Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)

["D. J. Bernstein" <[e-mail]>]

> a long-standing tradition of the on-the-wire format

Just to make sure that I understand, after reviewing a ton of tcpdump
output: You're referring to the HTTP tradition of variable-length ASCII
decimal encodings for integers on the wire (cache times, data lengths,
version numbers, etc.)? Does this mean that IETF pushed this HTTP
tradition into AES-GCM's internal integer encodings before deploying
AES-GCM, and plans to do the same for other cryptographic systems?

> better looking and more maintainable code

You're absolutely right: being able to reuse existing variable-length
ASCII decimal integer encoders and decoders has always been a critical
part, I daresay the most important part, of implementing, reading,
auditing, and maintaining cryptographic software. RFC 1321 (MD5) got
this totally wrong---the integers are _backwards_ and _non-decimal_ and
_non-ASCII_---and we all know what happened to MD5 as a result.

Now that you've reminded me of what really matters for cryptographic
code complexity and security, I would love to put together an ASCII
decimal version of Curve25519, but I have to admit that I'm not
_completely_ clear on the details of the HTTP tradition that you're
talking about. For example, are leading zeros allowed? This would allow
simpler integer encoding for some embedded systems, but it would cause
trouble for existing parsers that switch to octal for a leading 0, such
as base-0 strtol(). Also, can the integers exceed 2147483647?

---Dan