summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--e3/52c960f6d71b1e0b254d1d9791b85b2e74d4c3241
1 files changed, 241 insertions, 0 deletions
diff --git a/e3/52c960f6d71b1e0b254d1d9791b85b2e74d4c3 b/e3/52c960f6d71b1e0b254d1d9791b85b2e74d4c3
new file mode 100644
index 000000000..43d1166a4
--- /dev/null
+++ b/e3/52c960f6d71b1e0b254d1d9791b85b2e74d4c3
@@ -0,0 +1,241 @@
+Delivery-date: Wed, 02 Jul 2025 04:41:58 -0700
+Received: from mail-qt1-f183.google.com ([209.85.160.183])
+ by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
+ (Exim 4.94.2)
+ (envelope-from <bitcoindev+bncBDWIFPUA4ICRB6VVSTBQMGQEVGQRLJQ@googlegroups.com>)
+ id 1uWvqf-0001Cs-IY
+ for bitcoindev@gnusha.org; Wed, 02 Jul 2025 04:41:58 -0700
+Received: by mail-qt1-f183.google.com with SMTP id d75a77b69052e-4a43ae0dcf7sf142040691cf.1
+ for <bitcoindev@gnusha.org>; Wed, 02 Jul 2025 04:41:57 -0700 (PDT)
+ARC-Seal: i=2; a=rsa-sha256; t=1751456511; cv=pass;
+ d=google.com; s=arc-20240605;
+ b=ft3h/Vc/eWnxe63Tecjd2CWoJCyofeQYIM48Zg/X90R9LHLD8kS8WwkMeJhPhcEe4m
+ JyfoDMFFzSix49ofdruG2paszSQ6KPGvBKEsi5tJse0yQ4t0yn8xHQaQ4KnxrMKcK/xX
+ Dzo8EuiL4MMNyKJNGYNj5i3Vb/uV7c521Ebxd63RByfbykoq6UyfbArM+eIs71E9FVbz
+ MSl4hObPMd+XIwsmNQyH1LPr0TcsUDDgH/s44oVAeD43tdv7aOBXV4mZZ23DX9nPkv7C
+ BNzv0hhfbapLWI3AowAy8Ve4gizIITbeKxSxGzfy/FX8NMBl2pTpLgbiA039L7SIkmwb
+ p4jA==
+ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
+ h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
+ :list-id:mailing-list:precedence:mime-version:references:in-reply-to
+ :date:to:from:subject:message-id:sender:dkim-signature;
+ bh=3Iq3cs3vfQHquHNf0yKQltoY7Gneg7rhgEXsE2X1ntw=;
+ fh=biQLkhsAtMTvm2vEEvTaYmt154icElPyBY6rwZKmMPI=;
+ b=kKc4lKKnbRCOYnEGKetbUim7b/door/x1IEgIRs/xetQ1y2UXf8oIIsyYB9AtJpfG9
+ Ex3+E8e/26pLJhqlQI1uMvsCxVyYRBGC9U2jwIbHc3WCEv1ekE4F9qD7gUITodSK9TAN
+ /207aRmUtTyqS4P6Cv49ZPyDGI4WYlB5S31HXiaskcuyFItF67Wgl2VR81fbBJFXjZy4
+ eEy3Efrb38qTP7RM6w2Tdaxfc7YzO2jdUmZ/tPlAz+H5vtjaeNZ5Z2+UvrVdoV24mSQF
+ q7V7HD60CP+x+hgPg9KNkASP1WKboHq/Rr/EEpFfeOsylaL6QOIbd7tJnIhIUaeF81L1
+ pxOQ==;
+ darn=gnusha.org
+ARC-Authentication-Results: i=2; gmr-mx.google.com;
+ dkim=pass header.i=@timruffing.de header.s=MBO0001 header.b=TV008ajg;
+ spf=pass (google.com: domain of crypto@timruffing.de designates 2001:67c:2050:0:465::101 as permitted sender) smtp.mailfrom=crypto@timruffing.de;
+ dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=timruffing.de
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=googlegroups.com; s=20230601; t=1751456511; x=1752061311; darn=gnusha.org;
+ h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
+ :list-id:mailing-list:precedence:x-original-authentication-results
+ :x-original-sender:mime-version:references:in-reply-to:date:to:from
+ :subject:message-id:sender:from:to:cc:subject:date:message-id
+ :reply-to;
+ bh=3Iq3cs3vfQHquHNf0yKQltoY7Gneg7rhgEXsE2X1ntw=;
+ b=QCsS8TmvtC1o5xqix+LhS1Jv3v2n1xt9bB1oQ4KGF65e27zgqqpLj03JifMh7vS2jY
+ zpWxfoLH8aGDH8mD1+3+ggKugOWFFz8ICraSl3lLUUp7KGXOTl6vOPGoh7EPgYuFwq5u
+ HT/3ewjPSZ6Maf2Fhwn3SjKQ/y/eyfPIwVxb7oQe7gK7hNq5FSoUBjAE8lLPXlIbNTsH
+ hPbBYpZDvuNYFc5HC2TjqJvAfzOiEVt08N6DwrjLe80VW09zfV49NrlK37ZeQmVI9DRP
+ 3mZmcO4c7ZieQNhxaT4OxDGRqq7fN4lwNa4UdyntGOVYFqDKBZN44uTvBlJ3kMGwdhmJ
+ FwWw==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20230601; t=1751456511; x=1752061311;
+ h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
+ :list-id:mailing-list:precedence:x-original-authentication-results
+ :x-original-sender:mime-version:references:in-reply-to:date:to:from
+ :subject:message-id:x-beenthere:x-gm-message-state:sender:from:to:cc
+ :subject:date:message-id:reply-to;
+ bh=3Iq3cs3vfQHquHNf0yKQltoY7Gneg7rhgEXsE2X1ntw=;
+ b=iXUOBsZGQ7G7HJ66/c663jFmsM5tf1aye+tfvEBCNOyMt1gcrNFF7t9xKB3WRQSEYj
+ oARGznkn767mE435HswVc47IAxkwcc3LxAYtVgWSw2v11iVrWHAbHamnTSb//4kONhf4
+ tp6PTv1md0MGTIE9WaEbBhWTuqiEp/o06X05gvKdB/cZ4w0kW7t7xWuGoWXKJkLVN8uj
+ q5ldVg7xcnO7UjpzFsViuT+2iS/QRdOxAL52ZClFTUxJ/QxhpuawwaEfk8W3a0TVtda6
+ xtAL6cHdLMSjU+ulfvzFuZvt7b0o+g/pQz3tGTylaOCSogf4/VN+vDl1VYbZhaNDsW7/
+ wE+w==
+Sender: bitcoindev@googlegroups.com
+X-Forwarded-Encrypted: i=2; AJvYcCUsSMsx8vmb2V6tTzg26CW7cQqYglDs1dOuIBHsH57gSJSaMEp/LxekVMlCLB2Q9gfPlrewkdv2D/Es@gnusha.org
+X-Gm-Message-State: AOJu0YyT+sBHoq3FJw5X61VaDIzxXuPz3E9SUKkLS/fY/a0YrlKk8aJ3
+ vCCwqK1Xfb9PFdtPQKWzmZxtPt3PPifeCo+Rxi19s6066nzt2R2hTSyC
+X-Google-Smtp-Source: AGHT+IF+y9vqcAL64BPYL5dmtdJcsXJoHEt3Ms5cI3XJjkgq9rEGt3pdqQogRRzQ5jSxGrg1IopvQA==
+X-Received: by 2002:ac8:5e0a:0:b0:494:b1f9:d683 with SMTP id d75a77b69052e-4a976ab1db3mr42900881cf.49.1751456510829;
+ Wed, 02 Jul 2025 04:41:50 -0700 (PDT)
+X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeLf6JUFdq307nzx2fXWRHWrbBcWHa+L7RRszXi4Gz5zw==
+Received: by 2002:ac8:5803:0:b0:477:78b2:dc08 with SMTP id d75a77b69052e-4a82ee59498ls34139261cf.0.-pod-prod-01-us;
+ Wed, 02 Jul 2025 04:41:46 -0700 (PDT)
+X-Forwarded-Encrypted: i=2; AJvYcCXVV+pWchaw5z7EnEK9pvaNP6t8GlESksYrFH0iirjedSzT6LFpuhEZ/MO7/+WjnwyX16AjrxjplylQ@googlegroups.com
+X-Received: by 2002:a05:620a:6844:b0:7c7:739d:5cea with SMTP id af79cd13be357-7d5c4798c57mr330969185a.35.1751456506363;
+ Wed, 02 Jul 2025 04:41:46 -0700 (PDT)
+Received: by 2002:a05:6504:d91:b0:2b1:9626:e73d with SMTP id a1c4a302cd1d6-2b5fb63a227msc7a;
+ Wed, 2 Jul 2025 04:36:15 -0700 (PDT)
+X-Forwarded-Encrypted: i=2; AJvYcCXRfAn01xfvOe/uhpzU/ibhQQbw6E5FdsfbIPgfqyWYAMU+Tx8+8zGnVIi02AdUnBL1mWIPbregj9i4@googlegroups.com
+X-Received: by 2002:a05:651c:487:b0:31e:261a:f3e2 with SMTP id 38308e7fff4ca-32dfff68830mr6761991fa.1.1751456172813;
+ Wed, 02 Jul 2025 04:36:12 -0700 (PDT)
+ARC-Seal: i=1; a=rsa-sha256; t=1751456172; cv=none;
+ d=google.com; s=arc-20240605;
+ b=SNx1q22r3q9K6jOj0X9UUgD2w+qzXu9JXYYWnG/UDrGR8BCs0e+x7kVtgl+nZop2hf
+ talK/aFPQLpOqC7sRL/u8GVmdcK5jQMU3C1NfIV05wLeUD0XQekTeUR9wbNPOiWo2+6u
+ rwiraPlqm3oJoZ3RW7zsJ9Nydk8EVw+4MSLqz7OL0S6EbNuqpJv2MsDYaK7EJ+h9Excj
+ btlIR3CJ51cn+sB1GbkPSSDRGcA/8yYbp2ptVizm1RdfhOIZe0+zfpMkKtay4q7UJd7o
+ t6A06+HPhzsSfVuw1aD9ZKvYQl++ioayCvjuuyVIGtpvayHJhwknS952lsufqVpNZoa0
+ oPAg==
+ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
+ h=mime-version:content-transfer-encoding:references:in-reply-to:date
+ :to:from:subject:message-id:dkim-signature;
+ bh=FzUnWzrZaG9QFzBmunDMZD7KFHeuHbSl5Krz/MxCN0c=;
+ fh=2EV9HtMw1QTzGSfUm2X/O0xVoxxmy5vUj8s0Z9ARrDA=;
+ b=Wv0OKXTdKGEDWucGEfQHuE0bs8aIXeMFV1aW1f9+UHOKgDxpv695u05C5dBrWDnpJj
+ b/7fkAL+aa3C4BJsZ66esISsoFE9RA+cM6aTuKuBleSv8GZ7NrjNFWd6VDQFX04/PkxI
+ Ru9tCko/qHri782ZJZUkwTJ3r2aR/mAaNG0dLt4kuKq8iEXJAAlPDPecFEMLLamIDGwl
+ it7L07qQ8NrmXidz88CEEoO6Q+w89fWwlllyIz3g+JOjTVV+TpXMlWVHN/IzbCfW6GFh
+ AQQfXRQdcDR/1OvD53hqQ9OguSz6yQOf+knxMSYb6dgf5y+VKK9RkMNRyYRcNbzmI3AZ
+ +jpw==;
+ dara=google.com
+ARC-Authentication-Results: i=1; gmr-mx.google.com;
+ dkim=pass header.i=@timruffing.de header.s=MBO0001 header.b=TV008ajg;
+ spf=pass (google.com: domain of crypto@timruffing.de designates 2001:67c:2050:0:465::101 as permitted sender) smtp.mailfrom=crypto@timruffing.de;
+ dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=timruffing.de
+Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org. [2001:67c:2050:0:465::101])
+ by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-32cd2c4275fsi5556341fa.0.2025.07.02.04.36.12
+ for <bitcoindev@googlegroups.com>
+ (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
+ Wed, 02 Jul 2025 04:36:12 -0700 (PDT)
+Received-SPF: pass (google.com: domain of crypto@timruffing.de designates 2001:67c:2050:0:465::101 as permitted sender) client-ip=2001:67c:2050:0:465::101;
+Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202])
+ (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
+ key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
+ (No client certificate requested)
+ by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4bXHsQ00ZVz9tK1;
+ Wed, 2 Jul 2025 13:36:10 +0200 (CEST)
+Message-ID: <437237c5f0debe352aafd0a184d6266c14d6e142.camel@timruffing.de>
+Subject: Re: [bitcoindev] Re: DahLIAS: Discrete Logarithm-Based Interactive
+ Aggregate Signatures
+From: Tim Ruffing <crypto@timruffing.de>
+To: waxwing/ AdamISZ <ekaggata@gmail.com>, Bitcoin Development Mailing List
+ <bitcoindev@googlegroups.com>
+Date: Wed, 02 Jul 2025 13:36:08 +0200
+In-Reply-To: <3f23ebaa-02c7-45d1-bf57-9baf48c133a3n@googlegroups.com>
+References: <be3813bf-467d-4880-9383-2a0b0223e7e5@gmail.com>
+ <039cb943-5c94-44ba-929b-abec281082a8n@googlegroups.com>
+ <604ca4d2-48c6-4fa0-baa6-329a78a02201n@googlegroups.com>
+ <f9e082e3-4079-40b6-aa49-5d1b9b3b1e29@gmail.com>
+ <a9f133ff-1d8e-45a3-8186-79fb52bbd467n@googlegroups.com>
+ <3f23ebaa-02c7-45d1-bf57-9baf48c133a3n@googlegroups.com>
+Content-Type: text/plain; charset="UTF-8"
+MIME-Version: 1.0
+X-Rspamd-Queue-Id: 4bXHsQ00ZVz9tK1
+X-Original-Sender: crypto@timruffing.de
+X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
+ header.i=@timruffing.de header.s=MBO0001 header.b=TV008ajg; spf=pass
+ (google.com: domain of crypto@timruffing.de designates 2001:67c:2050:0:465::101
+ as permitted sender) smtp.mailfrom=crypto@timruffing.de; dmarc=pass
+ (p=NONE sp=NONE dis=NONE) header.from=timruffing.de
+Precedence: list
+Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
+List-ID: <bitcoindev.googlegroups.com>
+X-Google-Group-Id: 786775582512
+List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
+List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
+List-Archive: <https://groups.google.com/group/bitcoindev
+List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
+List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
+ <https://groups.google.com/group/bitcoindev/subscribe>
+X-Spam-Score: -0.8 (/)
+
+First of all, again great to see that you look so carefully at the
+paper.
+
+Your observation is right: If each participant has a distinct b_i as
+you've sketched, then the duplicate checks can be omitted. And I tend
+to agree that this is more natural scheme. In fact, this is where we
+started, and we had a security proof of this (though without tweaking
+worked out) in an earlier unpublished draft of the paper, and only
+afterwards we found a scheme with a single b.
+
+The reason we why prefer the scheme with a single b is simply
+efficiency. The current signing protocol needs 3 group exponentiations
+(i.e., scalar-point multiplications). With separate b values, one of
+those becomes a multi-exponentiation of size n-1, which is much slower
+and needs O(n/log n) time instead of O(1).
+
+Another, very minor and optional efficiency benefit is that the
+coordinator can take care of the computation of the final R2 and send
+it to the participants. (But that's really minor, because the
+coordinator needs to send the individual R_{2,i} values anyway.)
+
+Intuitively, we manage to get away with a single b by (ab)using the R_i
+values as ephemeral identifiers for the participants, which makes it
+possible to distinguish them even if they happen to have the same
+public key (or, in other words, if it's the same participant that joins
+the session more than once). This is why we need the uniqueness check,
+to make sure that the identifiers are unique.
+
+And yes, the uniqueness check looks a bit strange at first glance, but
+(as the proof shows) there should be nothing wrong with it. One could
+argue that the uniqueness check is a potential footgun in practice
+because an implementation could omit it by accident, and would still
+"work" and produce signatures. But we find this not really convincing
+because it's possible to create a failing test vector for this case.
+
+We didn't talk about identifying disruptive participants in the paper
+at all, but one could also argue that the uniqueness check creates a
+problem if the honest participants want to figure out who disrupted a
+session: if malicious participant i copies from honest participant j,
+then how the others tell who of them to exclude?
+
+But if you think about it, that's not a real issue. In any case,
+identifying disruptive participants will work reliably only if the
+coordinator is honest, so let's assume this. And then, if additionally
+the participants have secure channels to the coordinator, then no
+malicious can steal the R_{2,j} of an honest participant j. So, if the
+coordinator sees that R_{2,i} = R_{2,j}, the right conclusion is that
+they are colluding and both malicious.
+
+
+On Mon, 2025-06-16 at 12:35 -0700, waxwing/ AdamISZ wrote:
+> So here's my question: why does the signing context, represented by
+> "b", in the aggregate R-value, need to be a fixed value across
+> signing indices? Clearly if we have one b-value, H-non(ctx), where
+> ctx is ((P1, m1), (P2, m2),..) [1], then it is easy to sum all the
+> R1,i = R1 and then sum all the R2,i values = R2 and then R = R1 +
+> bR2, exploiting the linearity. But why do we have to? If coefficient
+> b were different per participant, i.e. b_i = H(ctx, m_i, P_i) then it
+> makes that sum "harder" but still trivial for all participants to
+> create/calculate. All participants can still agree on the correct
+> aggregate "R" before making their second stage output s_i.
+>
+> If I am right that that is possible, then the gain is clear (I
+> claim!): the attacks previously described, involving "attacker uses
+> same key with different message" fail. The first thing I'd note is
+> that the basic thwarting of ROS/Wagner style attacks still exists,
+> because the b_i values still include the whole context, meaning
+> grinding your nonce doesn't allow you to control the victim's
+> effective nonce. But because in this case, you cannot create
+> scenarios like in Appendix B, i.e. in the notation there:
+> F(X1, m1(0), out1, ctx) = F(X1, m1(1), out1, ctx) is no longer true
+> because b no longer only depends on global ctx, but also on m1 (b_1 =
+> Hnon(ctx, m1, P1) is my proposal),
+>
+> then the "Property 3" does not apply and so (maybe? I haven't thought
+> it through properly) the duplication checks as currently described,
+> would not be needed.
+>
+> I feel like this alternate version is more intuitive: I see it as
+> analogous to (though not the same) as Fiat-Shamir hashing, where the
+> main idea is to fix the actual context of the proof; but the context
+> of *my* partial signature for this aggregate, is not only ((P1, m1),
+> (P2, m2),..) but also my particular entry in that list.
+>
+
+--
+You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
+To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
+To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/437237c5f0debe352aafd0a184d6266c14d6e142.camel%40timruffing.de.
+