crypton

Crypton is a fork from cryptonite with the original author's permission.

Crypton is a haskell repository of cryptographic primitives. Each crypto algorithm has specificities that are hard to wrap in common APIs and types, so instead of trying to provide a common ground for algorithms, this package provides a non-consistent low-level API.

If you have no idea what you're doing, please do not use this directly. Instead, rely on higher level protocols or implementations.

Side channels

AES is where this matters most, and which implementation runs is decided at runtime from what the processor has.

On x86-64 with AES-NI and carry-less multiply, and on AArch64 with the ARMv8 cryptographic extension, AES and GHASH are instructions rather than tables. crypton's AES and AES-GCM then make no branch and no memory access that depends on the key or on the data: the secrets stay in vector registers and never reach one a branch can test, which the generated code is checked against. Every x86-64 part since about 2010 and every AArch64 part in ordinary use has these.

Where neither is present crypton falls back to a table-driven AES, which indexes a 256-byte substitution table with data derived from the key and the input. That is not constant time, and on a machine where an attacker can observe the cache it is open to a timing attack. The fallback exists so that the library builds and runs everywhere; it is not meant for a setting where that matters.

Crypto.System.CPU.processorOptions says which is in use. AESNI in that list means the instruction path, and PCLMUL that GHASH has its instruction too; without AESNI it is the tables. The list also reports RDRAND, which is unrelated to this.

ghci> import Crypto.System.CPU
ghci> processorOptions
[AESNI,PCLMUL]

RSA is the other place to know about, and there the choice is the caller's. The private key operations in Crypto.PubKey.RSA.PKCS15, .OAEP and .PSS take a Maybe Blinder, and Nothing is no harder to write than the safe form:

decrypt     :: Maybe Blinder -> PrivateKey -> ByteString -> ...
decryptSafer :: MonadRandom m => PrivateKey -> ByteString -> m ...

The exponent itself is not what is at risk. expSafe keeps the value of an exponent out of the work it does, so the private exponent does not leak through the exponentiation. What a blinder covers is the other side: without one, the operation runs on the ciphertext the caller was handed, so how long it takes depends on a number an attacker may have chosen and can vary. That is what a remote timing attack on RSA needs. With a blinder the input is multiplied by a random value first and the result divided out afterwards, so the timing carries nothing an attacker can steer.

decryptSafer and signSafer generate the blinder themselves and are the ones to reach for. Pass Nothing only where the input is not attacker controlled and you have decided that it is not.

The RSA rows in the tables below are the unblinded path. A blinder costs one more exponentiation, by the public exponent, which is the cheap direction: measured on the M4, signing goes from about 601 to about 620 microseconds, three per cent.

Performance

The algorithms a TLS connection uses, measured against the previous release and against OpenSSL on the same machine. Throughput is over 16 KiB messages; the public key operations are one operation each; every figure is the best of several runs, and crypton and OpenSSL are run alternately so that neither gets the quieter machine.

The columns read 2.0.0 and are what 2.1.0 measures on every row but two. The only C 2.1.0 changed is AES-GCM's and P-256's, and of those only P-256 is on a path these tables take: measured on the same EPYC 7763, ECDH P-256 goes 164.3 to 159.5 microseconds and ECDSA P-256 verification 231.1 to 226.2, so those two rows are about 3% better than they read here. ECDSA P-256 signing does not move, being the base-point path. What 2.1.0 did to AES-GCM was add a one-call interface beside the one measured here -- key expanded once, additional data, payload and tag together -- which is worth 3.6 times at 100 bytes and nothing at 16 KiB, so it does not show in a 16 KiB throughput figure at all.

Bulk encryption and hashing are measured through crypton's C layer, as openssl speed measures OpenSSL's. The public key operations are measured through crypton's Haskell API, since that is where ECDSA and RSA live and it is what a program actually calls; the Haskell layer adds well under a microsecond, which the X25519 and ECDH P-256 rows confirm by agreeing with a C-level measurement to within a percent. Both releases of crypton are built the same way -- -optc-O3, which is what both of them ask for -- and each column of a table comes from one run on the machine named above it.

x86-64

An AMD EPYC 7763, which has AES-NI, PCLMULQDQ, AVX2, ADX and the SHA extensions, against OpenSSL 3.0.13.

Throughput in MB/s, higher is better:

Time per operation in microseconds, lower is better -- so the last column divides OpenSSL's time by crypton's, and is again better the larger it is:

AArch64

An Apple M4, which has the AES, PMULL, SHA-1, SHA-2, SHA-512 and SHA-3 instructions, against OpenSSL 3.6.4.

Throughput in MB/s, higher is better:

Time per operation in microseconds, lower is better; the last column again divides OpenSSL's time by crypton's:

What the numbers say

1.1.5 had no AArch64 code of its own at all, which is why AES-GCM there is sixty-nine times what it was. On x86-64 it had AES-NI and nothing else. The curves over a prime field other than P-256 moved from Haskell Integer arithmetic into C, which is the nineteenfold change in ECDSA P-384 signing on the M4. X25519 and Ed25519 are unchanged between the two releases, and the rows say so: where they differ by half a percent, that is the measurement and not the code. P-256 is unchanged on x86-64 and a fifth faster on AArch64, which is the paragraph below.

Where crypton is behind, it is behind for three separate reasons.

P-256. crypton's field arithmetic is C where OpenSSL's is hand-written assembly, and that is what is left of the difference: the two differ by about the same factor on every P-256 row, and nothing above the field -- a wider window, a different addition formula, another field representation -- recovers a useful part of it.

The AArch64 rows are better than the x86-64 ones because of where a field multiplication's latency goes. It ends in a carry chain the width of the number, and the curve arithmetic has independent products that could cover that chain -- but only if the compiler inlines the reduction instead of calling it, since a call is a fence. Asking it to costs code and pays where there are registers enough to hold two chains at once: a quarter on AArch64, where there are thirty-one, and nothing on x86-64, where there are fifteen and the same request makes it slower. So x86-64 is left to the compiler's own judgement and stays at 0.3.

RSA signing. 2.0.0 is slower than 1.1.5 here on purpose. Its modular exponentiation no longer indexes a table with the bits of the exponent, and hiding the exponent is what the difference buys. What is left of the gap against OpenSSL is the Montgomery multiplication, which is assembly there and C here.

The AVX-512 instructions. Neither machine above has them. On one that does -- an EPYC 9V74, measured the same way -- OpenSSL uses them for AES-GCM and ChaCha20 and reaches 12003 and 3789 MB/s, against 4745 and 2372 for crypton, whose vendored assembly is generated without them. Those ratios are 0.40 and 0.63 rather than 0.97 and 1.00. Nothing else in either table moves by more than a few percent between the two processors.

One row wants a word of its own: crypton's Ed25519.sign derives the public key from the secret key every time it signs, so that a caller who passes a public key that does not match cannot be made to leak the private one. That costs a second scalar multiplication, which OpenSSL's signing does not pay.

SHA-1 is in the tables because a number of protocols and file formats still ask for it, not because it is a good choice for anything new. The algorithms that nothing should ask for any more -- MD5, 3DES, RC4, CBC mode -- are left out.