From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 21:40:39 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C879416A4CE for ; Tue, 1 Mar 2005 21:40:39 +0000 (GMT) Received: from marlena.vvi.at (marlena.vvi.at [208.252.225.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F2BA43D46 for ; Tue, 1 Mar 2005 21:40:39 +0000 (GMT) (envelope-from www@marlena.vvi.at) Received: from marlena.vvi.at (localhost.marlena.vvi.at [127.0.0.1]) by marlena.vvi.at (8.12.10/8.12.9) with ESMTP id j211jNoH046189; Mon, 28 Feb 2005 17:45:24 -0800 (PST) (envelope-from www@marlena.vvi.at) Received: (from www@localhost) by marlena.vvi.at (8.12.10/8.12.10/Submit) id j211jF1s046188; Mon, 28 Feb 2005 17:45:15 -0800 (PST) (envelope-from www) Date: Mon, 28 Feb 2005 17:45:15 -0800 (PST) Message-Id: <200503010145.j211jF1s046188@marlena.vvi.at> To: elric@imrryr.org From: "ALeine" cc: freebsd-hackers@freebsd.org cc: kernel@crater.dragonflybsd.org cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 21:40:39 -0000 elric@imrryr.org wrote: > You would need to maintain some sort of journal. With CGD, I > specifically avoided any strategy which tied the write of one > sector to the write of another sector for this reason. And so, > I use one key to encrypt the disk rather than storing randomly > generated keys upon every write. > > GBDE already explodes a single sector write into two sector > writes, which makes its performance quite suboptimal. Adding a > journal would make it even worse. I do not think that maintaining a > different key for each sector actually provides enough benefit to > justify this. I find using a single key for the whole disk less secure and not very practical when one wants to change the key because it takes a very long time to re-encrypt the entire disk. However, having a separate per-sector key which is changed on every write seems to go too far in the opposite direction, so IMHO the best solution would be to use the same key for a definable number of sectors (set at initialization) and then having a sysctl variable to control after how many writes you want the key changed. This would speed things up quite a bit and users would be allowed to decide how much assumed security they are willing to sacrifice for noticable speed. This would also make it possible to implement my key shadow sector idea without a performance penalty in comparison to the current implementation of GBDE. > This is basically implementing a journal. It adds a lot of > complexity for IMO very little gain over moving to a simpler solution such > as CGD. The whole thing (GBDE) is already pretty brittle, i.e. hard > to change without breaking. This would make it more so. Well, it does not need to be very complex and I am more interested in getting this kind of functionality in 4.x, so I think that porting GBDE would be more work than writing my own implementation from scratch and just using the same principles, only adapted and implemented in a way to suit my ideas and needs. > And, GBDE is obviously already less secure than a simpler > approach such as CGD with AES-256 (which is around twice as fast). I believe it is not less secure because eventhough it might require less steps to brute force a sensitive part of the filesystem (some directory structure), the impact is completely localized and can't be used to leverage a wider compromise, while that is not the case with CGD. As I said, I believe the speed of GBDE could be greatly improved by implementing my ideas, but AFAIK there seems to be very little you can do to improve the speed of CGD beyond how fast it is now because it is already using the most simple approach and any additional optimization attempts would only increase the complexity, which is something you seem to want to avoid at all cost. > Many rather dubious claims have been made about GBDE such as in: > > http://www.bsdcan.org/2004/papers/gbde.pdf > > PHK claims that it will take O(2^384) to crack GBDE if the lock > sector is destroyed. Perhaps my maths is a little rusty, but it > perplexes me how it could possibly take 2^384 steps to > individually crack 2^30 sectors that are encrypted with 128 bit AES. > That comes out to a [not at all strict] upper bound of 2^158 steps to > entirely crack a 512GB disk. So, already it is less secure than CGD > using 256 bit AES. But, obviously you'd just crack the ``key-key > sectors'' which would knock another 5 bits off. Now, consider that > really an attacker doesn't really care about the whole disk. By chasing > directory structures, etc., they could find what they wanted in > very little more than O(2^128). So, what's the point of all of > the gymnastics... a few bits. I believe PHK's calculations are based on the fact that even if you want to brute force a GBDE volume, you have to assume it's encrypted using GBDE and then try to break the structured multilayered mechanism, because otherwise you can only hope to brute force a very minimal part of the disk that would do you no good in leveraging that knowledge to break the encryption of the rest of the disk. > It is also structured in such a way that substantial > breakthroughs in the cracking of many different encryption algorithms, > hashes and random number generators will bring the house of cards down. > I do not believe that it has had an appropriate amount of peer > review to be considered trustworthy, and I have seen some pretty > obvious weaknesses that I've been meaning to write up but haven't > quite found the time that would knock a few more bits off. I believe PHK is well aware of the threats, he even commented on them in the code itself and his papers, his choice of SHA2/512, for example, shows that he is planning for those advances that pose a threat. I am sure there is room for a lot of improvement in GBDE and eventhough not that many reputable cryptographers have reviewed GBDE so far, those who have are very well respected, like Lucky Green, for example. I hope you will find the time to write an analysis of the weaknesses you found, I would be very interested in seeing if they would apply to what I have in mind. ALeine ___________________________________________________________________ WebMail FREE http://mail.austrosearch.net