Re: [Cfrg] Outline -> was Re: normative references

David McGrew <mcgrew@cisco.com> Thu, 16 January 2014 20:31 UTC

Return-Path: <mcgrew@cisco.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 17B5F1ABBB1 for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 12:31:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.439
X-Spam-Level:
X-Spam-Status: No, score=-9.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 9lEoOFczfggE for <cfrg@ietfa.amsl.com>; Thu, 16 Jan 2014 12:31:05 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id E7AF21A16F0 for <cfrg@irtf.org>; Thu, 16 Jan 2014 12:31:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1488; q=dns/txt; s=iport; t=1389904253; x=1391113853; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=1vhJWjAoausIC/IYCLS94mkbPPbwjroN2T486yGiWIQ=; b=O/dw9Nng1TvP7ZuRgdvJNJpfdxBvgD2MfF1CZa0WBQM5RModuS+iy5lI lVWoMCffD6+fFpjW1rikovUfSKl27swe4DkozwJpyvg0Q29MO9ig1uoMw oMoH51BfNkbtSkyh9Q9egNJmVRY+MAdyan5qb7TJAF8fG65t6Neq/X4yy w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFAN1A2FKtJXG9/2dsb2JhbABZgwuEDLUMgwiBDxZ0giUBAQEEIwQLAQVAARALGAICBRYLAgIJAwIBAgFFBgEMAQcCiACpEJwoF4EpjHQRAVAHgm+BSQEDiUeOWoZGi1GDSx6BNQ
X-IronPort-AV: E=Sophos;i="4.95,669,1384300800"; d="scan'208";a="13422248"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-5.cisco.com with ESMTP; 16 Jan 2014 20:30:52 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8914.cisco.com [10.117.10.229]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0GKUpVp005368; Thu, 16 Jan 2014 20:30:52 GMT
Message-ID: <52D8417B.9030908@cisco.com>
Date: Thu, 16 Jan 2014 15:30:51 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: "Igoe, Kevin M." <kmigoe@nsa.gov>, 'Paul Lambert' <paul@marvell.com>, Watson Ladd <watsonbladd@gmail.com>
References: <CEFC6B5C.2C6E8%paul@marvell.com> <CACsn0ckSMUbEJ4F3bQ5KVMbhdPQw1MTMCce6B8uhMfA_V0Nupw@mail.gmail.com> <CEFCBB2E.2C792%paul@marvell.com> <3C4AAD4B5304AB44A6BA85173B4675CABA9A493F@MSMR-GH1-UEA03.corp.nsa.gov>
In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABA9A493F@MSMR-GH1-UEA03.corp.nsa.gov>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Yaron Sheffer <yaronf.ietf@gmail.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Outline -> was Re: normative references
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, 16 Jan 2014 20:31:06 -0000

Hi Kevin, Paul, and Watson,

On 01/16/2014 02:42 PM, Igoe, Kevin M. wrote:
> Paul Lambert
> On Thursday, January 16, 2014 1:43 AM Paul Lambert wrote:
>
>> A truly ‘unified' public key system would support both signatures and
>> key establishment with the same key.
>>
> Received wisdom is that using the same key for both key establishment and
> signatures is a bad idea.  I believe the concern is that one protocol
> might be used an Oracle to subvert the other.

Agreed on that point, but there is a background issue here that I want 
to ask about.

Watson said in a previous email:
 >
 > Montgomery curves are here for their blazing speed in ECDH without 
large tables.
 > Edwards curves are here for their blazing speed in signatures where 
we can't toss out
 > one coordinate. I'ld much rather use Montgomery for ECDH and Edwards
 > for signatures than Edwards for everything.

So, what would this mean for an implementation that uses both ECDH and 
an EC signature?   That the math routines for both Edwards and 
Montgomery need to be included?    Or is translation between the formats 
very efficient?  If a single curve type and a single set of 
math/algorithms could be used for both, then an implementation could be 
simpler and more compact, and could perform better in software.

In any case, it makes sense to consider a complete system, rather than 
to optimize ECDH in isolation, and optimize a signature method in 
isolation.

David