FUD about CGD and GBDE

[Perry E. Metzger]

"Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
> In message <877jknik4w.fsf at snark.piermont.com>, "Perry E. Metzger" writes:
>>The best I can say, however, is that the US
>>government has approved the use of AES with 256 bit keys for very
>>highly secure communications, and they have a very demanding user
>>community.
>
> (There is a big difference in what crypto you need for communications,
> storage, and archiving.)

In general, yes, but not in this context. In communications you need
stuff like authentication that you don't always need in archiving.

Anyway, the need for long term safety on a government top secret
message is unlikely to be lower than the requirement in a storage
context. That's because the adversary can store your message for 30
years just as you can.

> My philosophy in this, (as implemented in GBDE), is to trust the
> algorithms to do their job, but to not offer an attacker any more
> leverage against them than I absolutely have to.

In theory, that's a fine sentiment. The problem is that it is very
hard to achieve that.

> It has been said by various people that "there are [currently]
> no cause to think that using the same key for many millions of
> sectors is a problem".
>
> I belive that is a fair and balanced summary, and I trust the
> people to know what they talk about and I belive them.
>
> Nontheless, I do not consider it good engineering to expose the
> algorithm to unnecessary stress, even if we currently belive we
> have a 220 bits margin of safety, if by trivial means, I can avoid
> that stress on the algorithm and maintain 256 bits of margin.

Let me phrase this in software engineering terms, but it applies also
at the crypto layer. In theory, this is a nice idea, but imagine if,
in the course of producing your "improved" version, you are actually
increasing the risk because there is more code to audit and that code
is more complex. (On the crypto side, the issue is that you're
combining operations in complex ways that are hard to analyze. Even if
you wish to do such a thing, you are in general better off doing it in
a way that is designed to be easy to analyze. Often changes that are
seemingly trivial to a layman make a big difference in what you can
analyze in cryptography and cryptographic protocols.)

> But in the case something unforeseen happens, I know that GBDE will
> yield its secrets only one sector at a time and CGD will spill all
> the eggs at once because it has only one basket.

You have one basket too -- the master key. What if there's a nice
time/memory tradeoff attack to locate it on your disk? At very best, I
can gain a security factor of N this way, where N is the number of
disk sectors. In truth, however, one can probably do much better if
you're willing to spend some money.

Then, of course, what if your algorithm for turning your master key
into a sector key key isn't very good? That last bit is equivalent to the
"key scheduling" problem you find in many cryptosystems -- and bad
key-schedulers are notorious for causing serious trouble. You may think
that you've increased the work factor, but perhaps you haven't. The
literature is full of unfortunate instances of that.

In any case, cracking AES-128 on every sector is pretty clearly
cheaper than cracking AES-256 assuming AES is good. If AES is bad,
well, your lock sector or attacking the whole disk are again
possibilities.

I suspect that the security you add by slowing down your crypto enough
to do all the master keying you do is likely a lot smaller than simply
moving to AES-256 would have given you. If AES isn't good enough for
you, you can do stuff like triple-AES, but I think that's likely
overkill.

> As for making user selectable ciphers and keysizes I decided against
> it for two reasons.
>
> The first reason is that it adds complexity.

The code is easily verified though by using test vectors for standard
algorithms. In any case, it is a lot simpler to do that than what you
have done. You've added substantial complexity behind the scenes, much
of which is hard to analyse.

> The second is that it offers complexity.
>
> Adding complexity in the implementation is wrong for all the reasons
> we all agree on.  To justify that complexity, a benefit must be
> proven.

The benefit is straightforward -- the user can select their tradeoff
between speed and security, and between simplicity in keying and added
security from multi-factor keying, and the user can switch to a new
algorithm if an old one proves wanting, without even having to compile
a new kernel.

> In all my interviews and talks with people, I found nobody who
> wanted that level of flexibility.  Everybody, almost in unison sang
> from the "AES is the annointed king and 128 bit is the his key
> size." hymn.

Then why didn't you stick to AES-128 throughout? :)

> The other complexity is for the user.  The more questions the user
> has to determine the correct answer to, the less likely he is to
> get it all right if he is not a subject matter specialist.

That's what friendly install software is for. You need not emasculate
a system, however, for fear that an advanced user might want to turn
knobs. You can simply make sure that the defaults are okay.

> Finally, on keying schemes:  I didn't put a keying scheme on GBDE
> because I belive in the "tools not policies" dogma.  The gbde(8)
> userland program should be (but isn't quite) flexible enough to
> support any keying scheme people decide to use.

CGD is similar in that the kernel isn't doing all the flexible key
management stuff -- that's userland.

> PS: Will you be at BSDcan ?  It would be a good chance to corner
> a whiteboard and some beer.

Possibly. If I am, see you there.

-- 
Perry E. Metzger		perry at piermont.com