[Twisted-Python] Elliptic Curve support

[Thedore Oidelson]

Glyph, I understand your and other's concerns, and while clearly I feel a
little differently, my real concern was how the curves I was using were
suddenly not supported at all. Which is why I think the API you and Tobias
suggested is a good compromise.

I have the code to do this just about ready and will submit a ticket and PR
shortly.

On Mon, Apr 17, 2017 at 10:28 PM, Glyph Lefkowitz <glyph at twistedmatrix.com>
wrote:

>
> 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
>
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20170418/5c447751/attachment-0002.html>