Re: [Cfrg] key as message prefix => multi-key security
"D. J. Bernstein" <djb@cr.yp.to> Tue, 13 October 2015 12:31 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
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 685B81B2FD9 for <cfrg@ietfa.amsl.com>; Tue, 13 Oct 2015 05:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.596
X-Spam-Level:
X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] 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 S1hxqX3Srsa8 for <cfrg@ietfa.amsl.com>; Tue, 13 Oct 2015 05:31:40 -0700 (PDT)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 8CAC51ACECF for <cfrg@ietf.org>; Tue, 13 Oct 2015 05:31:39 -0700 (PDT)
Received: (qmail 32600 invoked by uid 1017); 13 Oct 2015 12:32:00 -0000
Received: from unknown (unknown) by unknown with QMTP; 13 Oct 2015 12:32:00 -0000
Received: (qmail 21136 invoked by uid 1000); 13 Oct 2015 12:31:28 -0000
Date: Tue, 13 Oct 2015 12:31:28 -0000
Message-ID: <20151013123128.21134.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@ietf.org
Mail-Followup-To: cfrg@ietf.org
In-Reply-To: <20150930225622.21805.qmail@cr.yp.to>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/ZXanwSuWcQJ5ldpBBEA5SpcIlM4>
Subject: Re: [Cfrg] key as message prefix => multi-key security
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2015 12:31:42 -0000
I now have a paper online analyzing multi-user signature security: http://cr.yp.to/papers.html#multischnorr There's also a separate project analyzing the security of EdDSA's r-generation mechanism. Nothing is online yet from that project but the quantitative multi-user security results look completely satisfactory _assuming_ a double-length hash. Overall I'd say that the multi-user proof picture is shaping up nicely, leaving very few ways that an attack breaking 1 out of N signature keys could be faster than an attack breaking a single targeted key. However, I see one remaining theoretical concern, and there are ways that Ed25519 signers could be tweaked to eliminate this concern; I think this is worth some discussion. Background: Let's say you're an attacker trying to break 1 of N discrete logs. Assume that each of the N users has chosen a scalar completely at random from {0,1,...,l-1}, where the base point has prime order l. Can you succeed more quickly for large N than for N=1? The answer is no. Any algorithm that breaks 1 of N discrete logs can be reused to break a single targeted discrete log at the same speed and with the same success probability: * Take the original target kB. * Choose random r_1,r_2,...,r_N. * Apply the 1-of-N algorithm to kB+r_1 B,kB+r_2 B,...,kB+r_N B. * If the 1-of-N algorithm successfully finds the jth discrete log k+r_j mod l, simply subtract r_j mod l, and you've successfully found k. The point is that discrete logs in {0,1,...,l-1} have a "random self-reduction", a very strong type of "worst-case-to-average-case reduction". Now here's the theoretical concern in a nutshell. Assume that each of the N users has instead chosen a scalar from the half-size interval {0,1,...,ceil(l/2)-1}. Does this help you? This is pretty much the situation in Ed25519. The range of secret scalars in Ed25519 is chosen to match the range of secret scalars in X25519, for people who want to reuse X25519 code; X25519 chooses that range as 2^251 through 2^252-1 (times a factor of 8 that isn't relevant to this analysis), so that a "start with the first 1 bit" Montgomery ladder has constant length, while people who reuse Weierstrass code don't bump into infinity; l is slightly above 2^252 in Curve25519. Is this an issue? For N=1 this is a well-known question. On the provability side, the same random self-reduction shows that you can't gain more than a factor F in success probability from targeting an interval of size l/F. On the cryptanalysis side, "kangaroos" do gain a probability factor roughly proportional to F (with sqrt(l/F) computations, kangaroos have success probability roughly 1, while "rho" against the whole interval has success probability only roughly 1/F), but they also lose a constant factor, and after tons of work on the constant factor there still doesn't seem to be any gain for F=2. I already commented on this in a message last year. For N>1, however, I don't see any literature on this question. The same random self-reduction shows that the probability gain can't beat F^N, but that's not useful when N is large and F is noticeably larger than 1. A different argument produces an upper bound of NF, but that's still not satisfactory. In Section 5 of the multischnorr paper I've outlined a tight proof compared to finding 1 discrete log in an interval of length l/NF, but that's also not satisfactory. Even if the rho probability curve is optimal, all of these proofs are consistent with speedup factors proportional to sqrt(min{F^N,NF}): e.g., breaking 1 of 2^40 keys with F=2 in only 2^105 operations. The looseness here is much smaller than the looseness in, e.g., the Pointcheval--Stern reduction from single-key discrete-log attacks to single-key generic-hash Schnorr-signature attacks. However, those two problems are tightly related for generic-group attacks, and Schnorr signatures are well known to cryptanalysts; many experts would be surprised if there were a way to exploit the Pointcheval--Stern looseness for Schnorr signatures on any standard elliptic curve. For comparison, I think that * generic-group analyses and * actual cryptanalytic efforts are both missing for the 1-of-N interval question. Here are two ways to eliminate this concern: * Take an extra bit in the Ed25519 secret scalars: specifically, take a 256-bit scalar, clear bit positions 0 1 2, and set bit position 255 (rather than setting 254 and clearing 255). This is, aside from the factor of 8, the same as taking the range 2^252 through 2^253-1. This would also work for X25519, so it's still compatible with a merged code base. It _does_ mean, for both X25519 and Ed25519, that there's no longer a structural prohibition on key 0, and on staying away from infinity in standard Weierstrass scalarmult methods. Of course, the key hashing in Ed25519 means that even a malicious RNG can't target any particular scalars, and maybe the same type of hashing should also be done for X25519. (On the other hand, X25519 was designed from the outset to be usable without hash functions.) * Hide the top bit of the scalars: i.e., send |A| rather than A, where A is the public key. This is tantamount to expanding the key interval to {-2^252+1,...,-2^251,2^251,...,2^252-1}, which is indistinguishable from {0...l-1}, so it should reenable the usual random self-reduction. X25519 already does something equivalent to this. For Ed25519 it's simplest to clear the Edwards x sign bit in public keys, and include a constant-time conditional negation of the scalar in the signing procedure. Both of these are compatible with existing Ed25519 verifiers. For the first approach there's an issue of testing Weierstrass implementations, but I'm not sure this noticeably affects the probability of obtaining security with such implementations in any case. The second approach is fingerprintable, and if it becomes popular enough then people might start leaving out the corresponding conditional negation in verifiers--- so if this is going to be done at all then it would be best for everyone to agree on doing it. The parameter examples in the EdDSA paper already take the first approach for Ed41417, Ed448, and Ed521. In each of these cases, l is slightly _below_ a power of 2 rather than slightly above, so there's no hope of structurally avoiding the 0 cases anyway. Does anyone care? ---Dan
- [Cfrg] EC signature: next steps Alexey Melnikov
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Watson Ladd
- [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Dan Brown
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- [Cfrg] Side inputs to signature systems D. J. Bernstein
- Re: [Cfrg] Side inputs to signature systems Natanael
- Re: [Cfrg] EC signature: next steps Simon Josefsson
- Re: [Cfrg] Side inputs to signature systems Michael Hamburg
- Re: [Cfrg] EC signature: next steps Rene Struik
- Re: [Cfrg] EC signature: next steps David Jacobson
- Re: [Cfrg] EC signature: next steps Mike Hamburg
- Re: [Cfrg] EC signature: next steps William Whyte
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Ilari Liusvaara
- Re: [Cfrg] EC signature: next steps Stephen Farrell
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] EC signature: next steps Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… Dan Brown
- [Cfrg] key as message prefix => multi-key security D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Paterson, Kenny
- Re: [Cfrg] key as message prefix => multi-key sec… Sven Schäge
- Re: [Cfrg] key as message prefix => multi-key sec… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] key as message prefix => multi-key sec… William Whyte
- Re: [Cfrg] key as message prefix => multi-key sec… Bill Cox
- Re: [Cfrg] key as message prefix => multi-key sec… Andrey Jivsov
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Eike Kiltz
- Re: [Cfrg] key as message prefix => multi-key sec… D. J. Bernstein
- Re: [Cfrg] key as message prefix => multi-key sec… Simon Josefsson