<div dir="ltr">I'm taking Glyph's suggestion and bringing this to the mailing list. :)<div><br></div><div>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.</div><div><br></div><div>*  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.</div><div><br></div><div>*  These are all curves suggested in RFC 5656, and I believe the more Twisted supports the RFC the better.</div><div><br></div><div>*  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.</div><div><br></div><div>* Having extra curves does not make Twisted less secure.  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.</div><div><br></div><div>There are other reasons why I think it makes sense to have the curves in Twisted but these are the main ones.</div></div>