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. So a dictionary attack isn't all that likely unless the encrypted files are of a specific nature (known template which remains constant while only small parts of the file vary).

Note that without salt (or with constant salt) an attacker would know which files are identical both within a snapshot or across them. But this is pretty much what the OP wants the back-up system to know, so I guess that would be okay.

If you are using a (e.g. USB connected) disk as backup, use geli(8) to encrypt
the whole disk instead of encrypting each file separately.

The OP may be doing something like rsync over an insecure network. But in the absence of details about the OPs situation it's hard to make solid recommendations. As you suggest, encrypting the resulting back-up filesystem is probably the the best option if the back-up filesystem is exacted to be the target of attack.



Jeffrey Goldberg                        http://www.goldmark.org/jeff/

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to