CURDLE and Cryptographic algorithm APIs / selection

[hallambaker]

One of the major problem areas in .NET at present is the organization and algorithm selection for cryptography. In particular:

• .NET 4.6 does not supply many of the preferred algorithms for IETF protocols
• The organization of the APIs is haphazard and inconsistent.

I know that there are several comments on this and an expectation that 'something' will be done. I would like to make some suggestions.

First, for algorithm selection, note that IETF just started a call for comments on a new working group to choose a consistent set of algorithms for use in IETF protocols. So the idea is that S/MIME, TLS, SSH, OpenPGP, etc. all use the same set of algorithms.

This is not a completely open ended process either as pretty much anyone involved in that process can tell you right now that you are not going to need anything outside:

Encryption/Integrity: AES-CCM, AES-GSCM, AES-CBC in 128 and 256 bit strengths
ChaCha20 and Poly1305
Digest: SHA2 and SHA3
Public Key: Key agreement (ECDH) and digital signatures (EdDSA) with Curve25519 and
Curve448 as defined by CFRG
RSA signature and encryption at 1024 and 2048 bit key strengths.

It will take at least 18 months to get documents out that describe in detail how these are applied in all the application protocols. But that is the set of algorithms we are trying to establish as standard across the board.

On the API side, there is a lot of inconsistency right now and the current classes are really not well suited for use with the encrypt-plus-authenticate modes we prefer in modern protocol design. The classes for encryption, authentication and public key ops expose different functionality at different layers in the inheritance hierarchy. They don't expose the identification info we need for interface with certificates, or S/MIME, JOSE, etc.

So what I have done for my own code is to develop a set of classes that essentially wrap the .NET classes which in turn wrap either the Windows classes or OpenSSL. I also have a much simpler certificate parser/issuer library that is in native C#. Both of those will be released as open source under an MIT license in the next few days.

Right now my project is built in .NET 4.6 because it is what existed. But the aim all along was to move to .NET Core, that was part of the reason for choosing .NET in the first place.

[xied75]

What about using this then https://github.com/onovotny/BouncyCastle-PCL

[karelz]

We need API proposal for each algorithm.
Keep in mind that each new algorithm has to receive Microsoft crypto-board approval - we can help get it started, but there is no guarantee about the result.

[cyberphone]

Although the following is for Java, most of the issues should apply to .NET as well:
https://github.com/cyberphone/java-cfrg-spec

[bartonjs]

Encryption/Integrity:

• AES-CCM (Done)
• AES-GCM (Done)
• AES-CBC (Done)
• ChaCha20 and Poly1305 (Done)

Digest:

• SHA2 (Done)
• SHA3 (tracked by Add support for SHA3 (Keccak) #20342)

Public Key:

• Key agreement (ECDH) with Curve25519 or Curve448 (sorta works)
• digital signatures (EdDSA) with Curve25519 or Curve448 (tracked in [API Proposal]: Add support for Ed25519 #63174)
• RSA signature and encryption at 1024 and 2048 bit key strengths (Done)

Doesn't seem like there's a lot of action to take. Anything that's missing should be discussed in a dedicated issue, instead of a grab bag issue.