Re: How to encrypt/decrypt a file

Well, I never believe in fighting with Valery ;-)
Only with Alun! hehe
- Mitch

"Valery Pryamikov" <valery@xxxxxxxxx> wrote in message news:eY9hnDmNGHA.2884@xxxxxxxxxxxxxxxxxxxxxxx
Thanks :D,
a nice summary. :-).

-Valery.
"Alun Jones" <alun@xxxxxxxxxxxxx> wrote in message news:C9idnRc1N6rmc2XeRVn-vg@xxxxxxxxxxxxxx
In article <uK$JCXJNGHA.3196@xxxxxxxxxxxxxxxxxxxx>, "Mitch Gallant"
<jensigner@xxxxxxxxxxxxxxxx> 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 | alun@xxxxxxxxxx
Washington WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.



.

Relevant Pages

  • Re: How to encrypt/decrypt a file
    ... Modified to use random IV value (and random salt). ... You just have to love it when Mitch and Valery fight. ... IVs should always be randomly generated for each run through the encryption ... If the server encrypts data before sending it to the client, ...
    (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
    ... However random IV (in addition to password's salt) is better and more secure solution anyway. ... (and for CTR mode of operation counter IV gives much better IND-CPA security). ... get a cryptographically random salt (different for each encryption invocation) ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: How to encrypt/decrypt a file
    ... Mitch's sample doesn't use have salt that I was talking about, but a password salt is not redundand... ... get a cryptographically random salt (different for each encryption invocation) ... The question is, from a security perspective, should the IV also be derived from a RNGCryptoServiceProvider ... even so your customer's requirement looks quite strange - the server is processing the data and the server is watching that this exact data is not stored on the server... ...
    (microsoft.public.dotnet.security)
  • Re: Not enough salt for high speed server connection
    ... > they are free to be of any design the management approves. ... > information is considered quite sensitive so strength of encryption is ... How is this salt used? ... > As you would expect the machines with higher clock speeds were able to ...
    (sci.crypt)