On 09/02/2013 06:28 PM, Nicholas Cole wrote: > On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit > <hhhob...@securemecca.net> wrote: > > [snip] > >> >> Paradoxically, AES256 & AES192 had >> weaknesses that made them less safe than AES (AES-128) several >> years back. May I humbly suggest TWOFISH or one of the >> CAMELLLIA ciphers as a first choice UNTIL you determine whether >> or not the fixes for AES-256 and AES-192 are retroactive? DID >> THEY GET THEM FIXED? I am just assuming they did but that means >> I HOPE the older implementation and the newer one can easily be >> discerned when you do the decipher. > > > [snip] > > I was curious about this. The wikipedia page mentions the "Related Key > Attack" on these cyphers, but is vague about whether they were ever > fixed. > > Does anyone know? > > And did fixes make it into the version used by Gnupg?
Short answer - it wasn't changed and Bruce Schneier still considers AES-128 to be more secure than AES-256. Now you can tap delete. It is time for Werner, Robert, and the others to speak up. I usually tailor my statements to novices just getting started. It is just that AES-256 is NOT necessarily twice as secure as AES-128. In fact going up in bits sometimes gets you only marginal improvements that are closer to logarithmic than straight line. But this time it seems AES-256 is STILL not as secure as AES (AES-128): First of Schneier's blogs: http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html Second of Schneier's blogs: http://www.schneier.com/blog/archives/2009/07/another_new_aes.html [Note that Serpent is referenced as a backup plan. If you look at Bruce's 1:22 PM comment he recommends AES-128 (AES) over AES-256 due to the poor key-schedule for AES-256. I changed my cipher order several weeks later with no evidence to the contrary. For novices you can do that any time you change your mind - but I have always had TWOFISH first despite his deprecating remarks about his own 32-bit world cipher.] Note the figures at the start of "Abstract". Even those are practically unbreakable. The quick fix was to use more rounds but my research is drawing a blank so I suspect nothing was done. Even so, infecting your machine or hacking into it somehow which may include personal visits and real world physical lock-picking is more likely to get them what they want than attacking any of these ciphers with ANY sort of cipher attack. There are also different ways for doing the AES family depending on where they are used with some being weaker implementations than others. E.g., in OpenSSL you cannot afford the luxury of a single machine munching away like it is in GnuPG which means GnuPG most likely has the strongest implementation of the AES family. It will be what ever is in the RFC: https://www.ietf.org/rfc/rfc4880.txt All I was pointing out was that AES-256 versus AES-128 does NOT imply AES-256 is twice as secure as AES-128. The idea that just because it is twice the size then it must be twice as secure is just a novice point of view. The quick fix was to use more rounds and I just assumed that may have been done. Evidently I assumed wrong. Most ciphers have known weaknesses. But there are lots of crypto people that work over-time on analyzing them for weaknesses. That includes a lot of people here who should speak up because they know more than me. I am too busy processing the three variants of the mini-downloader trojans and wondering why they delivered the almost same code all at once. They do a lot of experiments so it is probably to measure how much the same time reduces their effectivenes over spreading them out with as little as 8 hours or as much as 48 hours between each release. Only 1-2/47 of the AV at VirusTotal were detecting both the the zips and the exes. It takes a week or longer for detection to reach the halfway mark. Even after a month about 10-25% of the AV still won't detect and probably never will - Zeus variant mini-downloader. HHH _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users