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.
Cheers,
-j
--
Jeffrey Goldberg http://www.goldmark.org/jeff/
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
