> I have a web application that allows users to download their data to a
> file on their computer.  Then at a later time they can upload the file
> back to the web server and continue working.  The file is in XML
> format.  I want to find a simple way to encrypt the file before I
> stream it down to their computer.  Then at a later time I will need to
> decrypt it when they re-upload it.  The user's do not have any type of
> account on the server so I am assuming that I will need to use the same
> key information for every file that I encrypt.  I have done quite a bit
> of reading on MSDN about cryptography and still can not make heads or
> tails of it.  All of the examples that I have seen seem to generate the
> key on the fly every time.  I need a solution where I store the key
> somewhere on the server so that I can use it every time I need to
> encrypt a file.
>
> Can anyone point me to a simple example of how to encrypt a file using
> a key stored somewhere on the server?
>
> Thanks,
> Corey
>

> "Eric Johnson" <e*@ejinnovations.com> wrote in message
> news:qFJIf.22845$6Q3.17878@fe07.news.easynews.com...
>> I'm new to this to, in fact I just got done with my first real use of encryption and it doesn't
>> sound too different from what you are running into.  Here's a little about what I ended up doing,
>> hopefully it'll help.
>>
>> I created a public/private key pair (RSACryptoServiceProvider) that gets stored in a Key Container
>> on the server.  The client is given the public key so they can decrypt stuff the server encrypted
>> with its private key.
>>
>
> The public key should be considered exactly that .. PUBLIC ..
> If you are expecting that the data is ENCRYPTED with the servers private
> key, then this is poor security.
> What you are doing (encrypting with servers private key .. decrypting with
> corresponding public key on the client) is what digital siganture verification is about.
> Public keys should be considered complely visible publically .. therefore, the
> encryption  scheme you are using is not sure at all (even though you might think
> you are protecting the  public key for your clients use only?)
>
> - Mitch Gallant
>    MVP Security
>
>

"Eric Johnson" <e*@ejinnovations.com> wrote in message
news:znLIf.53504$vO1.34889@fe04.news.easynews.com...
> Let me clarify... in the code I just completed, the client is actually doing the encryption with
> the public key and the server decrypts with the private.  I misspoke when trying to explain with
> respect to the problem Corey is working with.
>
> Thanks for bringing that to my attention... Corey I apologize for the misstatement.
>
>
>
> Mitch Gallant wrote:
>> "Eric Johnson" <e*@ejinnovations.com> wrote in message
>> news:qFJIf.22845$6Q3.17878@fe07.news.easynews.com...
>>> I'm new to this to, in fact I just got done with my first real use of encryption and it doesn't
>>> sound too different from what you are running into.  Here's a little about what I ended up
>>> doing, hopefully it'll help.
>>>
>>> I created a public/private key pair (RSACryptoServiceProvider) that gets stored in a Key
>>> Container on the server.  The client is given the public key so they can decrypt stuff the
>>> server encrypted with its private key.
>>>
>>
>> The public key should be considered exactly that .. PUBLIC ..
>> If you are expecting that the data is ENCRYPTED with the servers private
>> key, then this is poor security.
>> What you are doing (encrypting with servers private key .. decrypting with
>> corresponding public key on the client) is what digital siganture verification is about.
>> Public keys should be considered complely visible publically .. therefore, the
>> encryption  scheme you are using is not sure at all (even though you might think
>> you are protecting the  public key for your clients use only?)
>>
>> - Mitch Gallant
>>    MVP Security
>>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:eLLw0HoMGHA.1124@TK2MSFTNGP10.phx.gbl...
> That's good!  You are then talking about "enveloping" data to the
> server.
> The OP if I understand correctly, wanted the file to be encrypted to
> each client .. which of course is not addressed by enveloping back to the
> server.
> If data protection on the wire is important to may users, than SSL makes
> sense,
> potentially with end-user authentication (i.e. possibly user-certificates
> to validate users).
> Perhaps the OP can clarify exactly what the requirements are.
> - Mitch
>
> "Eric Johnson" <e*@ejinnovations.com> wrote in message
> news:znLIf.53504$vO1.34889@fe04.news.easynews.com...
>> Let me clarify... in the code I just completed, the client is actually
>> doing the encryption with the public key and the server decrypts with the
>> private.  I misspoke when trying to explain with respect to the problem
>> Corey is working with.
>>
>> Thanks for bringing that to my attention... Corey I apologize for the
>> misstatement.
>>
>>
>>
>> Mitch Gallant wrote:
>>> "Eric Johnson" <e*@ejinnovations.com> wrote in message
>>> news:qFJIf.22845$6Q3.17878@fe07.news.easynews.com...
>>>> I'm new to this to, in fact I just got done with my first real use of
>>>> encryption and it doesn't sound too different from what you are running
>>>> into.  Here's a little about what I ended up doing, hopefully it'll
>>>> help.
>>>>
>>>> I created a public/private key pair (RSACryptoServiceProvider) that
>>>> gets stored in a Key Container on the server.  The client is given the
>>>> public key so they can decrypt stuff the server encrypted with its
>>>> private key.
>>>>
>>>
>>> The public key should be considered exactly that .. PUBLIC ..
>>> If you are expecting that the data is ENCRYPTED with the servers private
>>> key, then this is poor security.
>>> What you are doing (encrypting with servers private key .. decrypting
>>> with
>>> corresponding public key on the client) is what digital siganture
>>> verification is about.
>>> Public keys should be considered complely visible publically ..
>>> therefore, the
>>> encryption  scheme you are using is not sure at all (even though you
>>> might think
>>> you are protecting the  public key for your clients use only?)
>>>
>>> - Mitch Gallant
>>>    MVP Security
>>>
>

