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

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

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.