3 ms·

My feeling is that there has been a change in crypto. It seems in the past, crypto was a la carte. Over time, this has been shown to open up a big security vul

My feeling is that there has been a change in crypto. It seems in the past, crypto was a la carte. Over time, this has been shown to open up a big security vulnerabilities such as this one, and also issues with key agility in TLS, etc. I think the tendency today is to make make crypto more omakase where there are a few well studied, well implemented algorithms that you use for everything. The Windows CryptoAPI is from that older time.

WorldMaker 7y ago
A small part of the problem is that the omakase options do change over time with changes in threat models and knowledge of vulnerabilities. One example is the recent push away from the NIST Curves to the more open knowledge Curve 25519, in part because of reasonable concerns that the NIST Curves were backdoored by NSA for easier cryptoanalysis. So you still need "low level" a la carte tools underlying and backing the omakase experiences. Part of the problem of the Windows CryptoAPI in question is that it has to serve "both customers", the omakase sort that need the best option, and the a la carte needs to higher level tools serving as the omakase option. That is, for some traditional/legacy C/C++ users that CrpytoAPI is about as high level as they will get, and it's up to the documentation to steer its consumers to the best omakase options. But crypto32.dll also is the low-level backend of tools like WinRT's Windows.Security.Cryptography and .NET's System.Security.Cryptography (on Windows). The push towards omakase and somewhat getting applications away from micromanaging the a la carte stuff, definitely seems the smart path. Handling the onion of it all in what needs to be supported at a low level to keep the high level omakase shop running smooth seems like it still has a lot of pitfalls.
- tptacek 7y ago
  Without addressing the thing about the NIST P-curves being backdoored, which is an extremely dubious proposition, I'll just say that whether you trust NIST or not, nobody should be using custom curves with TLS. Cryptographers have spent an inordinate amount of time working out, proposing, and competing with each other about what the best curves are, and what the best mechanisms for generating them are, and there are a wealth of named curves to pick from. I'd be happier if nobody used the P-curves (they're unsafe for other reasons). But that's got nothing to do with whether people should literally be plugging their own Weierstrass coefficients and base points into X.509. Standards should immediately deprecate support for explicit curve parameters.
  - WorldMaker 7y ago
    > Without addressing the thing about the NIST P-curves being backdoored, which is an extremely dubious proposition I don't believe it exactly either, I just know it as a zeitgeist reason why some of the dialog about curve changes has been happening. In hindsight I supposed I'd have been better off not mentioning it. > Standards should immediately deprecate support for explicit curve parameters. I agree and that wasn't the intent of my post, if it came across that way. While elsewhere in the thread it is mentioned that many named curves are implemented standalone, my understanding is that not all of them are. I was only suggesting that crypto32.dll is intended to be low level enough that it is possible that some of the higher-level APIs that Microsoft has built that do focus on named curves only (such as the UWP/WinRT and .NET APIs I mentioned) may rely on the explicit parameter support in the lower level library. I don't envy Microsoft the task of balancing what is in a low-level API like that versus backwards compatibility, "upwards" compatibility with high level components, etc.

WorldMaker 7y ago

A small part of the problem is that the omakase options do change over time with changes in threat models and knowledge of vulnerabilities. One example is the recent push away from the NIST Curves to the more open knowledge Curve 25519, in part because of reasonable concerns that the NIST Curves were backdoored by NSA for easier cryptoanalysis. So you still need "low level" a la carte tools underlying and backing the omakase experiences. Part of the problem of the Windows CryptoAPI in question is that it has to serve "both customers", the omakase sort that need the best option, and the a la carte needs to higher level tools serving as the omakase option. That is, for some traditional/legacy C/C++ users that CrpytoAPI is about as high level as they will get, and it's up to the documentation to steer its consumers to the best omakase options. But crypto32.dll also is the low-level backend of tools like WinRT's Windows.Security.Cryptography and .NET's System.Security.Cryptography (on Windows). The push towards omakase and somewhat getting applications away from micromanaging the a la carte stuff, definitely seems the smart path. Handling the onion of it all in what needs to be supported at a low level to keep the high level omakase shop running smooth seems like it still has a lot of pitfalls.

tptacek 7y ago
Without addressing the thing about the NIST P-curves being backdoored, which is an extremely dubious proposition, I'll just say that whether you trust NIST or not, nobody should be using custom curves with TLS. Cryptographers have spent an inordinate amount of time working out, proposing, and competing with each other about what the best curves are, and what the best mechanisms for generating them are, and there are a wealth of named curves to pick from. I'd be happier if nobody used the P-curves (they're unsafe for other reasons). But that's got nothing to do with whether people should literally be plugging their own Weierstrass coefficients and base points into X.509. Standards should immediately deprecate support for explicit curve parameters.
- WorldMaker 7y ago
  > Without addressing the thing about the NIST P-curves being backdoored, which is an extremely dubious proposition I don't believe it exactly either, I just know it as a zeitgeist reason why some of the dialog about curve changes has been happening. In hindsight I supposed I'd have been better off not mentioning it. > Standards should immediately deprecate support for explicit curve parameters. I agree and that wasn't the intent of my post, if it came across that way. While elsewhere in the thread it is mentioned that many named curves are implemented standalone, my understanding is that not all of them are. I was only suggesting that crypto32.dll is intended to be low level enough that it is possible that some of the higher-level APIs that Microsoft has built that do focus on named curves only (such as the UWP/WinRT and .NET APIs I mentioned) may rely on the explicit parameter support in the lower level library. I don't envy Microsoft the task of balancing what is in a low-level API like that versus backwards compatibility, "upwards" compatibility with high level components, etc.