[email protected] (Niels Möller) writes:
> Simon Josefsson <[email protected]> writes:
>
>> Do you think a uint32_t->uint32_t interface would be acceptable?
>
> If that's what is really needed for scrypt (the only application so
> far), and it lets you avoid converting back and forth between bytes and
> uint32_t, then it seems like the right thing to do.
>
> We may add a function with uint8_t (and little endian convention, I
> guess) later if the need arises. So we should take that possibility into
> account when naming the function.
So you don't think we should implement the uint8_t interface now? I
think there is little cost in doing that directly, and allows us to
directly use the only test vectors that I'm aware of.
What's a good name? Is there any precedent for something like this in
Nettle?
void
salsa20_core (unsigned rounds,
uint8_t dst[SALSA20_BLOCK_SIZE],
const uint8_t src[SALSA20_BLOCK_SIZE])
void
salsa20_core32 (unsigned rounds,
uint32_t dst[SALSA20_INPUT_LENGTH],
const uint32_t src[SALSA20_INPUT_LENGTH])
/Simon
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
