On Wed, Jan 01, 2014, Kyle Hamilton wrote: > Curve25519 public keys are 32-byte strings of digits. Private keys are > 32-byte strings of digits. The agreement algorithm doesn't use the Y > coordinate at all. >
By itself that isn't enough. We need a way to encode those digits in a PKCS#8 sttucture and a SubjectPublicKeyInfo structure. If Curve25519 was treated in a way similar to existing curves you'd just need another standardised namedCurve OID (as was the case with brainPool). Then the existing routines would handle encode and decode just fine. Curve25519 differs from other ECC curves in a number of ways, not least of which is that the y component is not used. That probably makes it incompatible with RFC5480 unless you kludge it to include y anyway. So Curve25519 needs a standard OID and some notes on the format to use for ASN.1. Does such a thing exist? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
