4 ms·

When it goes over the network it has to be big-endian so both sides agree on the value. That's why we call it "network order". If the value is random and you s

by sjs 16y ago

When it goes over the network it has to be big-endian so both sides agree on the value. That's why we call it "network order". If the value is random and you send the low byte first and then treat that as the high byte it would work. I can't imagine that ever being useful, but it works as long as both sides agree that that [FE, ED, FA, CE] is 0xFEEDFACE. If your RNG gives you 0xFEEDFACE you better not send it out as [CE, FA, ED, FE] or you're going to make a mess of things. Host byte order is completely irrelevant.

axod 16y ago
The endianness here is irrelevant. It's 8 bytes of random data. My point was, that generating a random 64bit integer and storing it as little endian, would infact work fine. Because the 8 bytes of random data is only used in the context of "8 bytes of random data", and never as "an integer" by both sides. The spec is just ridiculously overly specific. It's telling us how you can generate 8 bytes of random data. Any programmer implementing it should have a vague idea how to do that.
- sjs 16y ago
  I completely understand your frustration with the over-specification. Why would they send it over the wire if it was never meant to be used though? Surely the other side is interpreting these bytes somehow and excepts them in a certain order. [ a bit later ... ] I decided to check the spec and see for myself what's going on. The part you're talking about, key3, is in fact used later. The bytes may be random but both sides need to know which of the 8 bytes comes first and which comes last. Let /challenge/ be the concatenation of /number_1/, expressed as a big-endian 32 bit integer, /number_2/, expressed as a big- endian 32 bit integer, and the eight bytes of /key_3/ in the order they were sent on the wire. If the other side doesn't agree on the order of the bytes in key3 then things are not going to work. Your other complaints may be valid but sometimes this sort of over-specification helps implementers.

by sjs 16y ago

axod 16y ago

The endianness here is irrelevant. It's 8 bytes of random data. My point was, that generating a random 64bit integer and storing it as little endian, would infact work fine. Because the 8 bytes of random data is only used in the context of "8 bytes of random data", and never as "an integer" by both sides. The spec is just ridiculously overly specific. It's telling us how you can generate 8 bytes of random data. Any programmer implementing it should have a vague idea how to do that.

sjs 16y ago
I completely understand your frustration with the over-specification. Why would they send it over the wire if it was never meant to be used though? Surely the other side is interpreting these bytes somehow and excepts them in a certain order. [ a bit later ... ] I decided to check the spec and see for myself what's going on. The part you're talking about, key3, is in fact used later. The bytes may be random but both sides need to know which of the 8 bytes comes first and which comes last. Let /challenge/ be the concatenation of /number_1/, expressed as a big-endian 32 bit integer, /number_2/, expressed as a big- endian 32 bit integer, and the eight bytes of /key_3/ in the order they were sent on the wire. If the other side doesn't agree on the order of the bytes in key3 then things are not going to work. Your other complaints may be valid but sometimes this sort of over-specification helps implementers.