Subject: Re: FUD about CGD and GBDE
To: Poul-Henning Kamp <firstname.lastname@example.org>
From: Perry E. Metzger <email@example.com>
Date: 03/03/2005 19:45:53
"Poul-Henning Kamp" <firstname.lastname@example.org> writes:
>>> You don't actually know if I invented my own "cryptographic modes"
>>> or not, do you ?
> I did ? Cool, I should patent them! :-)
I would encourage it. It will keep others from wanting to use them.
>>> Sorry, they have only been disproved in a significantly larger universe
>>> than the one my users inhabit. That doesn't count to me.
>>Being stubborn on this isn't going to help your users. The math is
>>pretty obvious here. Sure a brute force isn't practical -- but neither
>>is a brute force of AES-256.
> No, not right now.
And if a break was found, it isn't clear that all your you would
actually protect against it very effectively. The simpler and safer
solution is to have the ability to replace your algorithm easily.
> But do we know that a brute force attack is unfeasible on AES-256
> tens years from now ?
No, we don't. What we do know is that it seems pretty unlikely that
the general *mechanism* of CGD is flawed given the security of its
components. Since the components may be flawed, the system permits
easy selection of other algorithms.
My strong suggestion for you is that you adopt a similar approach --
build a good framework that, given good algorithms, will provide
security, and make it easy for users to change over if an algorithm
When we were designing IPSec, there was a very interesting proposal
called SKIP, which had as its main flaw that we could never really
alter algorithms if we picked it. That alone damned it. As it turns
out, our decision was a good one.
> And are we sure that the reuse of key material
> which happens in CGD will not materially aid any attacks that may
> be developed in the next decade ?
I will never say never, but the "reuse" is for IVs. Now, if you
examine what it means for something to be an IV in a CBC context, you
will see that you are, in a very real sense, not using the key any
differently than it is used elsewhere. That is to say, you are
encrypting a piece of data under the key and then using the output as
a value to xor with another piece of data. That is pretty much the
definition of CBC mode. Essentially what you have is prepended the
block number to each block and then run CBC over the whole block using
a zero IV. That of course means that the first block is now
theoretically vulnerable in reuse, but since it isn't secret and is
never reused and isn't even placed on the disk, we don't really care.
It is possible that this usage is subtly bad, but it has been studied
in many other contexts, such as in cryptographic network protocols,
and it is likely reasonable. Again, I will never say never, just as I
would never claim AES is safe forever.
> The fact that you just need to break one single sector in CGD before
> you get the entire disk contents gives a disadvantage to CGD of
> 2^26 before we even consider the nature of the attack.
I disagree with your analysis, but lets consider what you are saying.
You are claiming, in essence, that AES 256 isn't good enough for you,
and that you need a better cipher. If it isn't good enough for you, I
suggest that rather than bandaid AES 256, what you should do is
actually find a better cipher to use.
> The goal for GBDE is to give credible denial of access for up to
> 25 years,
Well, so is stock AES 256. I don't see why I should assume your
construction is any better. What do you know that the NIST/NSA review
of AES did not know?
Perry E. Metzger email@example.com