Re: [Lwip] Call for adoption of draft-struik-lwig-curve-representations-02

Nikolas Rösener <nik_roe@uni-bremen.de> Sun, 19 August 2018 17:08 UTC

Return-Path: <nik_roe@uni-bremen.de>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DCC130EB9 for <lwip@ietfa.amsl.com>; Sun, 19 Aug 2018 10:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level:
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uni-bremen.de
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 p_UX9PlPncAj for <lwip@ietfa.amsl.com>; Sun, 19 Aug 2018 10:08:57 -0700 (PDT)
Received: from smtp.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D24130EA8 for <lwip@ietf.org>; Sun, 19 Aug 2018 10:08:57 -0700 (PDT)
Received: from webmail.uni-bremen.de (webmail-2.zfn.uni-bremen.de [134.102.50.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uni-bremen.de (Postfix) with ESMTPS id 47022202B0 for <lwip@ietf.org>; Sun, 19 Aug 2018 19:08:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=dkim; t=1534698536; bh=Jxsr3KweCoCY6YCytySfOlxvxpLzgGBdFcUdUO01noA=; h=Date:From:To; b=Nj/y5QoJhm6ednaFLIz03lmJyRYVBoQUVVdp1nV48EtiSpMVPYUxryVcrkdJ1oiFT 5OOdkt5RGV4u9E1srl8A7d9MzTEeLsGCPvAr0n9Fe11/aJcQYd1gFaLy8QtNxyHhg+ uHLOWZtEl2OpQ4hPcSRpQpFV1N6SvU5fOpiUbmR0=
Received: from uni-bremen.de (webmail-2.zfn.uni-bremen.de [134.102.50.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by webmail.uni-bremen.de (Postfix) with ESMTPSA id 2CF9E7FC8D for <lwip@ietf.org>; Sun, 19 Aug 2018 19:08:56 +0200 (CEST)
Received: from dslb-092-076-159-228.092.076.pools.vodafone-ip.de (dslb-092-076-159-228.092.076.pools.vodafone-ip.de [92.76.159.228]) by webmail.uni-bremen.de (Horde Framework) with HTTPS; Sun, 19 Aug 2018 19:08:56 +0200
Date: Sun, 19 Aug 2018 19:08:56 +0200
Message-ID: <20180819190856.Horde.72-iC2Qq0HvxX0ckCy94u8L@webmail.uni-bremen.de>
From: Nikolas Rösener <nik_roe@uni-bremen.de>
To: lwip@ietf.org
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset="utf-8"; format="flowed"; DelSp="Yes"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/AuhuZNUxVR-Rpp1WuVkqKcE5taY>
Subject: Re: [Lwip] Call for adoption of draft-struik-lwig-curve-representations-02
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Aug 2018 17:11:17 -0000

Hi,

my name is Nikolas Rösener - I am student at the Universität Bremen  
currently writing my masters thesis on the topic of the performance of  
curve model transformations.

In my opinion draft-struik-lwig-curve-representations-02 already  
presents a great summary of the possible transformations for the  
Curve25519-family of curves. I implemented the transformations in two  
different libraries, as part of my performance evaluation, and had no  
problems following the formulae in the draft.

In retrospect, I found that the following additional information would  
have been very useful if I had attempted to implement the  
transformations as part of a serious cryptographic primitive:

- Test Vectors
- Recommendations for (the relevance of) dealing with the special  
cases (point-at-infinity etc.)
- Usages with co-factor Diffie-Hellmann (NIST SP 800-56a)
- Usages with ECDSA (FIPS Pub 186-4)

I had some further discussions with Rene on topics related to  
retrofitting existing implementations with conversions (doing generic  
modular reduction, providing transformation formulae for different  
point formats, providing algorithms for recovering coordinates...).  
The relevance of these of course depends on the direction the draft is  
taking.

Oh, and - personal preference - but I also think it makes quite a  
difference to the ease and speed of implementing an ecc algorithm if  
it is provided as three-operand-code in addition to the mathematic  
formula (like e.g. https://hyperelliptic.org/EFD/). The former reduces  
cognitive load and risk of manual errors. 

Best regards,
Nikolas Rösener