Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS
Michael StJohns <msj@nthpermutation.com> Wed, 10 June 2015 17:27 UTC
Return-Path: <msj@nthpermutation.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDA11ACE6B for <tls@ietfa.amsl.com>; Wed, 10 Jun 2015 10:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.1
X-Spam-Level:
X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] 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 Fwl4LboSnyvL for <tls@ietfa.amsl.com>; Wed, 10 Jun 2015 10:27:18 -0700 (PDT)
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) (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 4739F1B2EFB for <tls@ietf.org>; Wed, 10 Jun 2015 10:27:18 -0700 (PDT)
Received: by qkx62 with SMTP id 62so28721194qkx.3 for <tls@ietf.org>; Wed, 10 Jun 2015 10:27:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Y7HL+QVdAy5iYy9Qc+aTdbn8t0dt2rmLjkSQ6dEb0Ms=; b=fnwCbibgq3Lh53SWQIivsMatHQcGlTg8/6W31LUaiKU9PLtDg/LVwNJqUfjCNMZcCd bRqvROQGRGmqXZP1KgHefvExygamI3AorCwM7CKAR4Byu1JIcHCFMCvA8JKPkt1tJMMh DaLfM+2rj6zVk6zDfQ718U7mZ5HOcq2ajUlsOZSHv97BbseLLyLnqqDJkJcZzFLiCs1l ig5pA5w0pR2wNDrnrxNryXDBN4SPnacdwFfH6zYz3uhxxMMtmSeYY7Qy3WGOv1KY9DII swotAWUfA40pZ6MICEpOd1D0eWkha62ahgNFeTuVoM57TwyEBVBirT/eMEuQ+NdM97Ca 5q1g==
X-Gm-Message-State: ALoCoQkT9WXmnDWrL/zFVJ0yWSLVP/86OVn5nnHY4Qc/GBmYB9OfTy2r9jnWww/kSSc9/21zNqat
X-Received: by 10.140.146.138 with SMTP id 132mr5849949qhs.2.1433957237530; Wed, 10 Jun 2015 10:27:17 -0700 (PDT)
Received: from [192.168.1.110] (c-69-255-115-150.hsd1.md.comcast.net. [69.255.115.150]) by mx.google.com with ESMTPSA id 106sm4410855qge.22.2015.06.10.10.27.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 10:27:16 -0700 (PDT)
Message-ID: <55787375.7040808@nthpermutation.com>
Date: Wed, 10 Jun 2015 13:27:17 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
References: <556C4ACD.9040002@azet.org> <CABcZeBNsYmto4F-J0mFoxcq-qfL=NJrvDu67fyY9bpBmRp16mQ@mail.gmail.com> <556C51FC.807@azet.org> <20150601125302.GA19269@LK-Perkele-VII> <556C9AF4.7030607@nthpermutation.com> <87r3pp3803.fsf@latte.josefsson.org>
In-Reply-To: <87r3pp3803.fsf@latte.josefsson.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/M58EfbTUnjqzOrm_EQKv8sXfiHI>
Cc: tls@ietf.org
Subject: Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2015 17:27:20 -0000
On 6/5/2015 10:06 PM, Simon Josefsson wrote: > Michael StJohns <msj@nthpermutation.com> writes: > >> Instead, get a new allocation and write a document that looks like >> RFC5480 for the ED and Curve public keys. You want certificate >> representations for *both*. > I've started this for EdDSA: > https://tools.ietf.org/html/draft-josefsson-tls-ed25519-00 > > Are you saying it would be useful to also specify certificate formats > for Curve25519 ECDH keys? > > /Simon Sorry - I missed this in the pile. And yes for Curve25519. Here's my thoughts: Usually, you have a certificate with a public key in it that's used to sign an ephemeral (EC)DH public key. The EPK is used to derive a shared secret and everything downstream is derived from that. The session keys trace their authentication back through the shared secret, through the EPK and through the signature over the EPK to the certificate's public key. And the public key in the certificate chains back to some root. With key agreement keys such as ECDH, Curve25519 or DH, what you can do instead is to use the key in the certificate with the other side's certificate key, to derive one half of the total shared secret and the senders EPK with the receiver's ephemeral private key to derive the second half. Concatenate those and then derive your downstream keys from them. (e.g. ECDH (PermPrivate1, PermPublic2) || ECDH (EphemPrivate1, EphemPublic2) ) The certificate keys chain as before, so that you know that the first half of the shared secret is derived from authentic data and is itself authentic. Combining the first half of the shared secret with the second half still gives you authentic data (but results in a varied shared secret for each call). And that means downstream keys derived from the combined shared secrets can still be traced back to the certificate authentication root. The nice thing about this scheme (It's called a C(2,2) scheme in NISP SP800-56A parlance), is that you don't need to sign anything during a key agreement handshake. You still need traditional signature schemes over the certificates, but you don't actually need them in the handshake. There are other schemes where one side only has ephemeral keys (e.g. client without cert) where this still works - you end up with: ECDH (PermPrivate1, EphemPublic2) || ECDH (EphemPrivate1, EphemPublic2) This just works with the existing EC Prime and F2M curves as the key pairs can be used with both ECDSA and ECDH. In any event, going ahead and creating a certificate format for Curve25519 at the same time you do ED25519 probably makes sense given the two algorithms are family members and appear to share a representation. Mike
- [TLS] AES-OCB in TLS [New Version Notification fo… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Eric Rescorla
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Eric Rescorla
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Ilari Liusvaara
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Hubert Kario
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Jeffrey Walton
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Peter Bowen
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Russ Housley
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Jeffrey Walton
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Yaron Sheffer
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Jeffrey Walton
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Daniel Kahn Gillmor
- [TLS] EDDSA/Curve25519 identifiers: Was Re: AES-O… Michael StJohns
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Michael Hamburg
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Daniel Kahn Gillmor
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Rob Stradling
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Michael Hamburg
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Gunnar Wolf
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Peter Gutmann
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Simon Josefsson
- Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: A… Simon Josefsson
- Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: A… Salz, Rich
- Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: A… Peter Bowen
- Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: A… Michael StJohns
- Re: [TLS] EDDSA/Curve25519 identifiers: Was Re: A… Nico Williams
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Aaron Zauner
- Re: [TLS] AES-OCB in TLS [New Version Notificatio… Matt Caswell