Recent

Author Topic: Encrypt a file  (Read 3910 times)

Ericktux

  • Full Member
  • ***
  • Posts: 229
Encrypt a file
« on: January 31, 2016, 08:08:04 am »
Good day,
as I can encrypt a file  :)

engkin

  • Hero Member
  • *****
  • Posts: 2513
Re: Encrypt a file
« Reply #1 on: January 31, 2016, 04:57:57 pm »
Try DCPcrypt. Example to show you how to encrypt a file is in the docs.

Ericktux

  • Full Member
  • ***
  • Posts: 229
Re: Encrypt a file
« Reply #2 on: February 01, 2016, 05:34:19 am »
thank you
I found a way to DCPcrypt.  :) :)

Code: Pascal  [Select][+][-]
  1. unit Unit1;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8.   Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls,
  9.   DCPrc4, DCPsha1;
  10.  
  11. type
  12.  
  13.   { TForm1 }
  14.  
  15.   TForm1 = class(TForm)
  16.     Button1: TButton;
  17.     Button2: TButton;
  18.     DCP_rc4_1: TDCP_rc4;
  19.     DCP_sha1_1: TDCP_sha1;
  20.     Edit1: TEdit;
  21.     Edit2: TEdit;
  22.     Label1: TLabel;
  23.     Label2: TLabel;
  24.     procedure Button1Click(Sender: TObject);
  25.     procedure Button2Click(Sender: TObject);
  26.     procedure FormCreate(Sender: TObject);
  27.   private
  28.     { private declarations }
  29.   public
  30.     { public declarations }
  31.   end;
  32.  
  33. var
  34.   Form1: TForm1;
  35.   KeyStr: string;
  36.  
  37. implementation
  38.  
  39. {$R *.lfm}
  40.  
  41. { TForm1 }
  42.  
  43. procedure TForm1.Button1Click(Sender: TObject);
  44. var
  45.    Cipher: TDCP_rc4;
  46.    Source, Dest: TFileStream;
  47.  begin
  48.    //if InputQuery('Passphrase','Enter passphrase',KeyStr) then  // get the passphrase
  49.    begin
  50.      try
  51.        Source:= TFileStream.Create(Edit1.Text,fmOpenRead);   // Edit1.Text, PATH SOURCE OF FILE
  52.        Dest:= TFileStream.Create(Edit2.Text,fmCreate);       // Edit2.Text, PATH DESTINATION OF FILE
  53.        Cipher:= TDCP_rc4.Create(Self);
  54.        Cipher.InitStr(KeyStr,TDCP_sha1);              // initialize the cipher with a hash of the passphrase
  55.        Cipher.EncryptStream(Source,Dest,Source.Size); // encrypt the contents of the file
  56.        Cipher.Burn;
  57.        Cipher.Free;
  58.        Dest.Free;
  59.        Source.Free;
  60.        MessageDlg('File encrypted',mtInformation,[mbOK],0);
  61.      except
  62.        MessageDlg('File IO error',mtError,[mbOK],0);
  63.      end;
  64.    end;
  65.  end;
  66.  
  67. procedure TForm1.Button2Click(Sender: TObject);
  68. var
  69.     Cipher: TDCP_rc4;
  70.     //KeyStr: string;
  71.     Source, Dest: TFileStream;
  72.   begin
  73.     //if InputQuery('Passphrase','Enter passphrase',KeyStr) then  // get the passphrase
  74.     begin
  75.       try
  76.         Source:= TFileStream.Create(Edit1.Text,fmOpenRead);   // Edit1.Text, PATH SOURCE OF FILE
  77.         Dest:= TFileStream.Create(Edit2.Text,fmCreate);       // Edit2.Text, PATH DESTINATION OF FILE
  78.         Cipher:= TDCP_rc4.Create(Self);
  79.         Cipher.InitStr(KeyStr,TDCP_sha1);              // initialize the cipher with a hash of the passphrase
  80.         Cipher.DecryptStream(Source,Dest,Source.Size); // decrypt the contents of the file
  81.         Cipher.Burn;
  82.         Cipher.Free;
  83.         Dest.Free;
  84.         Source.Free;
  85.         MessageDlg('File decrypted',mtInformation,[mbOK],0);
  86.       except
  87.         MessageDlg('File IO error',mtError,[mbOK],0);
  88.       end;
  89.     end;
  90.   end;
  91.  
  92. procedure TForm1.FormCreate(Sender: TObject);
  93. begin
  94.   KeyStr         := 'casa777';     // my password
  95. end;
  96.  
  97. end.
