Simon Josefsson <si...@josefsson.org> writes:
> Yes, although if necessary I could xor it to a zero buffer if there were
> no other way...
I was going to suggest using something like
void
salsa20_core (const uint32_t *input,
unsigned rounds,
unsigned length,
uint8_t *dst,
const uint8_t *src)
which would compute the hash of the INPUT. If SRC is NULL, it would just
store the LENGTH first bytes at DST. And if SRC is non-NULL, it would
xor that data before storing.
A bit clumsy, but reasonably general.
But then I remembered that for high performance encryption, it's not
sufficient with an assembly function which does only one block. You can
gain a lot of performance (current code doesn't do that) by hashing two
input blocks in parallel.
So at the moment, I'm inclined to let the assembly function do
encryption, including xoring data and incrementing the counter. And if
you only need the hash, you'd need a wrapper which encrypts a zero
buffer and undoes the incrementing (the assembly
function could leave the input block unmodified and maintain the updated
counter locally; that would be a bit extra hassle but I don't think it
would impact performance). Then we have sufficient freedom for
optimizing salsa20 encryption, with a small performance disadvantage for
using just the hash.
> however I'll loose performance, and my application
> (scrypt) would benefit from good performance.
Will you be hashing several independent blocks? If so, for highest
perforamnce you would also neeed an interface which lets the assembly
routines do several blocks in parallel.
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
