Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove nistpxxx curve #668

wants to merge 2 commits into
base: stretch-unstable


Copy link

commented Mar 1, 2019

The problem

The website say that the curve nistp256, and nistp384 is not secure.

From some source, the NSA had backdoored Dual the curve NIST P-256.


Remove all of theses curves

PR Status

Not tested, but should work, with some other curves

How to test

Just update your ssh config


  • Principle agreement 0/2 :
  • Quick review 0/1 :
  • Simple test 0/1 :
  • Deep review 0/1 :

Josue-T added some commits Mar 1, 2019

Remove nistpxxx curve
It's known that nistp256, and nistp384 as a backdor, so remove it

This comment has been minimized.

Copy link

commented Mar 1, 2019

Thanks for providing a source for this.

Doing some research on my side, I still find that this is all very much political speculation about those ...

c.f. (ECDSA section) and which summarize the situation like this :

there are good reasons to favor Curve25519 and other implementation-friendly elliptic curves (namely, they are faster, and they are fewer ways of shooting yourself in the foot if you implement them), but "NIST curves are backdoored" is not a very serious one.

So it looks a lot like "oh somebody says the NSA might have been involved at some point in the design of these so we shouldn't use them at all" ... But from what I read, the most compelling thing here is the difficulty of implementing the curves in a safe way ... and that still doesn't convince me that much, because I tend to think that if we don't trust the implementations in the lib we use, then we have bigger issues ...

And also clearly I'm still reluctant to have our own custom security cooking instead of sticking to the recommendation from a trustable third-party ... To me the weakest point in our SSH config right now is the fact that login happens using passwords instead of public key authentication. Which ultimately boils down to the UX issue of "how do we get people to set up public key auth".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.