« Last Edit: February 01, 2016, 05:54:55 am by Pascalito100 »

JimD

  • Jr. Member
  • **
  • Posts: 62
Re: Encrypt a file
« Reply #3 on: December 20, 2018, 11:05:46 pm »
I was testing the ENCRYPT FILE download and couldn't show the form.
Instead of troubleshooting, I just re-created in the attached.
I changed a few things except no changes to the encrypt/decrypt code sections.

You'll need the package: http://wiki.freepascal.org/DCPcrypt
Hint: open and compile the runtime version dcpcrypt.lpk

My Config:   Windows 10 Home 64-bit,   Lazarus 1.8.2, FPC 3.0.4

karmacomposer

  • New Member
  • *
  • Posts: 12
Re: Encrypt a file
« Reply #4 on: December 04, 2020, 04:34:23 pm »
I was testing the ENCRYPT FILE download and couldn't show the form.
Instead of troubleshooting, I just re-created in the attached.
I changed a few things except no changes to the encrypt/decrypt code sections.

You'll need the package: http://wiki.freepascal.org/DCPcrypt
Hint: open and compile the runtime version dcpcrypt.lpk

My Config:   Windows 10 Home 64-bit,   Lazarus 1.8.2, FPC 3.0.4

How would I use this library with text from fields using AES256 with a password and salt?  I am finding it very difficult to find any example documentation on this.
I am porting a working system from another language where the encrypt/decrypt functionality was built into the language.

Thank you for any help.

Mike

Warfley

  • Sr. Member
  • ****
  • Posts: 380
Re: Encrypt a file
« Reply #5 on: December 04, 2020, 04:54:26 pm »
How would I use this library with text from fields using AES256 with a password and salt?  I am finding it very difficult to find any example documentation on this.
The class/component you need for AES is called TDCP_rijndael and is used like any other of the ciphers, so you can use the exact example from above by replacing TDCP_rc4 with TDCP_rijndael. To use AES256 you need to adjust the BlockSize Property to 256 (default is 128).

About the salt, for encryption and decryption there is absolutely no point in using a salt. A salt is only used when *storing* passwords as a hash, so that two instances of the same password are not stored with the same hash (which means cracking one of them cracks all of them). When you are encrypting data using a cipher there is absolutely no need for a salt.

But if you insist on using one anyway, to use a salt just concatinate it with the password:
Code: Pascal  [Select][+][-]
  1. // Set password without salt:
  2. Cipher.InitStr(Password, TDCP_sha1);
  3. // With salt:
  4. Cipher.InitStr(Password + Salt, TDCP_sha1);

karmacomposer

  • New Member
  • *
  • Posts: 12
Re: Encrypt a file
« Reply #6 on: December 05, 2020, 12:24:50 am »
How would I use this library with text from fields using AES256 with a password and salt?  I am finding it very difficult to find any example documentation on this.
The class/component you need for AES is called TDCP_rijndael and is used like any other of the ciphers, so you can use the exact example from above by replacing TDCP_rc4 with TDCP_rijndael. To use AES256 you need to adjust the BlockSize Property to 256 (default is 128).

About the salt, for encryption and decryption there is absolutely no point in using a salt. A salt is only used when *storing* passwords as a hash, so that two instances of the same password are not stored with the same hash (which means cracking one of them cracks all of them). When you are encrypting data using a cipher there is absolutely no need for a salt.

But if you insist on using one anyway, to use a salt just concatinate it with the password:
Code: Pascal  [Select][+][-]
  1. // Set password without salt:
  2. Cipher.InitStr(Password, TDCP_sha1);
  3. // With salt:
  4. Cipher.InitStr(Password + Salt, TDCP_sha1);

I was under the impression that a salt value was inserted into a password to make it even harder to crack.

Quote
Salt is used when hashing, IV when encrypting. In both cases, the purpose is to prevent the same input from always resulting in the same output by adding a random input. If you see 'salt' in context of encryption, it probably means IV. ... It is important to point out that, when encrypting, you need to protect the IV

That is from https://security.stackexchange.com/questions/48000/why-would-you-need-a-salt-for-aes-cbs-when-iv-is-already-randomly-generated-and#:~:text=Salt%20is%20used%20when%20hashing,encryption%2C%20it%20probably%20means%20IV.&text=It%20is%20important%20to%20point,need%20to%20protect%20the%20IV.

I have never used an IV value, so it seems a IV is a salt, but just used differently.  Does DCPCrypt use IV instead of a salt?

