Elliptic Curve Diffie-Hellman

re: Elliptic Curve Diffie-Hellman

Pieter Philippaerts — Wed, 24 Jan 2007 02:35:02 GMT

Ugh :-/ It's the whole RSA catastrophy all over again...

Remember that CAPI only allowed to use the standard RSA paddings PKCS#1.5 and OAEP, and this caused a few problems for you guys when implementing the .NET wrappers. .NET has a clean RSA architecture with its barebones RSA descendants, and the higher-level formatter classes, but because of the way the CryptoAPI was designed you had to implement silly workarounds to get the thing working (RSACryptoServiceProvider.EncryptValue that always throws an exception for instance).

This ECDH implementation has essentially the same problem: what if I need to implement a different key derivation function? Since I can't access the bare output bits of the ECDH algorithm, there's nothing much I can do with this class...

There is a difference however. With the advent of the .NET framework v1.0, Microsoft had finally done it right. I really like the RSA architecture. When someone creates their own RSA implementation, they can simply plug it into the framework, and all the different paddings will immediately work.

However, the ECDiffieHellmanCng class appears to go the other way: a simple enum to select the key derivation function. That was not exactly the handsome OO architecture I was hoping for :-/ When the CNG API in Windows Vnext finally allows us to access the raw bits, we'll be stuck in .NET with this design decision.

I realize that this decision was most likely made because of the current CNG architecture, and that you guys are probably trying to save yourself some time by not having to duplicate the key derivation code in .NET (unlike the RSA padding code, which is duplicated in the .NET runtime). But do realize that this design decision might come back to haunt you within this and 10 years.

As a side note, can you explain where those three key derivation functions come from? I must admit I'm not exactly an ECDH expert, but I don't know of too many standards that use ECDH. So isn't it a bit early to declare there three key derivation functions as the de facto standards? In fact, I could only find the ANSI X9.63 key dervation function as a standard ECDH key derivation function (and this algorithm doesn't seem to correspond to any of the supported algorithms by CNG), so what happens if different standards begin to use ANSI X9.63?

Likewise, the TLS PRF option already seems to be outdated before CNG was even released. The current TLS 1.2 standard specifies a different PRF that allows for any hash function to be used.

Supporting all these different key derivation functions would be much easier if we had a plug-in system like the RSA classes (and if we could access the raw bits of the ECDH calculation, of course).

I realize that the tone in this post is somewhat negative, but dont't get me wrong: I'm really excited to see these new things happen in the Windows and the .NET crypto API. I'm just a bit disappointed that this same mistake has been made twice...

re: Elliptic Curve Diffie-Hellman

shawnfa — Thu, 25 Jan 2007 02:42:33 GMT

Hi Pieter,

Thanks for your feedback! Let me try to address some of your comments:

In this post I was talking about the ECDiffieHellmanCng class, which is roughly the equivilent to RSACryptoServiceProvider in the RSA hierarchy. There is also an ECDiffieHellman base class which is the analog of RSA - namely it defines only the basic operations, and you can inherit new implementation classes if you want. The base class simply has to be able to export its public key, and be able to generate a byte array given another party's public key.

You guessed correctly that the enum for the KDF is based around CNG. There's different structures we need to pass through depending on the KDF selected, and therefore we couldn't make it extensible like the other pseudo-enum string extensibility points. However, we do also provide a way around this. In addition to DeriveKeyMaterial, ECDSACNG provides a method DeriveSecretAgreement which returns back the CNG handle to the secret agreement. If CNG v2 allows you to use a new KDF that we haven't yet wrapped or lets you get at the raw secret agreement directly, you can then P/Invoke with that handle to access the data.

By exposing the secret agreement handle, we let you do just the last part of the P/Invokes rather than have to throw away the whole class and do all of them, which tends to be the case with our RSA class.

Not being able to get the raw secret agreement is enforced at the CNG layer, and not at the managed wrappers. When I was talking to the CNG guys during the design of this class, it turns out that this was by request from some certifications they were going through (although I don't recall all the details at this time).

If, when you're playing around with these classes, you find that you do have some more feedback about the design, please share it here with me. We're always glad to revisit our APIs before we ship if there's something that we've msised.

-Shawn

re: Elliptic Curve Diffie-Hellman

Pieter Philippaerts — Thu, 25 Jan 2007 18:48:47 GMT

Shawn,

thanks for the answer. The fact that these decisions were made because of certification requirements explains a lot about the design of CNG (and probably the CryptoAPI too).

I still don't see why someone wouldn't allow access to the calculated bits (while at the same moment allowing access to the underlying key), but at least it's outside of Microsoft's control.