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.
djb has a fixed-clock-cycle algorithm he wrote in GNU assembly for Athlon. I am unhappy with his insistence that nobody should try to implement it for other platforms, as though Athlon is the only platform anyone would ever need. I agree that a platform-independent optimized arithmetic would be a good thing. I would also like to see (since I know nothing about x86, x86_64, or Athlon assembly language) its translation to a 64-bit ABI. But that's out of scope for this list. At this point, tls@ has been so thoroughly compromised by BULLRUN and well-meaning rank amateurs that no actual work can be forwarded without a preexisting implementation. Many of the issues cited with the curve25519 tls draft were spurious and irrelevant to its application and adoption; however, I have neither the knowledge to implement it myself or the funds to hire anyone to implement it. I'd throw what pittance I can at a Kickstarter for it, though. (To be clear: you need to know what digest you're feeding the 256 bits of curve25519 output through, and that might cause a curve25519-sha256, curve25519-sha384, etc ECDHE selection. It's also useful to note that the public key calculation is the output of the same curve25519 function with the specific public key parameter '9', and the function in djb's implementation is fast enough to generate on an Athlon a public key from a pseudorandom private key on connect().) -Kyle H On Jan 1, 2014 1:18 PM, "Dr. Stephen Henson" <st...@openssl.org> wrote: > On Wed, Jan 01, 2014, Daniel Kahn Gillmor wrote: > > > On 01/01/2014 03:45 PM, Kurt Roeckx wrote: > > > Hi, > > > > > > I recently ran into this: > > > http://safecurves.cr.yp.to/ > > > > > > It seems that openssl doesn't support any of the curves that are > > > listed there as safe. > > > > > > At least the curve 25519 is popular and has a draft for using it > > > in TLS. Would it be possible to add at least support for that > > > curve? > > > > I think you're referring to Simon Josefsson's draft: > > > > https://tools.ietf.org/html/draft-josefsson-tls-curve25519-01 > > > > IIRC, the discussion about that draft over on t...@ietf.org got a bit > > bogged down in the details of how to represent the points for this curve > > and other similar curves (e.g. curve3617): > > > > Yes that's a problem. > > Adding support for some curves just needs addition of the appropriate curve > parameters, OIDs and in the case of TLS the Named Curve values. > > Unfortunately for others (curve 25519 is of this type I believe) the > handling > of the curve needs to be treated as a special case. We'd need a way of > representing public keys in SubjectPublicKeyInfo (this the point > representation discussion), private keys in PKCS#8 format and ideally > optimised curve arithemetic to protect it from attack. > > 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 >