"Henning Krause [MVP]" <newsgroups.rem***@this.infinitec.de> wrote in message
news:O3kCJUoMGHA.648@TK2MSFTNGP14.phx.gbl...
> Hello,
>
> I think the OP simply wants to encrypt the xml file to prevent the clients to edit the clear-text
> xml files.
>
> A symetric key is useful here. One could use the DPAPI (ProtectedData class in .NET 2.0). Because
> the scenario is in a ASP.NET environment, a machine-wide scope must be used with that API, so
> anyone running on the same machine under the same account could decrypt the files. But the clients
> could not decrypt it.
>
> Another approach is to create a symetric key and store it somewhere, like a file or a database
> table. The storage must then be secured properly by a strong ACL. So, no bulletproof solution.
>
> I would stick to the ProtectedData API.
>
> Greetings,
> Henning
>
> "Mitch Gallant" <jensigner@community.nospam> wrote in message
> news:eLLw0HoMGHA.1124@TK2MSFTNGP10.phx.gbl...
>> That's good!  You are then talking about "enveloping" data to the
>> server.
>> The OP if I understand correctly, wanted the file to be encrypted to
>> each client .. which of course is not addressed by enveloping back to the
>> server.
>> If data protection on the wire is important to may users, than SSL makes sense,
>> potentially with end-user authentication (i.e. possibly user-certificates to validate users).
>> Perhaps the OP can clarify exactly what the requirements are.
>> - Mitch
>>
>> "Eric Johnson" <e*@ejinnovations.com> wrote in message
>> news:znLIf.53504$vO1.34889@fe04.news.easynews.com...
>>> Let me clarify... in the code I just completed, the client is actually doing the encryption with
>>> the public key and the server decrypts with the private.  I misspoke when trying to explain with
>>> respect to the problem Corey is working with.
>>>
>>> Thanks for bringing that to my attention... Corey I apologize for the misstatement.
>>>
>>>
>>>
>>> Mitch Gallant wrote:
>>>> "Eric Johnson" <e*@ejinnovations.com> wrote in message
>>>> news:qFJIf.22845$6Q3.17878@fe07.news.easynews.com...
>>>>> I'm new to this to, in fact I just got done with my first real use of encryption and it
>>>>> doesn't sound too different from what you are running into.  Here's a little about what I
>>>>> ended up doing, hopefully it'll help.
>>>>>
>>>>> I created a public/private key pair (RSACryptoServiceProvider) that gets stored in a Key
>>>>> Container on the server.  The client is given the public key so they can decrypt stuff the
>>>>> server encrypted with its private key.
>>>>>
>>>>
>>>> The public key should be considered exactly that .. PUBLIC ..
>>>> If you are expecting that the data is ENCRYPTED with the servers private
>>>> key, then this is poor security.
>>>> What you are doing (encrypting with servers private key .. decrypting with
>>>> corresponding public key on the client) is what digital siganture verification is about.
>>>> Public keys should be considered complely visible publically .. therefore, the
>>>> encryption  scheme you are using is not sure at all (even though you might think
>>>> you are protecting the  public key for your clients use only?)
>>>>
>>>> - Mitch Gallant
>>>>    MVP Security
>>>>
>>
>
>

