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

[Watson Ladd <[e-mail]>]

On Sun, Jan 25, 2015 at 10:26 AM, Mike Hamburg <[e-mail]> wrote:
> 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.

Both NSS and OpenSSL have a bignum library underlying ECC operations,
but I don't know how often that gets used in practice vs per curve
optimized implementations. But we're talking about swapping bytes in a
serialization function: it's a potential wart, but a small one. If we
do reverse endianness, then what SSH is already doing won't be
included.

The fact that actual developers making actual projects don't consider
this a problem should register.

>
> 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.

SEC1 does this for points, but not signature elements. I agree that we
should used fixed-length whenever possible.

>
> 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
>> [e-mail]
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin