[Cfrg] Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 20 May 2015 21:15 UTC

Return-Path: <alexey.melnikov@isode.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 CB9F51A9115 for <cfrg@ietfa.amsl.com>; Wed, 20 May 2015 14:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.689
X-Spam-Level:
X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, 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 EuibI5W2PF9D for <cfrg@ietfa.amsl.com>; Wed, 20 May 2015 14:15:44 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [217.34.220.151]) by ietfa.amsl.com (Postfix) with ESMTP id 55FBE1A9110 for <cfrg@irtf.org>; Wed, 20 May 2015 14:15:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1432156542; d=isode.com; s=selector; i=@isode.com; bh=Jh1sLAUe2dZk10SJkv1+45guDWoc737jEytgaVgchcM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=nBd9oq2/ZHQDDXv+LNPM0vBbmw1lYdwHWOyR/cjUIGck5KvOm+dPQlD5dp2Kp2AJFQ40SR BtvCfLlptZFYP4IUjhSb2wr0Zz02bC6kXEboeOV66aIc1i63hJxD6ekfC/nzwRddE0B94u MhO8rJc12BTi7hT5SurDmO3YrSPscSo=;
Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <VVz5fgAnezNT@statler.isode.com>; Wed, 20 May 2015 22:15:42 +0100
X-SMTP-Protocol-Errors: PIPELINING
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Wed, 20 May 2015 22:16:16 +0100
Message-Id: <C49BFA4F-76B9-48A1-913B-144D606FBBDD@isode.com>
To: "cfrg@irtf.org" <cfrg@irtf.org>
X-Mailer: iPad Mail (12F69)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/JJ0wryoh6f_t5m7Auu6m4sDMTiI>
Subject: [Cfrg] Elliptic Curves - signature scheme: friendliness to low memory implementations (ends on June 3rd)
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: Wed, 20 May 2015 21:15:45 -0000

Signature schemes have, traditionally, hashed the message to be signed to
a representative value and then actually signed that value. This has led
to APIs that follow the Init, Update*, Final (IUF) pattern that allows for
fragmented or very large messages to be signed with constant memory usage.

Alternatively, some signature schemes hash the message to be signed twice,
where a prefix of the second hash depends on the result of the first.
Ed25519 is an example of a scheme of this type. This typically allows the
signature scheme to require fewer assumptions about the strength of the
hash function that is employed. However, this approach implies that the signing
algorithm would have to buffer the entire message. That could lead to
unacceptable memory usage for applications that sign very large messages.

Penalising large messages might be seen as a positive by some because
signing arbitrarily large messages invites implementations to process
unauthenticated data because of its potential size. Also, designs that
really wish to do this can always define that the message to be signed is
actually a hash of the data. In doing so they would reintroduce the
requirement that the hash function be collision resistant, but can
implement an IUF API in constant space again.

On the other hand, if we wish a signature primitive to be easy to
substitute into existing protocols then supporting a constant-space IUF
API might be seen as a requirement.

Chairs wish to poll the group on the following topic (please pick one):

#1: The signature scheme should follow the traditional model of hashing
the message to be signed, thus trivially supporting IUF APIs in
constant-space, at the cost of requiring collision resistant hash
functions.

#2: The signature scheme should not depend on collision resistance, at the
cost of the signing algorithm having to buffer messages to be signed.

#3: option #2, but with an additional "large message" mode defined for
protocols that feel that they need it, where the message to be signed is
actually a hash of the true message.