news:1140097423.073162.12650@g43g2000cwa.googlegroups.com...
> Let me clarify a bit.  The clients don't need to be able to decrypt the
> file.  I am encrypting it for two reasons.  One is so that if the file
> was to fall in to the wrong hands then they would not be able to make
> any sense of it.  The second reason is that if the file is encrypted
> hopefully the user's would be less likely to open up the file in a text
> editor and mess around with it.  The requirements for the application
> are that the users should be able to download their data from the
> program and keep it in a file on their computer.  They might want to
> email it to a colleague if they wanted to share their data with someone
> else.  Whoever has the file has to go back to the ASP.NET application
> and upload the file to continue working.  I am just concerned that
> people are going to attempt to open up the file in a text editor and
> see what's inside.  The underlying data is XML.  Since I couldn't
> figure out any way to really "lock" the file I figured that encrypting
> it would at least discourage people from editing the file in a text
> editor.  So the clients don't need to decrypt it.  The server just
> needs to be able to encrypt and decrypt the file all by itself.
>
> Hope this clears up the confusion.
>
> Corey
>

news:1140109555.910927.129050@o13g2000cwo.googlegroups.com...
> That is an excellent question - and one question that I have asked the
> client repeatedly.  The reason for this requirement is that the
> potential users of this application are very, very wary about saving
> their data to the web server.  They don't like the idea that their data
> is on the web server.  They want to have their data saved down to their
> computer.  I have tried all sorts of arguments and showed them how we
> could build the system so that the user is completely anonymous - but
> none of it is convincing to them.  The bottom line is that they want a
> web application (because it is easy to access and there are no
> installation issues) but they want to save the data down to their
> computer.  So I am left with this hybrid type of solution.
>
> Hope that explained it.
>
> Corey
>

news:1140115013.335571.199040@o13g2000cwo.googlegroups.com...
> Mitch,
>
> Thanks for your interest in helping me with this.
>
> The problem here really is a trust issue.  This is for a Department of
> Energy web site.  Users will be entering actual plant energy purchasing
> and consumption information.  Apparently this is highly confidential
> company information.  Everything I have been told by many different
> people on the client's side is that most users will definitely NOT want
> to store their data on the web server.  They are too worried about the
> data falling in to the wrong hands or, more importantly, they are
> worried that the data will be forwarded to the EPA and they will get in
> trouble!  So, during the design phase of this project the client said
> that they want a web application (easier to maintain) but they must
> have the option of saving their data down to their local computer.
> Mostly because the users do not trust the government when saving the
> data to the server.
>
> Now there is a technical point in all of this:  the data will ALWAYS be
> on the web server at least for a little time.  I have written the
> application so that the system cleans itself up when users are
> finished.  But, apparently, psychologically the users will feel much
> more comfortable with this application if they can save the data down
> to their computer.
>
> At one point I argued that it would be more worth our while to spend
> our time educating the users as to why it is ok for them to save their
> data to the server instead of spending time figuring out how to save it
> and load it from a file and "shuttle" the data back and forth.  They
> would not listen.  They were adamant that this application must provide
> the user with a way to save it down to their local computer.
>
> So I have written the system and it works pretty well.  It is pretty
> seamless.  Now I am looking for a way to encrypt the file so that
> people will be less likely to mess with it.  I also thought of zipping
> it up and changing the extension on the server before I send it to
> them.  Then when they re-upload it I could change the extension back
> and unzip it.
>
> Hope this explains things a bit more.
>
> Corey
>

