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

I think that this is actually an interesting question, so maybewe can
put aside religion and mockery thereof for little bit...

Does anyone know of existing code which processes cryptography over
multiple fields using a generic bignums package (hopefully with fixed-size
bignums for timing resistance), and would be complicated by inconsistent
endian practices in a new curve?  If so, it might be worth considering a
consistent endian.

Otherwise, I don't see why it really matters. Feel free to try to convince
me, but make sure you compose your post using Emacs and not vi.

However!  I think it's very strongly preferable that point formats and
signatures should contain a fixed number of bytes on a given curve.
(Perhaps allowing different sizes for compressed points, but leading zeros
*should not be stripped*.)  That way points and signatures can go into
structs instead of using some awful ASN.1 TLV format.

Cheers,
-- Mike

On 01/25/2015 09:48 AM, Dan Harkins wrote:
>
> On Sun, January 25, 2015 12:30 am, D. J. Bernstein wrote:
>>> 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?
>    No, you could not be more wrong in that assumption.
>
>>> 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?
>    Do you want to be taken seriously when you respond like this?
>
>    Dan.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg