Crypto in DragonFlyBSD

[Matthew Dillon]

:Against dictionary attacks, as I understand it.  The salt ensures that you 
:can't just pre-generate a list of hashes once, from a huge dictionary, but 
:have to attack each system separately.
:
:The salt must still be available to the system for it to be able to 
:decrypt things, which as far as I can see means outside the encrypted 
:volume and readable by root -- and any attacker that can gain physical 
:access.  (If it's not available to the system, it's not a salt, but 
:something else, like part of the password.)

   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.

   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.  That would certainly work though
   it is a lot more complex than having a crypting block device.

   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.

   Another option would be to build or port an integrated software
   RAID-10 which uses a combination of salt and cryptographic hashes
   (like ZFS) to maintain multiple copies of the dataset and to
   deterministically detect corrupted data cases.  Kind of a two-for-one
   deal.  I would love to have a layer which does that.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>