On 10/19/2016 11:34 AM, Leonard den Ottolander wrote:> Hello Gordon, >*snip*> > Personally I would be more concerned whether or not to enable ECDSA > algorithms (https://blog.cr.yp.to/20140323-ecdsa.html). > > Regards, > Leonard. >For web server ECDSA certs is currently a concern because the only curves with popular support across browsers have parameters that were chosen for undocumented reasons. That doesn't mean they are vulnerable but there is a question. OpenSSH uses Curve25519 for ECDSA which has documented reasons for the parameters chosen and thus are far less likely to be nefariously chosen. At least that's my understanding of the situation, which could be flawed.
Alice Wonder wrote:> On 10/19/2016 11:34 AM, Leonard den Ottolander wrote: >> Hello Gordon, >> > *snip* >> >> Personally I would be more concerned whether or not to enable ECDSA >> algorithms (https://blog.cr.yp.to/20140323-ecdsa.html). >> > For web server ECDSA certs is currently a concern because the only > curves with popular support across browsers have parameters that were > chosen for undocumented reasons. > > That doesn't mean they are vulnerable but there is a question. > > OpenSSH uses Curve25519 for ECDSA which has documented reasons for the > parameters chosen and thus are far less likely to be nefariously chosen. > > At least that's my understanding of the situation, which could be flawed.Oh, are those the ones with the NSA backdoor curve? mark
On 10/19/2016 01:54 PM, m.roth at 5-cent.us wrote:> Alice Wonder wrote: >> On 10/19/2016 11:34 AM, Leonard den Ottolander wrote: >>> Hello Gordon, >>> >> *snip* >>> >>> Personally I would be more concerned whether or not to enable ECDSA >>> algorithms (https://blog.cr.yp.to/20140323-ecdsa.html). >>> >> For web server ECDSA certs is currently a concern because the only >> curves with popular support across browsers have parameters that were >> chosen for undocumented reasons. >> >> That doesn't mean they are vulnerable but there is a question. >> >> OpenSSH uses Curve25519 for ECDSA which has documented reasons for the >> parameters chosen and thus are far less likely to be nefariously chosen. >> >> At least that's my understanding of the situation, which could be flawed. > > Oh, are those the ones with the NSA backdoor curve? >Allegedly they might. I use ecdsa certs on most of my websites, using secp384r1 I formerly used secp521r1 but suddenly Google with no warning stopped supporting it in chrome. That company is too powerful. The only other option (that has both browser and CA support) is prime256v1 Hopefully soon we will get a better option. I don't believe it is an issue with OpenSSH though.
Hello Alice, On Wed, 2016-10-19 at 13:40 -0700, Alice Wonder wrote:> On 10/19/2016 11:34 AM, Leonard den Ottolander wrote: > > Personally I would be more concerned whether or not to enable ECDSA > > algorithms (https://blog.cr.yp.to/20140323-ecdsa.html).> For web server ECDSA certs is currently a concern because the only > curves with popular support across browsers have parameters that were > chosen for undocumented reasons. > > That doesn't mean they are vulnerable but there is a question. > > OpenSSH uses Curve25519 for ECDSA which has documented reasons for the > parameters chosen and thus are far less likely to be nefariously chosen. > > At least that's my understanding of the situation, which could be flawed.The point Bernstein makes in the article I referenced is not so much that the NIST curves are suspect (for the reasons you mention) but the fact that the ECDSA algorithm itself is such that it is virtually impossible to implement in such a way that the code uses constant time. This opens the door for side channel (timing) attacks. The fact that you use a "nothing up my sleeve" curve does not change that fact. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research
Hi, On Thu, 2016-10-20 at 13:47 +0200, Leonard den Ottolander wrote:> The point Bernstein makes in the article I referenced is not so much > that the NIST curves are suspect (for the reasons you mention) but the > fact that the ECDSA algorithm itself is such that it is virtually > impossible to implement in such a way that the code uses constant time. > This opens the door for side channel (timing) attacks. The fact that you > use a "nothing up my sleeve" curve does not change that fact.Rereading the article I'm not sure again if my last statement is correct... Perhaps Bernsteins objections against ECDSA are against ECDSA +NIST-curves (because those use parameters that make a constant time implementation hard?) and not vs ECDSA as such. "Every natural implementation of ECDSA" is a bit ambiguous in this respect... Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research