AES256 & AES192. (Was: Can I revitalise an old key-pair?)

[Nicholas Cole]

On Tuesday, 3 September 2013, Nicholas Cole wrote:

> On Tue, Sep 3, 2013 at 10:07 AM, Pete Stephenson <pete at heypete.com<javascript:;>>
> wrote:
> > On Mon, Sep 2, 2013 at 8:28 PM, Nicholas Cole <nicholas.cole at gmail.com<javascript:;>>
> wrote:
> >> On Mon, Sep 2, 2013 at 5:04 AM, Henry Hertz Hobbit
> >> <hhhobbit at securemecca.net <javascript:;>> 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?
> >
> > Even more importantly, were they ever an issue with GnuPG in the first
> place?
> >
> > That is, does GnuPG generate related keys?
> >
> > I was always under the impression that GnuPG randomly generated
> > session keys rather than creating related session keys; if true,
> > wouldn't this mean that the related-key attack doesn't apply?
>
> And if that were true, I presume that would mean that the "AES is
> stronger than AES256" argument would also fall. Or have I
> misunderstood?
>

While reading up on all of this I found this piece (concerning a very
widely used piece of software for Mac OS and iOS) on the switch to AES256.
I thought others would find it useful.

http://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130903/c8833cce/attachment.html>