[17031] in cryptography@c2.net mail archive
comments wanted on gbde
daemon@ATHENA.MIT.EDU (David Wagner)
Mon Mar 7 11:32:30 2005
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: David Wagner <daw@cs.berkeley.edu>
To: cryptography@metzdowd.com
Date: Sun, 6 Mar 2005 22:39:06 -0800 (PST)
Reply-To: daw-usenet@taverner.CS.Berkeley.EDU (David Wagner)
Steve Bellovin writes:
>A "discussion" -- I'll be polite and call it that -- has erupted on
>some mailing lists about gbde -- geometry-based disk encryption. With
>the author's consent, I'm soliciting opinions from this group about it:
>http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
I took a look at that paper. (I seem to recall looking briefly at actual
GBDE code two or three years ago, but I have since forgotten everything
I once knew about GBDE, so I was forced to read the paper and start
from scratch.) Here are some thoughts. Warning: they are based solely
on reading the above paper. I have not put a great deal of thought into
this, nor have I examined any source code, so take everything with many
grains of NaCl.
My sense: GBDE isn't built the way I would have chosen to, and there are
many aspects that I consider inelegant, but it doesn't look obviously
broken. If you use it appropriately, it looks fairly reasonable, as far
as I can tell. I would be willing to use it for my own personal secrets.
I believe it is possible to use it in a way such that it will provide
adequate security.
However, I also believe it is possible -- and, perhaps, all too easy --
to use GBDE in a way that will not provide adequate security. My biggest
fear is that safe usage is just hard enough that many users will end up
being insecure. GBDE uses a passphrase to encrypt the disk. If you can
guess the passphrase, you can decrypt the disk. Now in theory, all we
have to do is tell users to pick a passphrase with at least 80 bits of
entropy. However, in practice, this is a pipe dream. As we know, users
often pick passphrases with very little entropy. Practices vary widely,
but for many users, an estimate in the range of 10-40 bits is probably
reasonable. Consequently, dictionary attacks are a very serious threat.
GBDE does not take any steps to defend against dictionary attacks.
In GBDE, a passphrase with b bits of entropy can be broken with 2^b AES
trial decryptions. This means that people who are using passphrases
with only 10-40 bits of entropy may be screwed -- their data will not
be secure against any serious attack. 40-bit security is a very weak
level of protection.
So, this seems like it could be a real concern, depending on how GBDE
is used and how much security you need. If you can train users to use
strong passphrases, GBDE should be fine, I would think. For instance,
human rights workers might be willing to deal with the usability costs of
very long passphrases. However, many users may not have enough discipline
to use very strong passphrases, and those users might be at risk.
The GBDE paper has a rather peculiar comment about dictionary attacks.
It mentions the possibility of using password stretching/strengthening
techniques (e.g., PKCS#5, iteration to slow down dictionary attacks,
etc.), but rejects them on the basis that they are not able to ensure
perfect security in all cases. That strikes me as a rather weird stance.
They in no case make things worse, and in many cases may provide a
measurable improvement. I agree that such mechanisms are imperfect,
and there are severe limits on how much they can help, but they still
seem better than doing nothing about dictionary attacks. This strikes
me as an unfortunate aspect of GBDE.
A second possible critique of GBDE is that the design seems a little
strange in several places. There is no clear explanation of the threat
model GBDE is intended to protect against, or the security goals it is
intended to achieve. The design is unnecessarily complex and baroque.
I should elaborate. The threat model: What can we assume about the
attacker's capabilities? What kinds of attacks are we trying to
defend against? One scenario is where a hard disk is stolen, the
attacker gains access, and wants to read the data. But what about
other threats? The paper mentions the "cleaning lady" threat, where
an attacker gains physical access to the hard disk at multiple times,
without being detected. Do we want to defend against such attacks?
If we do, we need chosen-ciphertext security, because otherwise the
attacker might be able to tamper with data on the disk and thereby learn
information about the plaintext. The GBDE paper does not clearly say
whether GBDE is intended to design against this threat model, and I have
serious doubts about whether it would be secure against such a threat;
the modes are certainly not chosen-ciphertext secure. So can we assume
we do not need to defend against such threats, and that if the attacker
ever gains access to the hard disk, then we will learn of this fact and
never use the hard disk again? As another example, can we assume that
the communication between the computer and the hard disk is physically
secure, or might GBDE be used with NFS (for example)?
Also, the security goals are never precisely stated. Is the only goal to
protect the confidentiality of stored data? Do we also want to prevent
"traffic analysis", i.e., to prevent the attacker from identifying
recently-modified data? Do we also want to protect the integrity of
the data? I would expect that GBDE only achieves the first of these three
goals, but I haven't tried to analyze anything other than confidentiality.
A third potential complaint is that the design is unnecessarily complex.
GBDE invents new modes of operation, uses 1024-bit keys, and does other
strange things. My feeling is that all of this is unnecessary and only
contributes to complexity. It would have been simpler to just use AES,
rather than inventing new modes. Complexity is a risk, because it
increases the chances of subtle mistakes due to interactions between
different pieces of the system. New modes are also a risk. The paper
talks about fears that AES might be insecure if used to encrypt a lot of
data, but I believe those fears are misplaced, and I suspect the risk
of greater complexity outweighs the possibility of successful attacks
on AES. So the GBDE design is not exactly as I would have chosen,
if I were designing it.
That said, despite the unnecessary complexity and slightly baroque
design, I couldn't see any weaknesses introduced by this complexity.
The modes looked like they will probably be ok to me. I would be very
surprised if GBDE gets broken by attacking the crypto head-on; attacks
on the crypto just don't seem like the most likely failure mode for GBDE.
A bigger concern is the implementation cost of this complexity.
More complex algorithms means you need more code, and that is more code
that you can get wrong. A serious review of GBDE would need to look at
the implementation, but I did not do that.
Another potential risk is how carefully the keys are handled. Are keys
zeroized quickly enough? Could there be traces of a key left laying
around somewhere? Could memory data structures (whether in kernel memory,
or in user memory) that hold a key get swapped out? How careful are
the userland applications about handling data? What happens when you
suspend a laptop to disk; do keys get copied to disk? How carefully is
plaintext treated after it is decrypted (or before it is encrypted)?
Will applications that handle plaintext make copies into temporary
files, and if so, will those temporary files also be stored on an
encrypted partition? How are backups made and protected? And so on.
You get the idea.
In summary, the three biggest risks seem to be 1) dictionary attacks; 2)
unsafe use of the system, due to insufficient clarity about what GBDE can
and cannot achieve (e.g., threat models, security goals, etc.); 3) the
possibility of implementation flaws. Unnecessary complexity could also be
a concern for some people, but I could not see any obvious problems there.
That said, despite all my criticisms above, I believe that, for the most
part, GBDE is a pretty reasonable design. It may not be the most elegant
design possible, but if used appropriately, I believe it can provide a
useful level of security. It is definitely not perfect, but in many
ways, it seems to be "Pretty Good". In the grand scheme of things,
using GBDE is probably a heck of a lot better than doing nothing.
I am also mindful of the fact that Poul-Henning Kamp has actually built
the thing. It is one thing to sit on the sidelines and take potshots
at a design; it is another thing entirely to put in the time and energy
to design, implement, and support a complete disk encryption system.
I have great respect for those who take the time to implement crypto
in a way that is usable, and I think we should be grateful to phk for
his efforts. He has done the world a service in building GBDE.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
