nisse@lysator.liu.se (Niels Möller) writes:
Simon Josefsson simon@josefsson.org writes:
I quickly discovered that I needed the round-reduced variants of Salsa20. Here they are. I didn't update the assembler part, so I would need help finishing that part.
Nice. Key setup is the same, just the number of iterations in the main loop is different?
Yes.
+static void +salsa20r_crypt(struct salsa20_ctx *ctx,
int rounds,unsigned length,uint8_t *c,const uint8_t *m)This is the function which should be implemented in assembly.
Actually, sleeping on this, I realized that we really want to export the Salsa20 core primitive (this was what I actually needed), and that is the primitive that should be implemented in assembler. I've fixed this in the attached patch.
The Salsa20 core is a hash function (not your typical hash function though) described here:
If we implement that quickly in assembler, with a variable round parameter, that will be sufficient to build fast C code around.
All of the Salsa20, Salsa20/8, Salsa20/12 and the stream handling code could then be written in C.
Do you think this should be a public, documented function (in which case salsa20r_crypt sounds like a reasonable name), or internal, in which case nettle convention would be something like _salsa20_crypt?
It should be an internal function, I've fixed this in the patch below.
--- a/testsuite/salsa20-test.c +++ b/testsuite/salsa20-test.c @@ -13,13 +13,18 @@ memzero_p (const uint8_t *p, size_t n) return 1; }
+typedef void (*salsa20_func) (struct salsa20_ctx *ctx,
unsigned length, uint8_t *dst,const uint8_t *src);A very minor point... I've decided to try to stick to non-pointer typedefs for function types. I.e.,
typedef void salsa20_func (struct salsa20_ctx *ctx, unsigned length, uint8_t *dst, const uint8_t *src);
That way, it is possible (although maybe not useful very often) to use the typedef for declaring functions, like
salsa20_func salsa20_crypt; salsa20_func salsa20r8_crypt; salsa20_func salsa20r12_crypt;
Sure.
Updated patch below.
/Simon