Using EC (and specifically SECP256K1) for TLS w/ twisted or txsni

[jMyles]

Hey @glyph. Hope you're well, man.

I'm not sure where to open this issue.

We talked for a bit in #twisted - since then, I've done a fair bit of homework.

My current conclusion is:

• txsni works with RSA keys generated by cryptography (obviously)
• txsni works with SECP256R1 keys generated by cryptography (wow!)
• txsni does not work with SECP256K1 keys generated by cryptography (bummer.)

For my use case (and, I think pretty much any blockchain use case), SECP256K1 is a must.

FWIW, RFC4492 does list both these curves as valid for TLS: https://tools.ietf.org/html/rfc4492#section-5.1.1

Now, it's obvious that this issue is not with txsni - I get exactly the same result trying to use SSL4ServerEndpoint (ie, _lib.SSL_do_handshake(self._ssl) returns -1).

I'm interested in system wherein a user can generate a cert, sign it with her blockchain keypair (say, ethereum wallet key) and then use that in TLS negotiations for a distributed application. Combined with your SO answer about authentication w/ Twisted (here: https://stackoverflow.com/a/28682511/479449), this can be a great way for nodes in a distributed app to perform TLS and authenticate each other without a CA.

I'm this close to a HendrixDeploy object that will do that, but this issue is in my way. I'm not sure what stones to turn over next.

[glyph]

This would more properly be a bug in Twisted: txsni is just a little convenience wrapper around the APIs there, and knows nothing about the format of a key, only that it is a key.

I honestly don’t know a whole lot about curve selection and it doesn’t make sense to me that this doesn’t just work automatically, given that this information is already encoded in the key?

In any case, I’m going to close this here since it’s not clear there’s even anything txsni could do.