news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
> 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
>

"Valery Pryamikov" <val***@harper.no> wrote in message news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
> 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.burn***@gmail.com> wrote in message
> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>> 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
>>
>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
> 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" <val***@harper.no> wrote in message
> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>> 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.burn***@gmail.com> wrote in message
>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>> 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
>>>
>>
>
>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:eV%23%23ybBNGHA.2276@TK2MSFTNGP15.phx.gbl...
> 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@community.nospam> wrote in message
> news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
>> 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" <val***@harper.no> wrote in message
>> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>>> 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.burn***@gmail.com> wrote in message
>>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>>> 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
>>>>
>>>
>>
>>
>
>

> security of CBC mode of operation (and sometimes could completely
> compromise security). Non-random IV automatically makes CBC to be IND-CPA
> insecure (however CTR mode provides better security with counter IV than
> with random IV).
> Adding a "salt" is redundant... and even harmful since it is just
> unnecessary goo that distructs attention from the real task - secure
> encryption.
> CBC with random IV is provably IND-CPA secure if cipher acts as PRF or PRP
> (against any, even yet unknown attacks!).
>
> -Valery.
> http://www.harper.no/valery
>
>
> "Mitch Gallant" <jensigner@community.nospam> wrote in message
> news:eV%23%23ybBNGHA.2276@TK2MSFTNGP15.phx.gbl...
>> 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@community.nospam> wrote in message
>> news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
>>> 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" <val***@harper.no> wrote in message
>>> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>>>> 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.burn***@gmail.com> wrote in message
>>>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>>>> 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
>>>>>
>>>>
>>>
>>>
>>
>>
>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:ub%23Yy3BNGHA.2472@TK2MSFTNGP11.phx.gbl...
> "Valery Pryamikov" <val***@harper.no> wrote in message
> news:uV12dpBNGHA.1124@TK2MSFTNGP10.phx.gbl...
>
>> Adding a "salt" is redundant... and even harmful since it is just
>> unnecessary goo that distructs attention from the real task - secure
>> encryption.
>
> So are you claiming that the salt used in the algorithm behind .NET
> PasswordDeriveBytes
> adds NO useful entropy (or added randomness) and hence is useless?
>
> - Mitch
>
>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:ehdUoFCNGHA.3852@TK2MSFTNGP15.phx.gbl...
> "Valery Pryamikov" <val***@harper.no> wrote in message
> news:eXU%23E%23BNGHA.3164@TK2MSFTNGP11.phx.gbl...
>> you misread what I wrote. Salt for PasswordDeriveBytes is important. Salt
>> appended to plain text before encryption (as you done it in your sample)
>> is
>
> I don't add the salt to the plaintext before encryption. The salt is
> written as is to the output file,
> and THEN the original (file) data is encrypted as per:
>
>   fSOut.Write(ransalt, 0, ransalt.Length);  //write out the random salt to
> file as binary
>   cstream = new CryptoStream(fSOut, algor.CreateEncryptor(),
> CryptoStreamMode.Write);
>
> - Mitch
>
>
>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:ub%23Yy3BNGHA.2472@TK2MSFTNGP11.phx.gbl...
> "Valery Pryamikov" <val***@harper.no> wrote in message
> news:uV12dpBNGHA.1124@TK2MSFTNGP10.phx.gbl...
>
>> Adding a "salt" is redundant... and even harmful since it is just
>> unnecessary goo that distructs attention from the real task - secure
>> encryption.
>
> So are you claiming that the salt used in the algorithm behind .NET
> PasswordDeriveBytes
> adds NO useful entropy (or added randomness) and hence is useless?
>
> - Mitch
>
>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:eV%23%23ybBNGHA.2276@TK2MSFTNGP15.phx.gbl...
> 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@community.nospam> wrote in message
> news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
>> 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" <val***@harper.no> wrote in message
>> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>>> 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.burn***@gmail.com> wrote in message
>>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>>> 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
>>>>
>>>
>>
>>
>
>

