Re: [P1619-3] Algorithm Equivalancy
> -----Original Message-----
> From: Landon Curt Noll [mailto:p1619.3-mail@xxxxxxxxx]
> Sent: Sunday, January 11, 2009 1:46 AM
> To: P1619-3@xxxxxxxxxxxxxxxxx
> Subject: Re: [P1619-3] Algorithm Equivalancy
>
> On 2009-Jan-10, at 23:11, Robert A. (Bob) Lockhart wrote:
>
> > The attached file contains a list of a majority of algorithms used
> > in storage applications. We will cover what we need to consider for
> > the standard and how we should handle algorithms versus modes.
>
>
> Bob,
>
> The RSA Key composition values are in error.
>
> Isn't largest ECC should be ECC-521 (not 512)?
>
> I also recommend dropping the "Effective Key Strength" column as it
> contains some values that are in error, that are subject to debate
> (and do we need to debate that here?), and may give a misleading
> impression of Algorithm equivalency.
>
> chongo () /\oo/\
I believe that information about the bit strength is very relevant. The two biggest markets for encryption, government and financial services, have definitions for bit strength that's needed to be in compliance with their needs. This is reflected in the NIST SP series as well as the ASC X9 standards. So while there may be some debate over exactly how many bits are needed to create a certain level of strength, the biggest customers have clearly defined how many bits they need. Following these requirements is what's needed to get FIPS 140-2 validated, for example. And while 3072 bits of RSA key may or may not be the same strength as a 128-bit AES key, customers use that equivalence, which makes it good enough for me.
So while cryptographers may endlessly debate exactly how many bits are needed in various situations, most customers don't, and having a reference that shows the customer requirements is probably very useful. Using the same terminology as SP 800-57 Part 1 ("bits of security," IIRC) and using it as a reference might be a good way to handle this.