# In Fortuna, can I use ChaCha20 instead of a block cipher and Blake2b instead of iterated SHA256?

In the Fortuna CSPRNG, can I use ChaCha20 instead of a block cipher and Blake2b instead of double SHA256, and still retain security?

My hypothesis is "yes" because:

• The block cipher's only use is in CTR mode (i.e. as a stream cipher). ChaCha20 is a PRF used in CTR mode. In fact, I think this should increase security.
• Blake2b is considered at least as strong as SHA256 and is immune to length-extension attacks, so the double hashing is not required.

• these modifications should work. I'll see if I can brew something authoritative together. – SEJPM May 5 '16 at 21:46

TL;DR: Fortuna is a CSPRNG so you can replace components pretty arbitrarily, because you're not bound by compatibility requirements and the modifications should work, although there are some points that are note-worthy.

In Fortuna (PDF), AES-256 is used in exactly one place: To generate the keystream based on the current counter (the function is even called GenerateBlocks())

However, there's one potentially difficult thing with the way AES-CTR is used by Fortuna: Counters aren't reset upon re-key. So if Fortuna re-keys, it generates two blocks of key material and uses them as the new keys, but the counter used for this just gets incremented by 1 again and continued to be used.

This can be overcome by appropriately using the seeking mechanism of ChaCha.

In the end, AES-CTR in Fortuna fulfills the role of a pseudo random generator and thus is arbitrarily exchangeable by any other PRG, which includes block ciphers in CTR mode and of course also ChaCha. Whether using a different cipher will actually increase security depends on the amount of cryptanalysis on the new cipher, as 256-bit AES is already physically unbreakable for humans.

SHA-256d is used in two places in Fortuna: As a KDF to derive the new key from the old key and a given random string and separately as standard hash function to collect the pool entropy.

For both usages, a replacement of SHA-256(d) by Blake-2b is functionally equivalent, even though one may want to consider using Blake-2b in MAC mode (for the KDF part) or with some (distinct) personalization string for both operations.