Date: Wed, 02 Mar 2005 11:14:30 +0100 From: Poul-Henning Kamp <phk@phk.freebsd.dk> To: hackers@freebsd.org Subject: FUD about CGD and GBDE Message-ID: <67876.1109758470@critter.freebsd.dk>
next in thread | raw e-mail | index | archive | help
I'm not regularly reading hackers these days, but I was pointed to the
amazing FUD being spread here. Please keep me in the Cc: if you want
me to see your replies.
The fact that the CGD author(s) engage in this FUD spreading in
random mailing lists rather than contact me directly speaks speaks
for itself, but here are my replies to some of the points raised:
If an attacker decides to attack a GBDE encrypted disk by brute-forcing
all the sectors he might have a theoretically very simple task of
on average 2^128 * Nsect work.
Right now 2^128 is considered a safe workload for brute force, but
that is assuming that the algorithms stand up to analytical attack.
But the devil is in the detail, and the detail in this case is
knowing that you had a hit.
The biggest problem in brute-force attacks is very often to _know_
that you had a hit. The actual crypto operations can be put in
silicon, but the practical hit-recognition is usually too complex
for hardware.
A brute force attack will produce 2^128 possible sector contents
and the attacker has no way of _knowing_ that he found the right
contents until he has checked if the hit is consistent with the
rest of his hits and the GBDE key schedule.
A brute force attack on a single sector in a trivial disk encryption
like CGD will reveal the key for all of the disk and you can very
fast verify that you got it right. The fact that filesystems
contains highly structured data like superblocks and bitmaps makes
this sensitive to almost any kind of weakness in the chipher.
A brute force attack on a single sector in GBDE gives that sector
and nothing which you can use the rest of the sectors with because
the key is PRNG, one-time use for each sector.
GBDE is written so there is no two-side leverage on any protocol
involved. This means that if a weak key is discovered or if one
of the algorithms has a major glaring hole of some kind, breaking
one single sector does not reveal any other sectors.
GBDE is probably slight overkill in this respect, but the other
extreeme, encrypting the entire disk with the same key (as CGD) is
very vulnerable to any kind of weakness in the ciphers: On a
contemporary disk that approach offers 80.000.000 differential data
points. No sane persone should ever encrypt 80.000.000 piece of
data with the same key: A one bit chip in the armour of the cipher
cuts 26 bits off the key. CGD even uses the key twice (a BIG no-no
if I ever learned anything) so they may loose much more.
The claim that:
"It is also structured in such a way that substantial
breakthroughs in the cracking of many different encryption
algorithms, hashes and random number generators will bring
the house of cards down."
Sounds very interesting and I am very
much looking forward to, but not
seriously expecting ever to, read a
substantiation of this claim. (Notice
that I made the margin wider here to
make sure they don't run out of space
:-)
As for the encryption algorithms being changeable, GBDE can be used
with any cipher and hash you care for. True, at this point it would
require a source code change, but it is not "impossible" as claimed.
If somebody wants an AES256 bit version of GBDE it wouldn't take
an hour to make the necessary changes.
The choices of algorithm I made were guided by which algorithms had
the best legal standing. It is no use that I think that algorithm
FOO is better if all the users of GBDE is bound by a legal requirement
for AES. Right now everything I have seen in the real world demands
AES128.
The claim that CGD can change the passphrase without reencrypting
they entire disk falls flat on its face: One cannot seriously claim
to have changed the passphrase if the 256 bit key used for the
entire disk remains constant. The static master key needs to be
at least 1024 bits to satisfy the contemporary security policies I
have been given access to.
With respect to the dictionary attack. The _real_ key of GBDE is
either 512 bits (changeable, for each of the four keys) or 2176
bits static, depending on where you decide to attack. I have not
heard of any realistic dictionary attacks of that size, mostly due
to shortage of atoms in the universe.
Now, currently the 512 bits are derived by running whatever the
user provides through SHA2, and if the user provides "password",
then a dictionary attack is indeed very feasible.
That, however, is not a problem in GBDE, that is a problem in
the users key-handling.
A very crucial design decision was that I did not want to impose a
particular kind of key-management on users of GBDE. Some people
want to use smartcards, some wants to split the the key between
multiple persons, across multiple locations or multiple media.
Some people use PGP/GPG for password management, other people use
signed CERTS. PKCS5 can obviously be used too.
GBDE allows any and all of these, by simply requring the production
of a repeatable bytestring of user selected length. Users so far
seem to appreciate this flexibility.
All the talk about what happens during a powerfail/crash is rather
uninformed: On any contemporary filesystem you will loose data,
encrypted or not, if the system crashes before you have a zero
return value from fsync(2). If fsync(2) completed successfully,
your data is safe on the disk, both with GBDE and CGD. Adding
journaling or before/after images to the disk encryption is totally
the wrong way to address this problem since all your filesystems
and disk device drivers suffer from the same issue.
(Adding journaling to your disk encryption has merits for other
reasons as it effectively obscures the write access pattern, but
the cost in performance and fragility of doing sector renames is
prohibitive IMO).
Finally, Yes, I will agree that GBDE takes a performance hit to
implement the PRNG single-use sector keys, but in practice that hit
is barely noticeable and the benefits it brings in cryptographic
strength can not be obtained in any cheaper way.
There are a lot of things GBDE doesn't try to protect against:
illicit modification of disks (If people can modify your disk
without you knowing about it, how do you know they did not also
modify your other hardware ?)
protection of running computers (This is an entirely different
ball game).
manipulation of entropy/randomness (If the attacker has this level
of control over your computer, don't you think you have other
problems which are more pressing ?)
The goal of GBDE was to write a trustworthy protection for cold
disks which also can protect the user and which can be used in
practice in real world organizations.
All reviews I have heard so far say that this goal was attained.
Several people have done detailed reviews for their respective
organizations, and none have yet to find anything wrong with GBDE.
Unfortunately, most people in this business seems to be very keen
on having their names not mentioned, so so far I think only Lucky
Green and David Wagner have stood by their opinion with their name.
I personally cherish this judgement from a government employed
analyst:
"It is refreshingly clear that it is just over the dotted
line into over-kill, yet simple enough that any theory about
loopholes can be disposed with instantly. Nobody will have
any doubt that the pass-phrase is the only viable access
path".
I personally find that the keyhandling is the only bit of CGD with
any real merits, what they do to the actual data on the disk appears
to be a mere afterthought to their work on key management. Since
I will not deny that the keyhandling is probably at little too much
left in the hands of the user in GBDE, it is obvious that it would
benefit boths parties to make the CGD key handling an option for
GBDE.
So how about it guys: Instead of spreading FUD, lets work together
and make the world an even better place ?
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67876.1109758470>