On Tue, May 26, 2009 at 09:31:25AM -0500, Jeffrey Goldberg wrote: > On May 25, 2009, at 2:00 PM, Roland Smith wrote: > > > You could use the -S option and specify a constant salt. It might make > > the encrypted materials easier to break, though. You can generate a > > random salt with openssl as well: > > > Or you can use the -nosalt option. But as explained in > > [http://www.openssl.org/docs/apps/enc.html], using a random salt by > > default is a design decision because: "Without the -salt option it is > > possible to perform efficient dictionary attacks on the password". > > That > > doesn't sound good, does it? > > This is being used for file encryption, not password encryption.
Of course. > So a dictionary attack isn't all that likely unless the encrypted > files are of a specific nature Suppose you are encrypting a tarfile that includes /usr/src/. There are definitely files in that tree that haven't changed in a long time. These could be used as (partial) cribs. > (known template which remains constant while only small parts of the > file vary). Or if you have the case of a 'known-plaintext' attack. It happens more often than you would think: [http://en.wikipedia.org/wiki/Known-plaintext_attack] Note that using a random salt would be a good protection against such an attack! I agree that in this case such an attack seems unlikely. From the original posters' questions I get the feeling that he is looking for an incremental encrypted backup solution for a large file or files. All possible solutions involve trade-offs between ease of use, robustness and security. And as you've said making a good choice requires more insight into the constraints. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725)
pgpzbNdD21c09.pgp
Description: PGP signature
