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

Adam Langley <agl@imperialviolet.org> Thu, 21 May 2015 00:09 UTC

Return-Path: <alangley@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 22E141ACD46 for <cfrg@ietfa.amsl.com>; Wed, 20 May 2015 17:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.621
X-Spam-Level:
X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 LYLruz78s1s2 for <cfrg@ietfa.amsl.com>; Wed, 20 May 2015 17:09:48 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9F2E1ACD30 for <cfrg@irtf.org>; Wed, 20 May 2015 17:09:47 -0700 (PDT)
Received: by lagr1 with SMTP id r1so90747400lag.0 for <cfrg@irtf.org>; Wed, 20 May 2015 17:09:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0mnMZ+rZxTqdIt+0+V8DZHFC7MLCOpMN6UROmqaC2jk=; b=gOfLEoWaTivCFV0JvH8vfRh/j9BKk2tltYQ04/4EfHZFTSomUmc+4c8+fRS45pRiZy CBICSAbBkvI5LayQ2LMdfWSency2uf/3yN7+9wHgPyTs7wRGjMv9aa61H+G42uWt5Ab5 TkO9RRRliZjw7Z6sFZDAaYfqqefOi49FULSuAWvKWM5/itYoKpjZgGdHmmtzCEC/MbTi jvydiAIFwHFmTgSbQcnw0FWdb8WPocIqBZegQo1/ywIDnCQnwOn+UwuLJyViX0LHdkMv PoYWrAKMWVwUo40KPe2PsTae8KI9EZ9jiK/jH3yXeZQk3V8LshN/MC/RUAvwjsK87YQ7 kC1w==
MIME-Version: 1.0
X-Received: by 10.152.183.200 with SMTP id eo8mr28151126lac.57.1432166985180; Wed, 20 May 2015 17:09:45 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.112.89.69 with HTTP; Wed, 20 May 2015 17:09:44 -0700 (PDT)
In-Reply-To: <20150521000052.GK19183@localhost>
References: <C49BFA4F-76B9-48A1-913B-144D606FBBDD@isode.com> <20150521000052.GK19183@localhost>
Date: Wed, 20 May 2015 17:09:44 -0700
X-Google-Sender-Auth: 9lbAMzUngqO9RW3LBeAx1FKKaaM
Message-ID: <CAMfhd9Wn0YPb3qZ47C8uJCHqQ389qVRVZoKJ0HmjqKsF+jHgqQ@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/LXOIbdrJBE_z2d2CaSS5j3q5kT8>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [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: Thu, 21 May 2015 00:09:49 -0000

On Wed, May 20, 2015 at 5:00 PM, Nico Williams <nico@cryptonector.com> wrote:
> I'd rather this be cast in terms of online/offline.  The question isn't
> how much memory is needed, but whether the amount needed is fixed or
> unbounded (e.g., proportional to message length).

I think "online" is what's described in the question as the
"traditional" construction, i.e. operates in constant space. But could
you confirm so that I'm clear?

> Anyways, I think we should do #4, a rephrasing of #3, though I'm open to
> all options listed thus far:
>
> #4: provide both online and not-online signature schemes
>
> Users could use an offline scheme in an online way and hash the message
> themselves, but it seems best to do it in the scheme itself.

How would your #4 differ from #3? Would the signature scheme itself be
different? (As opposed to #3 which imagines a "wrapper" around a
signature scheme.) If so, wouldn't that be a bunch more complexity for
the specification and implementation?


Cheers

AGL