: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
<dil...@backplane.com>
