Crypto in DragonFlyBSD

[Magnus Eriksson]

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.
Hmm.

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 
problem.)

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?)

MAgnus