DragonFly BSD
DragonFly kernel List (threaded) for 2010-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Crypto in DragonFlyBSD

From: Magnus Eriksson <magetoo@xxxxxxxxxxx>
Date: Sat, 3 Apr 2010 01:26:04 +0200 (CEST)

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


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]