DragonFly kernel List (threaded) for 2010-04
Re: Crypto in DragonFlyBSD
On Fri, 2 Apr 2010, Matthew Dillon wrote:
The system does not have to know what the salt is before hand. The
idea is for it to be random junk. But the encrypted salt does have
to be recorded in the block or stream somewhere and that takes space.
You mean, it would prefix the data in the stream? (It can't be inside the
encrypted stream if you need the salt to decrypt it.)
DragonFly's HAMMER filesystem could encrypt individual file blocks
and store the encrypted salt in the B-Tree record referencing the
block. The decrypted salt could then be used to adjust the stream
cipher for the rest of the block.
It would be a good idea to ask a cryptographer about any fancy
non-standard plans. I'm worried that any enhancements us mere mortals
can come up with are either already well known, and incorporated in some
good crypto algorithm, or known to weaken the crypto algorithm.
Since the salt is random there is no attack which works on it that
helps the attacker guess the primary encryption key. The salt in
the encryption stream or block scrambles the rest of the data block
and makes it more difficult for pattern attacks to succeed. e.g.
where a user writes known patterns and is somehow able to access
the encrypted result and then backhack the key that way.
Right, but this still assumes that the salt / the seed for the random
numbers generator is known by the system (stored somewhere), but kept from
the user / attacker. That will not help against an attacker that gains
root and/or physical access.
(There is also an active console cracking scene, which indicates that even
if you have very smart people, and lots of money to spend on custom
hardware designed specifically not to give up its secrets, this is a hard
And if you are only guarding against non-root users, you might be able to
acheive the same thing more simply. The "salt" in the above description
sounds more like a secret part of the en/decryption key; instead you might
just pick a longer encryption key, equal to the lenghts of the two
separate keys. (And by the way, isn't this exactly the "trick" that made
Windows NT passwords so bad?)