[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AES Key Integrity
> On Tue, 26 Jun 2001, Chris Trobridge wrote:
>
> > It has just occurred to me that I've not noticed any references to a
> > standard integrity mechanism for AES.
> >
> > Will there be one?
> >
> > DES has parity, but a CRC would be better.
> >
> > As crypto gets (theoretically) stronger issues like
> reliability become much
> > more important.
>
> This is an important issue, but it does not (and should not)
> depend on the concrete algorithm like AES. The subscribers from NIST to
> this list might want to consider adopting a standard for storing
> cryptographic keys (of any algorithm) for increasing reliability.
Agreed.
> Of course, standard here is mainly needed for interoperability:
That's really what I'm thinking about. While there aren't a lot of direct
transfers of keys between IPSEC instances (pre-shared and multicast cases?),
there will be standard crypto libraries that should include key integrity.
In most cases we check the key integrity in the crypto-hardware when the key
is loaded, so this would involve the chip designers.
> All you need is an error-correcting code (ECC) together with an optional
> (keyed?) hash. (Unkeyed hash does not really seem to be necessary if one
> already employes an ECC.)
> For most of the purposes a very simple ECC like Hamming code is good
enough.
Yes. I've not come across ECC on keys - I think that the rational may be
that its better to detect and discard corrupted keys (and generate new ones)
than correct keys with a lower probability of success. Of course if you're
not in a position to renogotiate then ECC is clearly the better option.
> Helger
> PS What a nice scary signature...
Quite! I'm afraid there's nothing I can do about it - it's added somewhere
downstream...
Chris
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.