Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 22 April 2016 17:12 UTC
Return-Path: <ilariliusvaara@welho.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2015B12B038 for <cfrg@ietfa.amsl.com>; Fri, 22 Apr 2016 10:12:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 jnVTBkSbiaE4 for <cfrg@ietfa.amsl.com>; Fri, 22 Apr 2016 10:12:34 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 993AF12D872 for <cfrg@ietf.org>; Fri, 22 Apr 2016 10:12:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id BFEAB4A61 for <cfrg@ietf.org>; Fri, 22 Apr 2016 20:12:31 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id DTOdHK4NhW74 for <cfrg@ietf.org>; Fri, 22 Apr 2016 20:12:31 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5C52E2310 for <cfrg@ietf.org>; Fri, 22 Apr 2016 20:12:31 +0300 (EEST)
Date: Fri, 22 Apr 2016 20:12:28 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "cfrg@ietf.org" <cfrg@ietf.org>
Message-ID: <20160422171228.GC28353@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160421043947.GA24394@LK-Perkele-V2.elisa-laajakaista.fi> <alpine.GSO.1.10.1604211349530.26829@multics.mit.edu> <20160421195014.GA26169@LK-Perkele-V2.elisa-laajakaista.fi> <87zismzo9o.fsf@alice.fifthhorseman.net> <20160422062121.GA27448@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnVd28WHT+wpMxVd+XczkiJmExkjTewG5B_a1uKgTMo7+A@mail.gmail.com> <20160422091618.GB27448@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnUGSWYe+Z4t63GpNipLLUx4G43U+ARL+jYL825k6QraMw@mail.gmail.com> <20160422112842.GA28192@LK-Perkele-V2.elisa-laajakaista.fi> <87mvoly84j.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <87mvoly84j.fsf@alice.fifthhorseman.net>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/KjYDx0JIDDBO4GGbOzyjELyRGiU>
Subject: Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final proposal for domain separation (context labels) for ed25519
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2016 17:12:38 -0000
On Fri, Apr 22, 2016 at 11:29:32AM -0400, Daniel Kahn Gillmor wrote: > On Fri 2016-04-22 07:28:43 -0400, Ilari Liusvaara wrote: > > 1) More vulernable to attacks there. > > can you describe the attacks you're concerned about? > > > Or just split on key. May be bit painful (and sometimes not possible > > at all, e.g. TLS versus CSR) but much better than dealing with the > > API mess. > > I don't think the API mess is as worrisome as you do. We've had API > changes for primitives in the past (i already mentioned HKDF's evolution > from previous context-free KDF schemes), and they haven't caused the sky > to fall. We already have a plan for how people can continue using the > primitive without a context label, and we can provide a well-defined > (granted, suboptimal) way for people to use it *with* a context label as > well. Well, I don't recall seeing KDF interface. But then, given crazy stuff I have seen in at least one WG, signature APIs might not be that standardized (outside things like PKCS#11, that are bit bad matches anyway). > >> I'm having a hard time understanding what you want out of this > >> conversation. Maybe you could try to explain whether you think that > >> context is a good idea and maybe how you would prefer that we solve > >> the problem. > > > > It is not possible to retrofit contexts into Ed25519 in a way that > > I would be even remotely comfortable with. This is because Ed25519 > > lacks any space to put any extensions to. > > Right, this is the backward-compatibility issue. So, we're trying to > propose a standard way that people who want contexts can use them with > Ed25519 that doesn't break backward compatibility with context-free > Ed25519. > > This is guaranteed to be weaker protection than a scheme that included > contexts from the beginning; but we're not at the beginning -- the > deployed base of "pure" Ed25519 is too large. > > However, it seems likely to offer better protection than either: > > a) no one does domain separation at all even in cases where key > separation is not possible > > b) different protocols make up their own domain separation mechanisms, > which may or may not collide with each other > > No one is arguing that this is a perfect thing to do for Ed25519, we're > arguing that we should do something which is better than nothing at > all. This is the curse of trying to improve a deployed base. it should > be familiar to anyone who works at the IETF :/ There exists pretty close to trivial transform that transforms any signature scheme into DIFFERENT signature scheme (that uses original scheme as subroutine) with context input. Weak signatures are transformed into weak signatures with context, strong signatures are transformed into strong signatures with context. > > Just adding contexts to Ed25519 without splitting variant would > > leave it open for trivial attacks (or cryptographic screwedness > > I really do not want to see). > > Are there other "trivial attacks" beyond confusing signature with a sane > context with a context-free signature? Is there other cryptographic > screwedness we should be aware of? Yes, trivial existential forgeries. And attempts to look at how prefixing the context into inner hash would fare turned into mess. > I don't understand how to split the variant in a way that is > successfully incompatible with "pure" Ed25519, since as you say Ed25519 > has no extension mechanism. You can add contexts, only you get different scheme (which needs different keys). If you can compute the result using existing Ed25519 code as-is is independent. -Ilari
- [Cfrg] draft-irtf-cfrg-eddsa -- one final proposa… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Paterson, Kenny
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Salz, Rich
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Salz, Rich
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Russ Housley
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… David Jacobson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- [Cfrg] Side inputs to signature systems, take 2 D. J. Bernstein
- Re: [Cfrg] Side inputs to signature systems, take… Natanael
- Re: [Cfrg] Side inputs to signature systems, take… David Jacobson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Daniel Kahn Gillmor
- Re: [Cfrg] Side inputs to signature systems, take… Daniel Kahn Gillmor
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Benjamin Kaduk
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Ilari Liusvaara
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Simon Josefsson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Martin Thomson
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Bryan Ford
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Watson Ladd
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Dang, Quynh (Fed)
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Bryan Ford
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… Richard Outerbridge
- Re: [Cfrg] draft-irtf-cfrg-eddsa -- one final pro… D. J. Bernstein