Date: Tue, 01 Mar 2005 19:45:34 -0500 From: Roland Dowdeswell <elric@imrryr.org> To: "ALeine" <aleine@austrosearch.net> Cc: tech-security@NetBSD.org Subject: Re: RFC: backporting GEOM to the 4.x branch Message-ID: <20050302004534.DFF6737012@arioch.imrryr.org> In-Reply-To: Your message of "Mon, 28 Feb 2005 17:45:15 PST." <200503010145.j211jF1s046188@marlena.vvi.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1109641515 seconds since the Beginning of the UNIX epoch "ALeine" wrote: > >> 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 But, I said that it requires less steps to brute force the entire disk not just some parts of the filesystem. Every last sector of a 512GB disk can be brute forced in 2^158 steps using the most naive method. All of the key-key sectors can be brute forced in 2^153 steps. This is much less than 2^256 which is what it would take to brute force 256 bit AES. So, until someone can crack 256 bit AES in < (2^25 * O(AES128)) steps, yes it is less secure. Or, one should say 256 bit AES with a lot of known plaintext in less than 2^25 * O(AES128). >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. I am not against adding complexity, just against adding needless complexity which has every appearance of introducing new methods of attacking the disk without appreciably increasing the cost of brute forcing it. CGD does contain a reasonable amount of complexity in some areas: 1. it has a modular mechanism for defining crypto algorithms, these do not need to be restricted to AES vs DES but could include things like ``GBDE'', 2. it takes care to turn passphrases into keys properly, and 3. it allows for the addition of new mechanisms to do (2). 4. etc. But, I also believe that one should solve first things first. That's why I put most of my effort into defeating dictionary attacks and making the sytem modular, etc. There is no point in worrying about what happens if someone breaks AES next year if you are putting out a system this year which can be compromised in months with a dictionary attack. Focus on the weakest links first and right now AES is not the weakest link. There is little point in replacing your front door with a steel reinforced door if all of your windows are open. >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. But, you do not have to break the structured multilayered mechanism at all. You can just brute force each sector one by one in much less than 2^384 steps and hence the claim is both trivially and obviously false. Or just crack one key-key sector in 2^128, reverse the MD5 in 2^128 to obtain the salt and get the rest of the disk in < 2^128, for a grand total of O(2^129). Together these methods seem to indicate that 2^384 is a little exaggerated. -- Roland Dowdeswell http://www.Imrryr.ORG/~elric/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050302004534.DFF6737012>