Re: [Cfrg] Elliptic Curves - curve form and coordinate systems (ends on March 12th)

Jakob Breier <Jakob.Breier@rwth-aachen.de> Fri, 13 March 2015 12:18 UTC

Return-Path: <Jakob.Breier@rwth-aachen.de>
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 B10631A037A for <cfrg@ietfa.amsl.com>; Fri, 13 Mar 2015 05:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level:
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 G3VRrtsaTJ3v for <cfrg@ietfa.amsl.com>; Fri, 13 Mar 2015 05:18:26 -0700 (PDT)
Received: from mx-out-1.rwth-aachen.de (mx-out-1.rwth-aachen.de [134.130.5.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2729C1A0016 for <cfrg@irtf.org>; Fri, 13 Mar 2015 05:18:25 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.11,394,1422918000"; d="scan'208";a="378479713"
Received: from hub2.rwth-ad.de (HELO mail.rwth-aachen.de) ([134.130.26.143]) by mx-1.rz.rwth-aachen.de with ESMTP; 13 Mar 2015 13:18:24 +0100
Received: from [192.168.1.2] (78.49.65.19) by mail.rwth-aachen.de (134.130.26.143) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 13 Mar 2015 13:18:23 +0100
Message-ID: <5502D58F.3030806@rwth-aachen.de>
Date: Fri, 13 Mar 2015 13:18:23 +0100
From: Jakob Breier <Jakob.Breier@rwth-aachen.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: cfrg@irtf.org
References: <54F8E735.2010202@isode.com> <5501E6A5.5040608@brainhub.org>
In-Reply-To: <5501E6A5.5040608@brainhub.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-PMWin-Version: 3.1.3.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/6eUqBFaLs8i3lYg0iIx-V4CWv5A>
Subject: Re: [Cfrg] Elliptic Curves - curve form and coordinate systems (ends on March 12th)
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: Fri, 13 Mar 2015 12:18:28 -0000

On 12.03.2015 20:19, Andrey Jivsov wrote:
> * This proposal incurs 32 additional bytes of storage overhead for the 
> public key, for the total of 64 bytes (compare this with 260+ bytes 
> for RSA 2048). 

The storage costs and transmission costs might be insignificant for 
machines, but I'd like to point out the human storage and transmission 
costs. Take a look at SSH keys for example. Compare how well you can 
visually parse several lines of keys in an authorized_keys file in these 
three formats:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDRTSfbRohGanse3u4gnu8wOId85f5KKyEzo/l
MabVM4J92n6r4NPgN46pQ3bTc8XzLO5zHXY/mPSwQru3Ks+6Mcut7bDo0ohPcLcdIYGTbqXkfz3
KNDbdXwPMcaPamLmugNnj9UK2cPe8Q7F9DGSLaQc1eiC0JS/Qm0gG3ULqX3DEDFQbLBzH326Lov
9gplu/U7D0bBiM7q7VQs32sz11L4KWY3RzUhuy6bQ7GGrkGvp78l7f+56AvQNeIV8fDOWKNE73s
Q3NybxWxQ771c5c+AZGYzkERlHWjxaxGA6V8ZUiE2VftHZMY4k6z4DC9hiadxwmr85qWriC7RrT
OjmN9 Alice-HomePc

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLB
RUKndAEfMluniDolf8eJIdhh1l9C2iXKtnbvbM9vFbBMQ+l47i7wusn4G2RMYsFPbwlV4XQt4TT
sEwkrcLss= Alice-HomePc

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICxtv8s7nwLqhkhryoY+w/u9ZrY7dr0ZPZhYuOS
bxTIb Alice-HomePc

They are in turn: RSA (2048 bit), 65 byte long nistp256 key and 32 byte 
long ed25519 key (apparently, openssh already uses point compression for 
this format). The difference would be even more pronounced, if the SSH 
key storage format was more efficient, but the result of factor two 
decrease from 64 byte to 32 byte keys is still significant. And these 
are keys that you often copy and paste as plain text instead of sending 
pubkey files, e.g. when you add one to GitHub or instant message it to a 
friend.

Another example is TextSecure, the end-to-end encrypted messenger app, 
that allows you to verify the 33 byte "identity" (32 byte Curve25519 key 
+ 0x05 prefix) by comparing them manually as 66 hex characters (or 
scanning a QR-code). Threema, another encrypted messenger app, also 
directly compares the public key (32 byte Curve25519) in the QR-code. 
(Threema does also feature a 128bit fingerprint, though, that can be 
compared by reading it aloud.)

As all three examples feature interactive protocols anyway, they could 
use fingerprints instead, but for various reasons don't and thus profit 
from short key sizes.

An example that does not have the alternative of using fingerprints are 
key revocation certificates. I have a few of these printed out for RSA 
keys and I fear the day I actually have to type them in.
Also, if we'll ever have a chance to bring strong end-to-end 
cryptography to the masses, then we need inexperienced users to backup 
their private key. And I trust my parents far more to securely store, 
and later on use, a slip of paper - which means writing down and later 
typing back in the key - than a USB stick / a memory card / a CD / …, 
all which have to be periodically checked whether they are still 
readable. And while this would be totally impractical with RSA keys, 
with EC keys this becomes borderline usable. And here the difference 
between 64 and 32 bytes is enormous.

Best regards,
Jakob Breier