News for hackers. Stuff that matters.
Re:Proposal to Change the Default TLS Ciphersuites Offered b... by tptacek on Sunday September 08, 2013 @10:30AM (#6348789)
It doesn't prove much; you can always just generate a new P-256-alike with the instructions NIST provided for you in that document.
Re:Proposal to Change the Default TLS Ciphersuites Offered b... by acqq on Sunday September 08, 2013 @11:47AM (#6349086)
Who can generate? Aren't the values fixed by the standards, mustn't both client and servers use the same as long as they support the given standard?
Re:Proposal to Change the Default TLS Ciphersuites Offered b... by tptacek on Sunday September 08, 2013 @02:24PM (#6349656)
The standard provides a standard set of curve parameters and a NIST-sanctioned way of generating new curve parameters using the exact same method.
Re:Proposal to Change the Default TLS Ciphersuites Offered b... by acqq on Sunday September 08, 2013 @02:51PM (#6349778)
How can be any other parameters than the standard ones used in the current browsers and servers? I think they can't, am I right?

And how can browsers start to use any other parameters before they standardise them? I think they can't?

Re:Proposal to Change the Default TLS Ciphersuites Offered b... by tptacek on Sunday September 08, 2013 @02:59PM (#6349820)
This is true but not particularly meaningful to me, because you can't really do anything new with crypto at all without some kind of software update. For instance, the primes and generator for conventional number theoretic DH are also pre-generated and baked into a standard.
Re:Proposal to Change the Default TLS Ciphersuites Offered b... by cryptbe on Sunday September 08, 2013 @01:57PM (#6349537)
So maybe we should generate our own curves. I propose something as follows:

1. Locate a public string. A tweet or a quote should suffice.

2. SHA-512 the string to obtain a seed.

3. Use that seed to generate b, and calculate N = #E(Fp) = n * h, and choose a base point P. Of course we need to ensure that these parameters are safe against known attacks.

4. Mandate that the new set of parameters MUST be supported wherever NIST prime curves are supported.

The last step is probably the most difficult. You don't need that if you don't need to interoperate with other implementations though.

Re:Proposal to Change the Default TLS Ciphersuites Offered b... by tptacek on Sunday September 08, 2013 @02:25PM (#6349663)
The only thing you want not to happen is for software to start generating and negotiating its own curves, because that then requires all interoperable implementations to parse and validate random curves from attackers.
Re:Proposal to Change the Default TLS Ciphersuites Offered b... by cryptbe on Sunday September 08, 2013 @05:43PM (#6350494)
No, I didn't say that everyone generates their own curves. I meant the security community should generate our own curves. Somebody should email Thomas Pornin.
Re:Proposal to Change the Default TLS Ciphersuites Offered b... by pbsd on Sunday September 08, 2013 @06:12PM (#6350627)
There are already several alternative curve sets, satisfying various degrees of paranoia:

- http://certivox.org/display/EXT/CertiVox+Standard+Curves

- http://tools.ietf.org/html/rfc5639

- curve25519 and the other djb et al curves.

Re:Proposal to Change the Default TLS Ciphersuites Offered b... by tptacek on Sunday September 08, 2013 @05:53PM (#6350527)
Sorry, I didn't mean to imply you were saying that.