Date: Thu, 3 Mar 2005 10:48:47 -0500 From: Thor Lancelot Simon <tls@rek.tjls.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: crypto@metzdowd.com Subject: Re: FUD about CGD and GBDE Message-ID: <20050303154847.GA3454@panix.com> In-Reply-To: <7153.1109852325@critter.freebsd.dk> References: <20050303120421.GW86348@cicely12.cicely.de> <7153.1109852325@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 03, 2005 at 01:18:45PM +0100, Poul-Henning Kamp wrote: > In message <20050303120421.GW86348@cicely12.cicely.de>, Bernd Walter writes: > > >No matter what disk you take - writes never have been atomic. > >The major difference I see is that you get a read error back in > >the disk failure case, while such a crypto failure produces more or > >less random data without any error. > >Mounting unclean filesystems rw for bg_fsck can be considered > >dangerous with such unexpected data corruption. > >And how would you know that a restore from backup is required for > >a damaged file? > > 100% true. > > The trouble is that it would cost a lot in performance and a doubling > in metadata to protect yourself against this. No, it would not. What it _would_ take would be an abandonment of the adamant position that your home-grown cryptosystem is superior to simply encrypting the disk with 256-bit AES. After all, cgd doesn't diminish the atomicity of writes; it's only your key-key blocks that create this problem. Generally, complexity is not considered a desirable property in cryptosystems. GBDE violates this rule in spades. There are _reasons_ why complexity is not good: to begin with, a very complex cryptographic construct will require detailed analysis (which it does not appear GBDE has had by anyone but its author until Roland started looking at it) in order that we may know that it is even as secure as the underlying algorithmic building blocks it uses. Furthermore, with a very complex cryptographic construct it is easy to persuade oneself that the complexity actually has security benefits which it does not, and thus go forth into the dangerous world unprotected from _other_ attacks that one overconfidently ignores. I'd say that is certainly going on here as well (e.g. the continual minimization of how GBDE's implementation makes dictionary attacks easier). I have often observed the phenomenon that engineers who build extremely complicated software systems insist vigorously that, due to their very complexity (or perhaps due to the amount of time they've spent building them) they _must_ be better than simpler systems that are easier to implement and maintain. One might characterize this as the love of one's own big ideas. The best antidote to this is to ask not "do I believe that all this complexity could plausibly have some benefit" but rather "is there some shortcoming in the simple system that could plausibly justify all this complexity"; in other words, to begin from the assumption that complexity is bad. In the case of CGD and GBDE I think the answer is plainly "no, there is not". To believe that I wanted something better, I'd essentially have to believe that AES256 were vulnerable to, at best, a chosen- plaintext attack. The key derivation is solid (and standard); the encryption is solid (and standard); and it is a strong point in the system's favor that it does not _try_ to give me more than I want from it. Compare to GBDE, where a massively complicated construct using double-encryption -- and MD5! -- is used to splat keys all over the disk but no attention is paid to key derivation at all. That this conversation has degenerated to the point that GBDE's proponents are claiming that it _would be_ more secure _if_ only someone knew how to break 256-bit AES is to me a pretty good indicator of why GBDE is not encryption software that I want to use. -- Thor Lancelot Simon tls@rek.tjls.com "The inconsistency is startling, though admittedly, if consistency is to be abandoned or transcended, there is no problem." - Noam Chomsky
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303154847.GA3454>