"Valery Pryamikov" <val***@harper.no> wrote in message
news:%23hn%2354BNGHA.1460@TK2MSFTNGP10.phx.gbl...
> 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@community.nospam> wrote in message
> news:eV%23%23ybBNGHA.2276@TK2MSFTNGP15.phx.gbl...
>> 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@community.nospam> wrote in message
>> news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
>>> 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" <val***@harper.no> wrote in message
>>> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>>>> 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.burn***@gmail.com> wrote in message
>>>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>>>> 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
>>>>>
>>>>
>>>
>>>
>>
>>
>

"Valery Pryamikov" <val***@harper.no> wrote in message
news:eDWe5ZCNGHA.2624@TK2MSFTNGP12.phx.gbl...
> 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" <val***@harper.no> wrote in message
> news:%23hn%2354BNGHA.1460@TK2MSFTNGP10.phx.gbl...
>> 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@community.nospam> wrote in message
>> news:eV%23%23ybBNGHA.2276@TK2MSFTNGP15.phx.gbl...
>>> 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@community.nospam> wrote in message
>>> news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
>>>> 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" <val***@harper.no> wrote in message
>>>> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>>>>> 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.burn***@gmail.com> wrote in message
>>>>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>>>>> 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>

"Valery Pryamikov" <val***@harper.no> wrote in message news:uLWLWgCNGHA.2580@TK2MSFTNGP14.phx.gbl...
>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" <val***@harper.no> wrote in message
> news:eDWe5ZCNGHA.2624@TK2MSFTNGP12.phx.gbl...
>> 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" <val***@harper.no> wrote in message
>> news:%23hn%2354BNGHA.1460@TK2MSFTNGP10.phx.gbl...
>>> 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@community.nospam> wrote in message
>>> news:eV%23%23ybBNGHA.2276@TK2MSFTNGP15.phx.gbl...
>>>> 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@community.nospam> wrote in message
>>>> news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
>>>>> 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" <val***@harper.no> wrote in message
>>>>> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>>>>>> 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.burn***@gmail.com> wrote in message
>>>>>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>

"Mitch Gallant" <jensigner@community.nospam> wrote in message
news:ezv6d4CNGHA.3852@TK2MSFTNGP15.phx.gbl...
> 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" <val***@harper.no> wrote in message
> news:uLWLWgCNGHA.2580@TK2MSFTNGP14.phx.gbl...
>>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" <val***@harper.no> wrote in message
>> news:eDWe5ZCNGHA.2624@TK2MSFTNGP12.phx.gbl...
>>> 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" <val***@harper.no> wrote in message
>>> news:%23hn%2354BNGHA.1460@TK2MSFTNGP10.phx.gbl...
>>>> 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@community.nospam> wrote in message
>>>> news:eV%23%23ybBNGHA.2276@TK2MSFTNGP15.phx.gbl...
>>>>> 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@community.nospam> wrote in message
>>>>> news:eyKnAI2MGHA.3196@TK2MSFTNGP09.phx.gbl...
>>>>>> 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" <val***@harper.no> wrote in message
>>>>>> news:uU5zkX0MGHA.3408@TK2MSFTNGP12.phx.gbl...
>>>>>>> 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.burn***@gmail.com> wrote in message
>>>>>>> news:1140119079.370490.179300@g44g2000cwa.googlegroups.com...
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>

