Runtime: Add ChaCha20-Poly1305 to CoreFX

[DemiMarie]

Add ChaCha20-Poly1305 to CoreFX's cipher suite. It is a very fast AEAD (significantly faster than AES-GCM except when the latter has hardware support) that is immune to side channel attacks and is relatively easy to implement.

It is included in OpenSSL 1.1 or later, or in libSodium.

[CodesInChaos]

What kind of API should be used for this? ICryptoTransform isn't a good match of authenticated encryption since it has to release data before verifying the MAC, which is a security risk. It doesn't support additional data at all.

[morganbr]

@drbo, are you specifically looking for a stream cipher? I agree with @CodesInChaos that we'd need to design an authenticated stream cipher API surface. My priorities in such an API would be that it:

1. Ensures that authentication actually happens -- we've seen cases where people use ICryptoTransform to decrypt the amount of data they expect and then stop reading before getting to the end of the input
2. Makes it unlikely that users will accidentally fall into key/nonce reuse since that can break stream ciphers very easily
3. Is reasonably usable -- ideally much more so than ICryptoTransform

[DemiMarie]

@morganbr no, I am not specifically looking for a stream cipher.

Rather, I am looking specifically for ChaCha20-Poly1305 (for AEAD) and possibly XSalsa20-Poly1305.

The _big_ advantages of the Salsa20 family of ciphers (which includes ChaCha20 and XSalsa20):

• Designed for secure implementation in software. When AES-NI is not available OpenSSL uses
  an
• Very fast, even in pure-software implementations. On ARM, ChaCha20-Poly1305 is over 3.5 times
  faster than 128-bit AES-GCM.

Nonetheless, a good AEAD interface would be extremely useful, but it is a seperate issue.

[prajaybasu]

Any progress on this yet ?

[bartonjs]

@prajaybasu Nope, sorry. Since AES-GCM works on both Windows (via bcrypt.dll) and Unix (via libcrypto) it will be the framework's first venture into AEAD.

Partly it's a problem of designing an API that creates the pit of success (e.g. forcing that the integrity be checked before letting you see any of the decrypted data) while also allowing for performance (e.g. streaming data out live).

But, even AES-GCM is behind getting the current 1.0 release out the door.

[karelz]

We need API proposal for the 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.

[tmds]

@stephentoub what does 5.0 mean on this (and other issues)? Is this planned? Or issues considered for 5.0 planning?

[stephentoub]

I bulk moved all api-* to 5.0 a few months back so they could be triaged and then closed, left, or pushed out as appropriate.

[ohsorry]

AEAD_CHACHA20_POLY1305 uses chacha encryption, it's fast.
ChaCha20 and Poly1305 for IETF Protocols

[oliverjanik]

Seconding this request. Net core needs to support modern cryptographic suit. It's lagging terribly compared to e.g. Go ecosystem.

It's been 4 years?

Can this make it into .net 5?

[bartonjs]

Can this make it into .net 5?

It definitely can't make it into 5, since 5 is pretty much wrapped up (only critical bug fixes at this point).

It's been 4 years?

We have a policy of not implementing cryptographic primitives, but deferring to OS libraries. As of when I last looked, Windows does not support ChaCha/Poly. This means that whatever our ChaCha/Poly implementation looked like it wouldn't work on Windows. That means we'd only go from "not available" to "not available half the time", which doesn't currently feel like a significant win.

[oliverjanik]

Maybe time to reexamine the policy?

When it comes to modern security features, other platforms are leaving .net core in the dust. AES-GCM only became available in .net core 3.

Heaps of libraries and SDKs bundle BouncyCastle due to lack of modern cryptograhy in dotnet.

Officially sanctioned and supported modern crypto would be a big win for the platform.

[DemiMarie]

@bartonjs IIRC there are formally verified, reasonably-performing implementations of both ChaCha20 and Poly1305, meaning that we can bundle them without worrying about future bug fixes (since none will be needed).

[ohsorry]

I don't know why the native Windows crypto library is so conservative.
chacha is fast, a managed implementation is also acceptable.

[FiniteReality]

Supporting XSalsa20-Poly1305 would mean I don't have to distribute builds of libsodium for users of my library, and would make installation so much easier.

[DemiMarie]

I strongly suggest that we bundle a formally-verified implementation on platforms where no implementation is provided by the OS. A formally verified implementation (by definition) has a machine-checked proof of correctness, so we do not need to worry about having to patch bugs in our crypto, which I suspect is the primary reason for not bundling crypto primitives.

[GrabYourPitchforks]

It's not just "correctness". It's also about things like being resilient to side-channels.

To be resilient against side channels, the implementation must control many details of execution. As a non-exhaustive list, the implementation must tightly control: register allocation, exact locations of all data in memory and on the stack, how context switches take place, how jump targets are aligned, when page faults occur, and so on.

This is why you often see battle-tested implementations written in assembly rather than higher-level languages. The more abstracted the language is from the raw codegen, the less ability the author has to make their implementations resilient to these types of flaws. It's hard to get even something seemingly trivial like a fixed-time equality check solid in C#. We still need to check every release that a JIT optimization didn't break our assumptions there - and that's just a single twenty-line method! The fact is that .NET's managed runtime doesn't provide enough low-level control for somebody to confidently write a secure cryptographic primitive. And that's fine! Not all code belongs in the managed layer; that's what unmanaged code and p/invokes are for. The solid implementations of these algorithms are written in [generally] assembly, and we p/invoke into them.

[DemiMarie]

We could still bundle the assembler implementation, or P/Invoke into a bundled BoringSSL.

[ohsorry]

I agree that tampering obfuscated assembly is more difficult than IL , but it has nothing to do with side-channel attacks like variable-time equality.

[oliverjanik]

As a user of dotnet, I care about batteries included official API, whether managed or just a wrapper around BoringSSL does not matter one bit to me.

If Microsoft does not provide reliable modern crypto, what chance does a majority of dotnet developers stand when evaluating random Nuget packages on their own?

All of this reflects back on the platform. Help dotnet developers do the right thing.