Closed etcimon closed 8 years ago
X25519 comes from the Curve25519 key type (curve25519.h) not via the generic ECC code. This is intentional and unlikely to change. First, because X25519 has a fast and side channel safe implementation specific for that curve, running it through the Weierstrass code would be a bad idea. And I expect that X25519/Ed25519 (and X448/Ed448) are effectively the last EC algorithms we'll ever need and will have dedicated implementations, and so I want to expose them as specific types, with the idea that eventually applications only using modern curves will be able to disable the generic ECC code entirely.
So X25519 kex is not as easy as adding the PEM, but is pretty straightforward I think. You'll just need to special case the TLS code when computing ECDH with this curve and use the Curve25519 key types instead of the ECDH keys. To point you at specific areas you'll need to add a conditional and some x25519 specific code - tls/msg_client_kex.cpp around lines 157-167 for creating the right public key type, and tls/msg_server_kex.cpp around line 74-88 you'll need to set m_kex_key to a Curve25519_PrivateKey. Hope this makes sense, let me know if you have questions.
Sounds good. It looks like they also removed the "uncompressed point" byte, so I don't see it going through DER/BER and it'll be a length-bytes tuple. Though I've been reading around to confirm this: since the point is scalar it's just a matter of using those bytes directly as the shared secret? Or do I need to decode/encode it using the X25519 algorithms mentioned in the RFC (which seem to be in donna). I'm wondering because the test vectors aren't in Botan yet
Added x25519 TLS key exchange in #673, closing
Who stole my ticket Master account sincerely Brady lee fischer anyone wanna tell me what a gift tube is
I'd like to try my luck with X22519 KEX, it looks like it should be just a PEM addition in the EC_Group class. Did you have any particular roadblocks in sight for it? Perhaps it would be more specialized?