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

Watson Ladd <watsonbladd@gmail.com> Sun, 25 January 2015 20:36 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61201A6F32 for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 12:36:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRmbqLUtvX0Z for <cfrg@ietfa.amsl.com>; Sun, 25 Jan 2015 12:35:58 -0800 (PST)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5080C1A0032 for <cfrg@irtf.org>; Sun, 25 Jan 2015 12:35:58 -0800 (PST)
Received: by mail-yk0-f177.google.com with SMTP id 19so2558804ykq.8 for <cfrg@irtf.org>; Sun, 25 Jan 2015 12:35:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lvYL964TM1wVePzPK6ZTDZGN1MuGrkMMWjUkd7xRnu0=; b=BRqlCt0qPJgZSw9qxOWjeibig56vFDJrVYqPIZdSy5bI11qiq7I9njXFeKPZPZ9TYL uvBcZLSce1xZ3Es/Sf4D+ty7/w1aJ11rai95Tuwslr6tlaQ+DKV0YewnCA8ubft8HH9s B0w76UASBV8nXj4A33zDz/iNq2CzjwyGbvC6MP3Q9F4jp8nKwfAaBFahbtgg6kE0YAmH cc+CphNe4bDDqaiOS2H565MuKYVCGRCAqXiSEWZCmVMMgVpiLtrzNZR97MKig/1LFjRx VDE6fYInfkCqkrIINIqbpvX4gxVPcMdHcNlvh+NsdGtZAxufysgqjdJn4T6JLZ7hRRpB BfNQ==
MIME-Version: 1.0
X-Received: by 10.170.112.215 with SMTP id e206mr9009805ykb.126.1422218157550; Sun, 25 Jan 2015 12:35:57 -0800 (PST)
Received: by 10.170.115.77 with HTTP; Sun, 25 Jan 2015 12:35:57 -0800 (PST)
In-Reply-To: <54C53542.60904@shiftleft.org>
References: <20150125083018.10434.qmail@cr.yp.to> <93c73db0ce2b40c90324e89ce404abc1.squirrel@www.trepanning.net> <54C53542.60904@shiftleft.org>
Date: Sun, 25 Jan 2015 12:35:57 -0800
Message-ID: <CACsn0c=bA=dRR8Y3vOp9o+Cmmdu7ZPr3vYbuRdBczRL2Uu+Gog@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Mike Hamburg <mike@shiftleft.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/LBQApaXG1G3DpceC1RV9vOTVU1Q>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Point format endian (was: Adoption of draft-ladd-spake2 as a RG document)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Jan 2015 20:36:00 -0000

On Sun, Jan 25, 2015 at 10:26 AM, Mike Hamburg <mike@shiftleft.org> 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
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> 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