RE: New version: draft-green-secsh-ecc-06

[James Blaisdell <JBlaisdell%mocana.com@localhost>]

Hello,

For my implementation, it would be trivial to have some ECDH/ECDSA methods name with ASCII OID, an English name, or a Base64 encoded OID.  I would imagine most people would use a table driven model, as we have done.  The first field is debug string name, second is the on the wire algo negotiation string, length of algo string, etc.  I simply need to change that one field, so mixing would be fine --- some could use one naming convention and others could use the base64 for future proofing.  

Here is a row from my table:

    { (sbyte *)"ecdh-sha2-secp521r1", (sbyte *)"ecdh-sha2-h/SsxnLCtRBh7I9ATyeB3A==",   34, cid_EC_P521, &ecdhMethods,      &sshHandshakeSHA512, secp521r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH },

Here are the beauty contestants:
    { (sbyte *)"ecdh-sha2-secp256r1", (sbyte *)"ecdh-sha2-scep256r1",                  19, cid_EC_P256, &ecdhMethods,      &sshHandshakeSHA256, secp256r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH },
    { (sbyte *)"ecdh-sha2-secp256r1", (sbyte *)"ecdh-sha2-1.2.840.10045.3.1.7",        29, cid_EC_P256, &ecdhMethods,      &sshHandshakeSHA256, secp256r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH },
    { (sbyte *)"ecdh-sha2-secp256r1", (sbyte *)"ecdh-sha2-9UzNcgwTlEnSCECZa7V1mw==",   34, cid_EC_P256, &ecdhMethods,      &sshHandshakeSHA256, secp256r1_OID, kTransReceiveECDH, kReduxTransReceiveECDH },

With table driven approach, I can actually leave all three of these naming conventions in the same table.  Mixing would be fine.  This seems to be more of cosmetic question than technical issue.  Is it A, B or C?  

Thank you,

James

-----Original Message-----
From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Peter Gutmann
Sent: Wednesday, April 15, 2009 5:50 AM
To: douglas%stebila.ca@localhost; jhutz%cmu.edu@localhost; pgut001%cs.auckland.ac.nz@localhost
Cc: djm%mindrot.org@localhost; ietf-ssh%NetBSD.org@localhost
Subject: Re: New version: draft-green-secsh-ecc-06

Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:

>It would be fine to name the kex methods by names, if there are such, but
>using an OID encoded in ASCII won't work; OID's can be arbitrarily long and
>you'll quickly run out of space.

They can in theory be arbitrarily long, but no-one ever uses them that way,
the longest ones that I'm aware of in crypto use are 20-25 characters, which
puts the extreme, worst-case OIDs in the same range as standard MD5-in-ASCII.

If they're OIDs encoded as ASCII then if someone sends you a new value that
you've never seen before all you need to do is cut and paste it into Google to
find the curve.  If you put the binary value through a *one-way* hash function
there's no way you can ever figure out what some string of base64 that you're
seeing actually started out as, and therefore no way to locate the curve
unless you've already got a copy to hand whose hash you can compare with (and
even then you need to do a brute-force search to figure out which value's hash
you're seeing).  Non-reversible hash functions are great for what they were
designed for, creating fingerprints of documents for signing.  They're less
useful when you need to map them back to the data they were created from.

Peter.