#include <std_roll_your_own_crypto_warning.h>

With the third round CAESAR candidates about to be announced, the design[0] of Salsa20/ChaCha + Poly1305 is still looking good in a number of ways, including software performance. However, LRX algorithms have a major advantage when it comes to (relatively) efficient masking/blinding[1].

NORX[2] is a sponge based design similar to Keccak/SHA-3 and the Keccak-p based Keyak[3] CAESAR candidate but designed with efficient software performance in mind. However, it is not as efficient as ChaCha20/Poly1305[4] in software, particularly if you want 256-bit keys on 32-bit systems.

So the question is, are there any obvious issues to using NORX32-f in a Salsa20 style stream cipher, using the pseudo-addition operation $H()$ to add in the initial state the way Salsa20 does? What, if any, different security properties are needed for the stream cipher usage vs. the sponge usage?


1 Answer 1


NORX's $F^l$ is meant to behave as a random permutation (modulo some known harmless properties), given enough rounds. $F^l$ is similar to the ChaCha double-round in all but the addition operation, which is replaced by $H$, and the rotation constants.

NORX should be usable in a Salsa20/ChaCha-style mode; a break in that mode would likely spell trouble for the NORX sponge mode as well. Note that the last step, adding in the initial state, can be simply done with xor; no need to use $H$ in there. Since you lose authentication by using this mode, the cost of an independent MAC should also be taken into account.

Another option to improve NORX32's performance would be to use the parallel mode. With, say, $8$ lanes you could use AVX2 to compute all of them simultaneously. Since NORX suffers from being a purely sequential mode, this would improve performance by a factor of 2 or more. This would not, however, be an 'official' CAESAR-submitted mode.

That being said, I cannot recommend using the NORX permutation in these modes, nor can I recommend using NORX in any form whatsoever just yet. This is a cryptographic primitive in its infancy, and its strong security should not be assumed.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.