Re: [cryptography] ChaCha/Salsa blockcounter endianness
On 27/01/14 06:33 AM, Billy Brumley wrote: I think the fact that, in the reference code, input[12] and input[13] are contiguous is throwing you off. The spec really just talks about bytes: http://cr.yp.to/snuffle/spec.pdf - Sec 10 Here i is the unique 8-byte sequence ... - Then see how that looks like in Sec 9 (e.g. Example 2) - Then Sec 8 finally Sec 7 how they get mapped to 32-bit ints OK, right. So that clears up one thing: the words are laid out in clear little-endian fashion (it's just not signalled so clearly). So my read is how you want to implement that 64-bit counter is up to you--as long as you respect the interface and feed the bytes in the order it expects. Right. Last night I was trying to impose longs over it. Looking back, that's a mistake, indeed there aren't even ints imposed or u32s, they are just used internally. The byte representation is what is imposed. So as long as the interface specifies a byte layout, it is pretty much up to a wider layer to extract the secret of the long conversion, if one is in the unfortunate position of having to do addition, etc. OK, much commentary added, and some conversion routines as well. Thanks! iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] ChaCha/Salsa blockcounter endianness
Has anyone implemented Salsa/ChaCha hereabouts?
I'm looking at the blockcounter and I have a doubt... It is an 8byte
block, and as the reference code works in u32s, it converts it as two
4-byte quantities to two 4-byte ints (u32s) in a platform independent
fashion (controlling each for endianness).
As it is working in little-endian mode, it then does the increment of
the two numbers manually with the first u32 [12] being the low-order.
Unfortunately, this means they are hard-coded in little endian mode:
x-input[12] = PLUSONE(x-input[12]);
if (!x-input[12]) {
x-input[13] = PLUSONE(x-input[13]);
/* stopping at 2^70 bytes per nonce is user's responsibility */
}
This is maybe sorta correct if that is how it is defined; the problem
is that it punts the question of what the actual ordering should be if
we wanted to use longs. As the reference code sets the blockcounter to
zero, and doesn't offer the choice of restarting down the stream at some
long value, it doesn't matter what the user thinks because there is no
setting of it.
I'm doing Java/network order/bigendian and I'm restarting at random
places determined in longs ... :( so I can't punt it. If I take a long,
and convert it to byte[8], will I be compatible with anyone else?
To make matters worse, none of the test vectors will pick this issue up
because they using the raw byte[8] all zeros as the blockcounter so will
happily increment internally in little-endian order and compare nicely.
(DJB's cunning test vector starts at long value -1 ... but again that is
symmetrical like zero (ox), and +1 for the next block
gives zero. Doh! )
There appear to be two options:
1. fix the ordering so that conversions to u64s are like the u32s, and
defined in a platform compatible fashion.
2. stick with the two u32s layed out in little-endian format,
regardless, if that's what everyone has already sort of done.
Any comments?
iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ChaCha/Salsa blockcounter endianness
I think the fact that, in the reference code, input[12] and input[13]
are contiguous is throwing you off. The spec really just talks about
bytes:
http://cr.yp.to/snuffle/spec.pdf
- Sec 10 Here i is the unique 8-byte sequence ...
- Then see how that looks like in Sec 9 (e.g. Example 2)
- Then Sec 8 finally Sec 7 how they get mapped to 32-bit ints
So my read is how you want to implement that 64-bit counter is up to
you--as long as you respect the interface and feed the bytes in the
order it expects.
BBB
On Mon, Jan 27, 2014 at 2:20 AM, ianG i...@iang.org wrote:
Has anyone implemented Salsa/ChaCha hereabouts?
I'm looking at the blockcounter and I have a doubt... It is an 8byte
block, and as the reference code works in u32s, it converts it as two
4-byte quantities to two 4-byte ints (u32s) in a platform independent
fashion (controlling each for endianness).
As it is working in little-endian mode, it then does the increment of
the two numbers manually with the first u32 [12] being the low-order.
Unfortunately, this means they are hard-coded in little endian mode:
x-input[12] = PLUSONE(x-input[12]);
if (!x-input[12]) {
x-input[13] = PLUSONE(x-input[13]);
/* stopping at 2^70 bytes per nonce is user's responsibility */
}
This is maybe sorta correct if that is how it is defined; the problem
is that it punts the question of what the actual ordering should be if
we wanted to use longs. As the reference code sets the blockcounter to
zero, and doesn't offer the choice of restarting down the stream at some
long value, it doesn't matter what the user thinks because there is no
setting of it.
I'm doing Java/network order/bigendian and I'm restarting at random
places determined in longs ... :( so I can't punt it. If I take a long,
and convert it to byte[8], will I be compatible with anyone else?
To make matters worse, none of the test vectors will pick this issue up
because they using the raw byte[8] all zeros as the blockcounter so will
happily increment internally in little-endian order and compare nicely.
(DJB's cunning test vector starts at long value -1 ... but again that is
symmetrical like zero (ox), and +1 for the next block
gives zero. Doh! )
There appear to be two options:
1. fix the ordering so that conversions to u64s are like the u32s, and
defined in a platform compatible fashion.
2. stick with the two u32s layed out in little-endian format,
regardless, if that's what everyone has already sort of done.
Any comments?
iang
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
