I have been working on implementing the NORX V3.0 authenticated encryption algorithm and I have run into a very confusing contradiction regarding the order in which padding and permutation are performed during header, encryption, and trailer operations.

According to the V3.0 specifications (https://github.com/norx/resources/blob/master/specs/norxv30.pdf) , they show that the final block is padded after the ID is absorbed into the state.

According to the authors C reference code (https://github.com/norx/norx/blob/master/norx6444/ref/norx.c) the padding is performed before absorbing the block.

When I implement it according to the V3.0 specifications, the output of my code matches the test vectors.

When I swap the order to match the reference code, the test vectors fail completely.

Based on my general knowledge of sponge functions, I would expect that padding is done before executing the permutation. This is consistent with what I see on the reference code, but contradicts what the specifications say.

I have searched the web to see of perhaps there are errors in the V3.0 specifications that have not yet been updated into the document.

I have also noticed that when I pad after the permutation as per the spec, parallel mode (NORX64-4-4-4) matches all the test vectors except the final output tag. Changing between the two padding orders yields different tags, but none that match the test vectors given in the specification.

Having seen reference code in multiple languages (C, GO, PYTHON, C++, etc.) all showing padding before permuting, and given that a sponge is normally padded before permutation, I am beginning to suspect that the specification is incorrect.

If anyone knows the correct ordering to use, would you please confirm it.

Related : The test vectors are very limited. Does anyone know of a set of more comprehensive vectors (single and parallel mode) that are available?


  • 2
    $\begingroup$ This sounds like an excellent inquiry for the authors of the specification and reference implementation! Have you tried emailing them? Authors of such things are typically quite responsive to reports of clearly reproducible discrepancies between the spec, ref impl, and test vectors. $\endgroup$ Commented Feb 23, 2019 at 2:44
  • $\begingroup$ I do not understand what the discrepancy is. Please be more specific. $\endgroup$ Commented Feb 23, 2019 at 8:20
  • 1
    $\begingroup$ Actually, it turns out the problem is with me :( Sigh... Not enough midnight oil left to keep the candle burning... Both the spec and reference are fine. The problem is in how the reference code passes arguments. It tricked me into thinking the padding was done before the permutation when, in fact, it is done after. That, combined with a misunderstanding of how parallel mode works lead to the red herring. Apologies. $\endgroup$ Commented Feb 23, 2019 at 18:49


Your Answer

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

Browse other questions tagged or ask your own question.