Crypto primitives

[riobard]

The README says:

Modern cryptographic primitives only: Ed25519 and EDCSA over the major NIST curves (P256, P384, P521) for asymmetric cryptography, AES-GCM for symmetric cryptography, x25519 for key exchange

There's a typo: EDCSA should be ECDSA.

Also please consider support chacha20poly1305 for symmetric crypto as it performs much better for devices without hardware accelerated AES instructions and it is also the default used by modern versions of OpenSSH, the most popular SSH implementations on servers.

[Joannis]

@riobard I've previously discussed this topic with @Lukasa and he gave me a brilliant quote:

"Cryptographic algorithms aren't like pokemon. You don't have to catch them all."

I'm not sure about the Apple Silicon / iOS ARM processors, but I think they handle hardware accelerated AES. I think it makes for a healthy piece of software. I do strongly believe, for example, that RSA keys should be supported for the large amount of existing keys out there.

The alternative we came up with it to work on a allowing external implementations, so the RSA support would come in an additive third-party library. This way you've got an explicit opt-in for these kinds of legacy/deprecated or plain unnecessary algorithms while still being able to use them.

This library runs as an SSH server as well as client-side, so implementing chacha20poly1305 would allow the server to match the algorithm choices with OpenSSH. As for the client, it would only help when the configured client either prefers the chacha20poly1305 scheme, or the server doesn't support AES. The latter of which is pretty unlikely in my eyes. This is because the client gets to dictate the preferred algorithm, not the server.

[Lukasa]

There's a typo: EDCSA should be ECDSA.

Agreed, I'd love a PR to fix this typo.

Also please consider support chacha20poly1305 for symmetric crypto as it performs much better for devices without hardware accelerated AES instructions and it is also the default used by modern versions of OpenSSH, the most popular SSH implementations on servers.

For the moment there are two reasons (over and above the reasons given to @Joannis) why we aren't providing ChaCha20Poly1305 in this core library.

The first is that there are almost no target platforms for this library that do not have AES hardware-acceleration support. All Apple devices have accelerated AES, and almost all Linux devices on which Swift will run also have hardware-accelerated AES. On those platforms, AES-GCM is preferred.

The second is that this library does not want to pull in any cryptographic dependencies other than Swift Crypto, and Swift Crypto does not provide ChaCha20-Poly1305 in a format that is suitable for SSH. The way SSH uses ChaChaPoly involves running two separate ChaCha algorithms, one for the length and one for the packet body, and then doing Poly1305 over the combination. This is not easily achievable with Swift Crypto's APIs, which only offer a combined construction of ChaChaPoly.

The complexity of implementation, combined with the fairly minimal number of platforms where ChaChaPoly is better than AES, mean that it's not a high priority for the core library to support it. We absolutely do want to allow extensions to provide this functionality, however.

[riobard]

Devices without hardware accelerated AES instructions can implement AES in software, but it comes with two major drawbacks:

1. AES is notoriously difficult to get correct in software, and most pure-software implementations exhibit side-channel weakness;
2. Pure-software AES is very slow.

Consider the exploding number of IoT devices without AES instructions, I'd say it's critical and generally recommended to default to chacha20poly1305 instead.

It's sad that Swift Crypto API does not make it easy.

[Lukasa]

We don't dispute the need to have a use-case for these underpowered devices. At this time the complexity involved in it here is such that we lose more than we gain by adding that support. Given that SSH is widely implemented, for now it's acceptable to say that this use-case is out-of-scope for now.

However, I absolutely want to see extensions that can handle this for us, and Swift Crypto is itself an evolving target: we can absolutely take steps to add the support we need there too.