According to the original paper form Bernstein public/private keys and the shared symmetric key are stored in little-endian. However, the WolfSSL of WolfSSL supports both, little-endian and big-endian. What is the reason for this? May there be any security issues?
1 Answer
$\begingroup$
$\endgroup$
7
We want to answer "How many wolves are coming to attack?" by "twenty one" (big-endian), not "one twenty" (little-endian). That can be a matter of life and death, and perhaps natural selection of memes¹ made that the convention in many languages (German is an important exception). Big-endian is thus used in most human positional numeral systems.
When it comes to algorithms for exact addition of large integers, it's much easier to start with the low-order digits. Little-endian thus makes sense in some areas of computing, including making a desktop calculator, which was a motivating application of early microprocessors, and got Intel started in that business. That's why little-endian is sometime called the Intel convention.
In network routing according to packet destination address, the low-order bits of a destination address typically does not participate in the routing, and comes last is the destination address field. That could² me made even so slightly advantageous: having the high-order bits first allows to find the destination earlier. That's how I remember big-endian is called "network order".
In computing, the farther away from hardware, the more big-endian. Because predators.
In crypto, both still coexist, but there's a perceptible trend towards big-endianness. MD5 is little-endian (that made the very first collision exhibited wrong), SHA-1 and later hashes are big-endian. That's the NIST order. And ASN.1 integers are big-endian, thus it has won for many practical purposes.
Bernstein has an history of being a skilled low-level programmer of Intel-compatible CPUs (even recommending some), and generally opposes NIST. That's how I remember Curve25519 is nominally little-endian. OTOH, that's a mere convention that should be without cryptographic significance. When adding Curve25519 to something existing, it's possible to get it big endian (by accident or design), and keep/have that as an option.
¹ I know no evidence big-endianness went genetic!
² The tale of traders making special network equipment to crush the last nanoseconds of latency could use that. I can't pinpoint any network equipment, much less a modern one, that does. But I like the idea, and still hope something (a supercomputer cluster maybe) would use it.
-
1$\begingroup$ I take it you are not well acquainted with the German language then? (Even English does not consistently use big-endian ordering for numbers.) $\endgroup$– MaeherOct 27, 2020 at 15:44
-
2$\begingroup$ To be clear, German only screws up the ordering for for the last two digits. 1337 is "one thousand three hundred seven and thirty". In French (at least in France, I believe this particular bug is fixed in the Belgian and Suisse versions, albeit in incompatible ways?) on the other hand you have the delightful quatre-vingts which will be a real headache for your hypothetical character beset by wolves. $\endgroup$– MaeherOct 27, 2020 at 16:28
-
3$\begingroup$ I would disagree on your speculation why network order is "bigendian"; every network device I have worked with receive the entire packet before looking at the IP addresses, hence the ordering of the bytes within the IP address is irrelevant. It is more likely that they went with bigendian because the original IP network device (the "Internet Message Processor") handled 16 bit words in bigendian order. $\endgroup$– ponchoOct 27, 2020 at 19:39
-
1$\begingroup$ @poncho: I was careful to word this as the way I remember network byte order, because I fail to exhibit a concrete example. I think I was told this in the 1980's. $\endgroup$– fgrieu ♦Oct 27, 2020 at 20:14
-
1$\begingroup$ @poncho: 'cut-through' switches were popular for a long time, although I haven't noticed any recently, and they don't read the whole packet -- but they do read the whole header, and thus don't care about endianness. $\endgroup$ Oct 29, 2020 at 0:03
Big-endianness is the dominant ordering in networking protocols, such as in the internet protocol suite, where it is referred to as network order, transmitting the most significant byte first. Conversely, little-endianness is the dominant ordering for processor architectures (x86, most ARM implementations, base RISC-V implementations) and their associated memory. File formats can use either ordering; some formats use a mixture of both.$\endgroup$