AES256 & AES192. (Was: Can I revitalise an old key-pair?)
Henry Hertz Hobbit
hhhobbit at securemecca.net
Tue Sep 3 00:36:28 CEST 2013
On 09/02/2013 06:28 PM, Nicholas Cole wrote:
> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit
> <hhhobbit at 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
More information about the Gnupg-users
mailing list