Date: Thu, 03 Mar 2005 19:45:53 -0500 From: "Perry E. Metzger" <perry@piermont.com> To: "Poul-Henning Kamp" <phk@phk.freebsd.dk> Cc: ticso@cicely.de Subject: Re: FUD about CGD and GBDE Message-ID: <87bra0grwe.fsf@snark.piermont.com> In-Reply-To: <12311.1109893353@critter.freebsd.dk> (Poul-Henning Kamp's message of "Fri, 04 Mar 2005 00:42:33 %2B0100") References: <12311.1109893353@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes: >>> You don't actually know if I invented my own "cryptographic modes" >>> or not, do you ? >> >>You did. > > 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 falls. 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 perry@piermont.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87bra0grwe.fsf>