5 ms·

So, Mr Smith wants to add a bunch of elliptic curve options (using the NIST curves, weakest P-256 first), while removing the widely used TLS_RSA_WITH_AES_256_CB

by ott2 13y ago

So, Mr Smith wants to add a bunch of elliptic curve options (using the NIST curves, weakest P-256 first), while removing the widely used TLS_RSA_WITH_AES_256_CBC_SHA256 due to "concerns" about "performance" and an unsubstantiated argument that ephemeral key exchange is somehow always better. Hmm.

bsullivan01 13y ago
Beware of random cryptographers bearing suggestions? #HUMINT
- ott2 13y ago
  Some of the OpenSSH and IETF mailing list archives about SSH also make interesting reading. Exactly why does RFC 4253 mandate Group 1 and Group 14 as the only required key exchange mechanisms? (They were defined by RFC 2412, written by someone who was "assigned to the DARPA Information Technology Office".) However, perhaps it would be better to fork a separate thread for such speculations.
- jwr 13y ago
  I really hope TLS crypto standards won't be set (or changes rejected) based on who proposed a particular change. Changes should stand on their own merits. I don't see why we should trust anyone, random or not. It's not about trusting people, it's about trusting algorithms. So it doesn't really matter who in particular proposes changes.
  - bsullivan01 13y ago
    In a ideal world, but if you get a lot of "contributions" some might slip through. Remember, no one can match NSA's budget, manpower and maybe brainpower.
hnolable 13y ago
TLS_RSA_WITH_AES_256_CBC_SHA256 is not forward secret (if you have the certificate private key you can passively decrypt all past/future sessions) so removing it is a great idea. I'm only responding to what you said and not making a judgement about the rest of the guy's suggestions.
tptacek 13y ago
Mr. Smith joins pretty much the entire mainstream of cryptography in urging people to switch away from RSA and towards ECC. The NIST P-256 curve is the most common ECC curve used. It was generated by picking a prime that is fast to compute with and hashing a string with SHA-1.
- sanxiyn 13y ago
  As djb pointed out in "Security dangers of the NIST curves", SHA-1 does not prove much. If NSA knows a weak class of curves, they try as many strings as they want until SHA-1 of the string hits a weak curve.
  - tptacek 13y ago
    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.
    - acqq 13y ago
      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?
      - tptacek 13y ago
        The standard provides a standard set of curve parameters and a NIST-sanctioned way of generating new curve parameters using the exact same method.
        acqq 13y ago
        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?

by ott2 13y ago

bsullivan01 13y ago

Beware of random cryptographers bearing suggestions? #HUMINT

ott2 13y ago
Some of the OpenSSH and IETF mailing list archives about SSH also make interesting reading. Exactly why does RFC 4253 mandate Group 1 and Group 14 as the only required key exchange mechanisms? (They were defined by RFC 2412, written by someone who was "assigned to the DARPA Information Technology Office".) However, perhaps it would be better to fork a separate thread for such speculations.
jwr 13y ago
I really hope TLS crypto standards won't be set (or changes rejected) based on who proposed a particular change. Changes should stand on their own merits. I don't see why we should trust anyone, random or not. It's not about trusting people, it's about trusting algorithms. So it doesn't really matter who in particular proposes changes.
- bsullivan01 13y ago
  In a ideal world, but if you get a lot of "contributions" some might slip through. Remember, no one can match NSA's budget, manpower and maybe brainpower.

hnolable 13y ago

TLS_RSA_WITH_AES_256_CBC_SHA256 is not forward secret (if you have the certificate private key you can passively decrypt all past/future sessions) so removing it is a great idea. I'm only responding to what you said and not making a judgement about the rest of the guy's suggestions.

tptacek 13y ago

Mr. Smith joins pretty much the entire mainstream of cryptography in urging people to switch away from RSA and towards ECC. The NIST P-256 curve is the most common ECC curve used. It was generated by picking a prime that is fast to compute with and hashing a string with SHA-1.

sanxiyn 13y ago
As djb pointed out in "Security dangers of the NIST curves", SHA-1 does not prove much. If NSA knows a weak class of curves, they try as many strings as they want until SHA-1 of the string hits a weak curve.
- tptacek 13y ago
  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.
  - acqq 13y ago
    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?
    - tptacek 13y ago
      The standard provides a standard set of curve parameters and a NIST-sanctioned way of generating new curve parameters using the exact same method.
      - acqq 13y ago
        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?