Algorithm Names - registry?

Michael StJohns mstjohns at comcast.net
Wed Nov 30 18:34:48 PST 2011


The web page you pointed me at is a bit more up to date than what I was looking at.  To be honest, I couldn't find a path there from the public web pages - but that may be just me.

What I'm finding when playing with things like ZigBee, smart cards and other similar technologies is that there are some specific crypto modes, algorithms and functions that are implemented in various providers, but for which I need to go looking in the source code to find the specific incantation (name).  For example - BC uses ISO9797ALG3MACWITHISO7816-4PADDING as the tag for the MAC that's used for a number of functions in the SCP02 GlobalPlatform protocol.   There are a number of algorithms documented in the javacard jdk that have no standard names in the JCE (for example the Korean SEED algorithm).  There are also variants on named algorithms that don't have a standard name - for example the extension of AES key wrap that allows wrapping of variable length data (RFC5649).

Let's not even get into the whole host of GOST algorithms as well as the various candidate SHA3 algorithms.

Maybe there's two parts to this -  the first a standard way of deriving a name from the base standard (<algtype>_<standard short title>[_alg shortname[_algvariation]][/algoption])  =>   MAC_ISO9797_ALG3_MODE3/7816-4Padding.  It would take a number of worked examples to figure out if this were feasible.   That sets the standard for externally created names.  And then and only then a second part which takes the proposed names and adds them to the registry.

I hadn't contemplating letting just anyone write into the registry, but I was looking for something a bit more dynamic than the current system.

By the way - why are CCM and GCM ciphers rather than cipher modes in the table?  They can be applied to any block cipher (i think with a specific block length).

Mike


At 08:20 PM 11/29/2011, Brad Wetmore wrote:
>I'm just one person, but I'm completely open to discussing on security-dev potential names/values to add.  I do have strong hesitations about just opening it up to anyone to add something (i.e. a wiki), allowing them to reserve names with no discussion.  (I'm thinking what a mess it could be if there was no IETF-IANA.)
>
>The JDK 7 edition is at:
>
>http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html
>
>The current doc does have most of the items you're suggesting, but maybe not as structured.  A reformatting might be helpful.
>
>I would also hesitate including optional secondary names, as the point of a standard name is to settle on one name that can be used across implementations.  Having three possible aliases like for SHA1 (SHA-1, SHA1, SHA) just makes things confusing for end users.
>
>Hadn't really thought about adding Javacard algids here.  I know outside Oracle this shouldn't matter, but they're a completely different group.
>
>My $.02.
>
>Brad
>
>
>
>
>On 11/28/2011 10:30 AM, Michael StJohns wrote:
>>One of the items that seems terribly out of date is the "Standard Names" list.  Also, sometimes its difficult to tell which algorithm - specifically - the name applies to.
>>
>>I'm wondering if it isn't time to create something like a Wiki for name registration and - for example - let the folks building the various JCE providers add or propose names.  I mention this because I'm finding it tiresome looking through the BouncyCastle source code each time I need to find an algorithm name not on the list.
>>
>>I would suggest as data elements:
>>
>>Primary name, Optional secondary names; Object Identifier (if any); Applicable JCE class (e.g. Cipher, MessageDigest, etc), Primary standard (e.g. RFCXXXX, ISOXXXX - section yy, option zzz); Alternate standards (for example ECDSA is referenced in SECG, NIST, ANSI etc); clarifying comments (e.g. "Use IvAlgorithmParameter with this").
>>
>>
>>Continuing this thought - the Javacard algorithm identifiers could also be included in this table.
>>
>>Mike





More information about the security-dev mailing list