[Twisted-Python] Elliptic Curve support

Glyph Lefkowitz glyph at twistedmatrix.com
Mon Apr 17 20:28:18 MDT 2017


> On Apr 17, 2017, at 9:46 AM, Thedore Oidelson <the0idelson at gmail.com> wrote:
> 
> I'm taking Glyph's suggestion and bringing this to the mailing list. :)

Thank you :).  Hopefully some people more qualified than me will comment...

> I still believe it was unwise to remove the support for the extra EC curves in PR #749 for a few reasons that I've said in a few different places so I'll summarize them here.

I have some arguments with the form of your argument here, but I should emphasize that I don't know enough about the specific underlying crypto to go one way or another - mostly I'm trusting the opinions of Alex Gaynor, and your counterpoints are not convincing (yet).

> *  Support for more curves is better.  It gives more options to users and developers such as myself who want to use Twisted for custom environments.  All of this widens the support base.

Not necessarily.  Support for more curves may allow or encourage the use of insecure curves by naive users.

> *  These are all curves suggested in RFC 5656, and I believe the more Twisted supports the RFC the better.

RFC 5656 is very old.  Specifically: pre-heartbleed, pre-snowden, pre-BULLRUN revelations.  Just because it's in that RFC is not a compelling argument for its inclusion.

> *  There are cases for using alternative curves.  NIST-T-571 is stronger than any of the currently supported curves.  NIST-K-163 is weaker, but there are still uses for it. I may be working in an embedded environment where every CPU cycle counts and I just need simple encryption to protect against simple plain text scanning.

These types of use-cases do not require these curves to be enabled by conch by default.  They just require there being a public API to enable these things.

> * Having extra curves does not make Twisted less secure.

If they are enabled by default, it very well can.

> SSH negotiates encryption based on a list of preferred ciphers.  We put the strongest ciphers first and the weaker curves only get used if nothing better is available where weak encryption is still better than no encryption.

Or if an adversary successfully executes a downgrade attack.

There's downgrade detection in SSH, but we shouldn't rely on it to be perfect.

> There are other reasons why I think it makes sense to have the curves in Twisted but these are the main ones.

I think it might be more productive to argue for the inclusion of individual curves on a case-by-case basis.  "should it be included at all" and "should it be enabled by default" are also separate questions.

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20170417/524b197f/attachment-0002.html>


More information about the Twisted-Python mailing list