Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [P1619-3] Algorithm Equivalancy

Matt & Landon,
You are right on ECC and RC4. RC4 was left in by mistake and I wasn't paying attention when I typed ECC 512 values and I knew better. I know we don't need RC4 algorithm as I don't know of any uses for storage. DES may be another matter and we should look for feedback on legacy keys that may still be in active or have a required retention for some unknown reason.
As for equivalence, it is the wrong term. The first way (as I should have called it) is used by NIST and they refer to it as bit strength. The second option is to assign levels and have specific key lengths at each level. This is for centralized policy management purposes when allowing devices to generate their own keys if that is the end users requirement. Mostly this covers NIST encryption requirements in the future with minimum key lengths. They do currently have dates associated with various bit strengths which would seem to imply that if you have really long term data retention requirements you must use longer keys to stay in compliance.
Personally I don't care what we call it as long as we include it in the policy section as an optional policy type (key length or key strength policy works for me too).
I will cover my ideas when I go over the sheet on Wednesday. For now I am going back to sleep since it is only 5:30am here. 

Bob L.

Matt Ball wrote:

Hi Bob,

Thanks for your work in putting this together!
As Landon said, the ECC entry should be 521 instead of 512. This is a common mistake, because 521 looks so much like a typo, that the computer scientist's brain almost automatically translates it to 512 without thinking. However, 521 (or rather 2^521-1) happens to be a convenient Mersenne Prime that was all but too tempting to the ECC developers. This has caused untold trouble to those who like nice powers of 2, but there you have it.
I personally don't like mixing the concepts of 'algorithms' (like AES), with modes of operation. As I've said before, stating a cipher without a mode-of-operation, while useful to the marketing people, is not really useful to a developer or implementer.
I hope we don't have to include RC4. The effective strength is well below the key size. (NOTE: this is a stream cipher, going against the last note that states "This list does no include stream ciphers")
I also hope we don't need DES. I could maybe see including 2 or 3 key TDES, but my preference is to remove these also.
The "effective key strength" of the HMAC section seems strange. Why doesn't this just match the "generated number of bits"? There's probably some context that's missing here 

Cheers,
-Matt
On Sun, Jan 11, 2009 at 2:46 AM, Landon Curt Noll <p1619.3-mail@xxxxxxxxx <mailto:p1619.3-mail@xxxxxxxxx>> wrote: 

    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/\




--
Thanks!
-Matt

Matt Ball, IEEE P1619.x SISWG Chair
Cell: 303-717-2717
http://www.linkedin.com/in/matthewvball
http://www.mavaball.net/