Re: How to encrypt/decrypt a file

A new version of SimCrypt.NET tool is now available:
http://www.jensign.com/JavaScience/dotnet/SimCryptNET

Modified to use random IV value (and random salt).

The output file generated by SimCrypt.NET now contains:

byte[] salt (16 bytes plaintext)
byte[] IV (16 bytes plaintext)
byte inputfilename length (encrypted)
byte[] inputfilename (encrypted)
byte[] encryptedinputfilecontents (encrypted)

(or a base64 version of the above)

The new compiled exe (compiled to .NET 2) has been Authenticode signed again.

- Mitch Gallant

"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:ezv6d4CNGHA.3852@xxxxxxxxxxxxxxxxxxxxxxx
Yes you have convinced me (sorry to keep you up so late LOL)
that I need to modify that code!
I will modify that code and add crypt-random IV to the code.
So now the output file will consist of:
Unencrypted random salt + unencrypted random IV + encrypted filecontents
Thanks for taking the time to look at this.

I hope Ivan M. reads this ;-) (tried to fwd to him via some MS colleagues).

I'll advise here when the modified code sample is updated on my web site.

Cheers,
- Mitch

"Valery Pryamikov" <valery@xxxxxxxxx> wrote in message
news:uLWLWgCNGHA.2580@xxxxxxxxxxxxxxxxxxxxxxx
I should stop answering at 2 AM friday night :D.
That salt that Mitch used in his sample is a kind of savior :-).
even so the security proof of CBC is gone... but nevertheless the sample seems to be practically
secure ( I didn't check the rest of the code for possible problems ;D ).
However random IV (in addition to password's salt) is better and more secure solution anyway.
-Valery (going to sleep now :D)
http://www.harper.no/valery

"Valery Pryamikov" <valery@xxxxxxxxx> wrote in message
news:eDWe5ZCNGHA.2624@xxxxxxxxxxxxxxxxxxxxxxx
ops,
feel myself a bit embarrased by my remarks regarding imaginary salt :-).
Mitch's sample doesn't use have salt that I was talking about, but a password salt is not
redundand...
However without (imaginary) salt, the sample has very big problem with fixed IV (which could
have been easied if he'd use the salt that I'm imagined ;-) )
However the major statement stays true - you should always use random IV with CBC modes of
operations (and for other modes of operations - refer to fine print manual, because random IV is
not always the right answer :D ).

-Valery.
http://www.harper.no/valery


"Valery Pryamikov" <valery@xxxxxxxxx> wrote in message
news:%23hn%2354BNGHA.1460@xxxxxxxxxxxxxxxxxxxxxxx
Ops, forgot to answer Mitch's question (sorry):
The question is, from a security perspective, should the IV also be derived from a
RNGCryptoServiceProvider

Yes, for CBC mode of operation you should use random IV! RGNCryptoServiceProvider is one of the
closest thing that is easily acceptable to Windows developers. You should not encrypt IV, but
you need to send it together with cipher text. And salt is completely redundant here.
(and for CTR mode of operation counter IV gives much better IND-CPA security).

-Valery.
http://www.harper.no/valery


"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:eV%23%23ybBNGHA.2276@xxxxxxxxxxxxxxxxxxxxxxx
Thanks to Valery :-) for bringing to my attention that some security issues appear
to be present in that SimCryptNET sample I wrote and referenced below:

Basically, the procedure I use for symmetric encyrption in SimCryptNET is the following:

(1) get a cryptographically random salt (different for each encryption invocation)
byte[] ransalt = new byte[SALTBYTES];
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
rng.GetBytes(ransalt) ;

(2) derive both the AES key and corresponding IV sequentially as follows:
PasswordDeriveBytes pdb = new PasswordDeriveBytes(pswd, ransalt, "SHA1", ITERS);

Rijndael algor = Rijndael.Create();
algor.Key = pdb.GetBytes(32); //256 bit key
algor.IV = pdb.GetBytes(16); //block size is 16 bytes

Then, encrypt the target data in default CBC mode, write the salt to the output file,
followed by the
encrypted content.
NOTE: Since the IV is sequentially derived from the pdb, it is not written to the file, since
it can be
recovered from the password

The procedure used here in SimCryptNET is essentially identical to that in Ivan Medvedev's
encryption blog at:
http://dotnetthis.com/Articles/Crypto.htm
which is frequently referred to.

The question is, from a security perspective, should the IV also be derived from a
RNGCryptoServiceProvider
exactly the same way the salt value is created? in this case, of course, the IV as well as
the salt value
would need to be included in the file (if we want all info. for decryption to be contained in
one file).

- Mitch

