Re: How to encrypt/decrypt a file

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: 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
    ... Modified to use random IV value (and random salt). ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... 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
    ... As an additional reading regarding I would recomend Goldwasser-Bellare Lecture Notes on Cryptography and Goldreich's Foundations of Cryptography. ... Any attempts of using precalculated IV that is not sent together with cipher is only decreasing security of CBC mode of operation. ... and even harmful since it is just unnecessary goo that distructs attention from the real task - secure encryption. ... 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: 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)