Thank you for your help, btw.

Mike

Warfley

  • Sr. Member
  • ****
  • Posts: 380
Re: Encrypt a file
« Reply #7 on: December 05, 2020, 02:47:43 am »
I was under the impression that a salt value was inserted into a password to make it even harder to crack.

A salt does not give any security against cracking a single password, it only ensures that two encryptions of the same data using the same password don't result in the same ciphertext.

So if you need that depends on the data you want to encrypt. How likely is it that two people use the exact same password for the exact same data? If you encrypt password lists that includes usernames and passwords, the probability is pretty much none because this would imply that two different people have exactly the same accounts, making them the same person. So no new information can be extracted from the second version of the same data.

About IVs, when using block ciphers like AES, you need a CipherMode. The default mode thats used by DCPCrypt is CBC. CBC requires an IV, therefore to answer your question, yes DCPCrypt uses IVs.

About your quote and the need to protect the IV, this is talking about a very special circumstance, an attack called BEAST on an encrypted TCP stream where blocks can be injected into. The vulnerability requires the ability to inject your own message into the encoded stream to be encoded with the exact same (unknown) password than the rest of the stream. Then you can craft a message such that the IVs cancel out and you can basically encrypt a message with the same key the original message was encrypted. You can then just try to encrypt all possible combinations of that message until the result is the exact same, you found out the plaintext.
This attack is only feasable if you know most of the target message and only miss a few bytes, otherwise this is just a bruteforce attack.

So the question is, can malicious data be injected into your datastream and then, how much of the data you encrypt is known a-priori.

For BEAST this is actually a real problem, as this targets HTTPS, where untrusted javascript code can inject data into the TLS encrypted TCP stream, for example using record splitting, and as the transmitted format (HTML, JSON, XML) is usually pretty strictly defined with only a few variables in there (usually a webserver sends templates with only a few customizations), this attack becomes viable.
But this is a very special setup as this relies usually on injection vulnerabilities (usually by browsers that load malicious javascript). It therefore is made possible because browsers implement a fully fledged scripting language interpreter that executes any code it is given.

If you for example encrypt a file, there is no way to keep the IV a secret, because it must be stored besides the file. This is also not really a security risk, because the encryption stream is usually only used for exactly that file giving no possibility to inject malicious data into it.
« Last Edit: December 05, 2020, 02:50:07 am by Warfley »

karmacomposer

  • New Member
  • *
  • Posts: 12
Re: Encrypt a file
« Reply #8 on: December 05, 2020, 02:50:46 pm »
So, if I create a random password (I have a routine to create very strong passwords from another language that I will port into Pascal) and then create another random string to be the IV, it would be very hard to crack considering I am not using a web language or browser for any of that, correct?

Thank you for the help.  I may ask more questions as I code this because my OOPascal is very rusty - used to code in Delphi 15 years ago when it was Borland Delphi and have been coding in other languages since.  Now I am back using Lazarus for now and possibly Delphi later on.

Mike

Warfley

  • Sr. Member
  • ****
  • Posts: 380
Re: Encrypt a file
« Reply #9 on: December 05, 2020, 04:25:49 pm »
DCPCrypt has two different options for the providing IV. Either your IV is computed from the password, this ensures that if your password is strong and secret, so is the IV. Or you can supply your own IV, this is useful if you want to use a specific IV, e.g. for compatibility with another language and/or library, so you can "negotiate" the IV. But in that case your IV is not a protected secret, as you need to negotiate it with the other party.

In general, if you use DCPCrypt for both, de and encrypting letting it compute the IV is the easiest solution and as it is computed from the password, it is a secret (it is also computed in a way that you can't get the original password from the computed IV, so it is secure).
If you use different components for de and encryption, you must provide your own IV to ensure both libraries have the same IV.

If your IV needs to be a secret is a different question, to avoid the BEAST attack, it is better to have the IV to be unknown, but BEAST can only be applied onto a stream to which one can inject his own packages, so for example for typical file encryption this is not an issue. That said, there is nothing wrong with using a secret IV, but I would recommend to compute it from the password in a deterministic way. This way you don't need to have "two passwords" in form of the password and the IV.

DCPCrypt provides the IV by using the 0 vector and encrypting it with the password using AES (in EBC mode). So the IV is AES(EmptyString, Password, ECBMode). Other options would be to hash the password or to use a hard problem like discrete logarithm for this. And as long as your password is secure, your IV will also be

 

TinyPortal © 2005-2018