"Alun Jones" <alun@texis.invalid> wrote in message
news:C9idnRc1N6rmc2XeRVn-vg@comcast.com...
> In article <uK$JCXJNGHA.3***@TK2MSFTNGP09.phx.gbl>, "Mitch Gallant"
> <jensigner@community.nospam> wrote:
>>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).
>
> You just have to love it when Mitch and Valery fight.  They are two of the
> best informed security guys around here, and it's instructive to watch
> them
> talk about how one thing or another makes security work.
>
> Valery's more theoretical than Mitch, so if Valery argues from a
> mathematical
> basis, follow his argument; but Mitch knows how to make .NET do the right
> things in the right way.
>
> Take-aways in summary form:
>
> IVs should always be randomly generated for each run through the
> encryption
> process.  They are there to ensure that two files with similar contents,
> encrypted with the same key, don't look similar at the end.
>
> IVs should be stored (unencrypted) with the encrypted text to which they
> refer.
>
> Sometimes a random salt can do a similar job to an IV, so much so that the
> two
> are often confused.  Salts and IVs may have different sizes, and
> therefore,
> different protection strengths.  Do not assume that this means that a big
> salt
> will override a small IV.
>
> If you derive a key from a password and a salt, the random salt must be
> stored
> (unencrypted) with the encrypted text so that you can re-derive the key at
> decryption time.
>
> If the server encrypts data before sending it to the client, and then
> decrypts
> the data after receiving it from the client, then by all practical
> definitions, the server is the only place where the data lives, and the
> clients' users cannot reasonably state that the data is not stored at the
> server.
>
> Sometimes people ask you to design a solution in a manner that doesn't
> solve
> the problem.
>
> Alun.
> ~~~~
>
> [Please don't email posters, if a Usenet response is appropriate.]
> --
> Texas Imperial Software   | Find us at http://www.wftpd.com or email
> 23921 57th Ave SE         | a***@wftpd.com.
> Washington WA 98072-8661  | WFTPD, WFTPD Pro are Windows FTP servers.
> Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.

"Valery Pryamikov" <val***@harper.no> wrote in message news:eY9hnDmNGHA.2884@TK2MSFTNGP12.phx.gbl...
> Thanks :D,
> a nice summary. :-).
>
> -Valery.
> "Alun Jones" <alun@texis.invalid> wrote in message news:C9idnRc1N6rmc2XeRVn-vg@comcast.com...
>> In article <uK$JCXJNGHA.3***@TK2MSFTNGP09.phx.gbl>, "Mitch Gallant"
>> <jensigner@community.nospam> wrote:
>>>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).
>>
>> You just have to love it when Mitch and Valery fight.  They are two of the
>> best informed security guys around here, and it's instructive to watch them
>> talk about how one thing or another makes security work.
>>
>> Valery's more theoretical than Mitch, so if Valery argues from a mathematical
>> basis, follow his argument; but Mitch knows how to make .NET do the right
>> things in the right way.
>>
>> Take-aways in summary form:
>>
>> IVs should always be randomly generated for each run through the encryption
>> process.  They are there to ensure that two files with similar contents,
>> encrypted with the same key, don't look similar at the end.
>>
>> IVs should be stored (unencrypted) with the encrypted text to which they
>> refer.
>>
>> Sometimes a random salt can do a similar job to an IV, so much so that the two
>> are often confused.  Salts and IVs may have different sizes, and therefore,
>> different protection strengths.  Do not assume that this means that a big salt
>> will override a small IV.
>>
>> If you derive a key from a password and a salt, the random salt must be stored
>> (unencrypted) with the encrypted text so that you can re-derive the key at
>> decryption time.
>>
>> If the server encrypts data before sending it to the client, and then decrypts
>> the data after receiving it from the client, then by all practical
>> definitions, the server is the only place where the data lives, and the
>> clients' users cannot reasonably state that the data is not stored at the
>> server.
>>
>> Sometimes people ask you to design a solution in a manner that doesn't solve
>> the problem.
>>
>> Alun.
>> ~~~~
>>
>> [Please don't email posters, if a Usenet response is appropriate.]
>> --
>> Texas Imperial Software   | Find us at http://www.wftpd.com or email
>> 23921 57th Ave SE         | a***@wftpd.com.
>> Washington WA 98072-8661  | WFTPD, WFTPD Pro are Windows FTP servers.
>> Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.
>