"Mitch Gallant" <jensigner@xxxxxxxxxxxxxxxx> wrote in message
news:eyKnAI2MGHA.3196@xxxxxxxxxxxxxxxxxxxxxxx
Here is a fairly simply .NET 1.1 symmetric encryption utility, with source code,
I wrote a while ago, which uses password-derived symmetric key:
http://www.jensign.com/JavaScience/dotnet/SimCryptNET
showing the basic elements of sending the IV and encrypted data, as a
single "blob".
This linked page:
http://www.jensign.com/JavaScience/dotnet/SimCryptNET/indexdetails.html
discusses issues of strength of that password-derived key in .NET

- Mitch Gallant
MVP Security

"Valery Pryamikov" <valery@xxxxxxxxx> wrote in message
news:uU5zkX0MGHA.3408@xxxxxxxxxxxxxxxxxxxxxxx
Hi,
even so your customer's requirement looks quite strange - the server is processing the data
and the server is watching that this exact data is not stored on the server... quis
custodiet ipsos custodes - as Romans very succintly pit it: who watches the watcher?...
But to answer your question - any kind of encryption will fit your purpose as long as you
don't give your customer the secret decryption key you used to encrypt your data.
I.e. you can use for eg. a simmetric encryption (let say AES with 128 bit key), generate
random IV and random encryption key; encrypt the data that you are sending to the client
with just generated key+iv+CBC or CTR mode of op.; store encryption key indexed by IV in
secure database; send IV concatenated with cipher text to the customer's computer. Your
customer (even NSA) has no chance to decrypt the data as long as they don't have the key
(provable secure if AES acts as PRP). When the data is sent back to server, you simply
retrive the key from database by using IV from the custmer's data and decrypt cipher text -
that's it.

-Valery.
http://www.harper.no/valery

<corey.burnett@xxxxxxxxx> wrote in message
news:1140119079.370490.179300@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Mitch,

I think that the 2 issues are these:

- the users don't want a competitor to get a hold of of the data and
find out that the Acme company is spending X amount of dollars on
electricity and Y amount of dollars on natural gas. So they are wary
of putting their data on a server. Even if there is nothing in their
data that has their company name they feel that it can somehow be
traced back to them.

- the users don't want the government to have this data on their
servers. They equate the US DOE with enforcement (even though that is
handled by the EPA). So if they store their data on the server they
are afraid that the government will look at their energy use and come
after them.

So the solution is to give them an application that allows them to save
the data to their local computer. Ideally this probably should have
been built as a more traditional stand alone application. However the
client really wanted a web application because of the tremendous
headaches involved in developing stand alone applications that have to
be updated and all of the installation issues and platform issues.

I wasn't looking at encryption as a way of securing the data. I was
looking at encryption as a way to hopefully dissuade people from
editing the data file. They are going to be downloading a text file
with their data. If I encrypted it then maybe they would be less
likely to open it in a text editor and mess with it. This conversation
however has made me think about a few other things....

1. I should probably have the user supply a password before they
download the file. Then I could add the password to the XML file
before I encrypt it. Then when they upload the file I ask for the
password before I show it to them in the application. This would
prevent someone from opening the file without knowing the password for
the file.

2. The more that I think about it, the more I think that it is
absolutely necessary to encrypt the file for security reasons. They
want to be able to take these data files and exchange them with
colleagues or other company personnel. If they are encrypted and
password protected then someone who got the file would have to know the
password to upload the file to the web application and open it up.
They would just have to be instructed to never send the password in
email.

3. As far as other security goes... You asked how I would know that
potentially untrusted entities would not get a hold of the server-side
private key. Well, I am not a security expert when it comes to hiding
server-side private keys. The system is being housed at a DOE hosting
facility that has the normal physical security measures so that people
can't gain physical access to the server. We will be running the
entire site over SSL so that we have secure communication between the
server and client. I will have to do some reading on what the best way
is to store the server-side private key.

Corey













.

Relevant Pages

  • Re: Proposal for Lite Encryption for Login Form without SSL
    ... This way the password is not sent to the server ... simply copy the server-side salt used to hash the pw in the ... password in the database, it does make public the server-side salt ... This would be the equivalent to a public key in public key encryption ...
    (comp.lang.php)
  • Re: Proposal for Lite Encryption for Login Form without SSL
    ... This way the password is not sent to the server ... simply copy the server-side salt used to hash the pw in the ... This would be the equivalent to a public key in public key encryption ... library or function that's readily available for both js and php. ...
    (comp.lang.php)
  • Re: How to encrypt/decrypt a file
    ... However random IV (in addition to password's salt) is better and more secure solution anyway. ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: How to encrypt/decrypt a file
    ... Mitch's sample doesn't use have salt that I was talking about, but a password salt is not redundand... ... get a cryptographically random salt (different for each encryption invocation) ... The question is, from a security perspective, should the IV also be derived from a RNGCryptoServiceProvider ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: Not enough salt for high speed server connection
    ... > they are free to be of any design the management approves. ... > information is considered quite sensitive so strength of encryption is ... How is this salt used? ... > As you would expect the machines with higher clock speeds were able to ...
    (sci.crypt)