From: waxwing/ AdamISZ <ekaggata@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: DahLIAS: Discrete Logarithm-Based Interactive Aggregate Signatures
Date: Wed, 30 Apr 2025 08:54:46 -0700 (PDT) [thread overview]
Message-ID: <a9f133ff-1d8e-45a3-8186-79fb52bbd467n@googlegroups.com> (raw)
In-Reply-To: <f9e082e3-4079-40b6-aa49-5d1b9b3b1e29@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4406 bytes --]
> That partial signatures do not leak information about the secret key x_k
is
implied by the security theorem for DahLIAS: If information would leak, the
adversary could use that to win the unforgeability game. However, the
adversary
doesn't win the game unless the adversary solves the DL problem or finds a
collision in hash function Hnon.
OK, so that's maybe a theoretical confusion on my part, I'm thinking of the
HVZK property of the Schnorr ID scheme, which "kinda" carries over into the
FS transformed version with a simulator (maybe? kinda?). Anyway this is a
sidetrack and not relevant to the paper, so I'll stop on that.
> This is a very interesting point, probably out of scope for the paper. A
single-party signer, given secret keys xi, ..., xn for public keys X1, ...,
Xn
can draw r at random, compute R := r*G and then set s := r + c1*x1 + ... +
cn*xn. So this would only require a single group multiplication.
I feel bad for saying so, but I absolutely do believe it's in scope of the
paper :) If there is a concrete, meaningful optimisation that's both
possible and sensible (and as you say, there is such an ultra-simple
optimisation ... I guess that's entirely correct!), then it should be
included there and not elsewhere. Why? Because it's exactly the kind of
thing an engineer might want to do, but it's definitely not their place to
make a judgement as to whether it's safe or not, given that these protocols
are such a minefield. I'd say even if there is *no* such optimisation
possible it's worth saying so.
I guess the counterargument is that it's suitable for a BIP not the paper?
But I'd disagree, this isn't purely a bitcoin thing.
On the third paragraph, yeah, as per earlier email, I realised that that
just doesn't work.
On Wednesday, April 30, 2025 at 9:03:34 AM UTC-6 Jonas Nick wrote:
> Thanks for your comments.
>
> > That side note reminds me of my first question: would it not be
> appropriate
> > to include a proof of the zero knowledgeness property of the scheme, and
> > not only the soundness? I can kind of accept the answer "it's trivial"
> > based on the structure of the partial sig components (s_k = r_k1 + br_k2
> +
> > c_k x_k) being "identical" to baseline Schnorr?
>
> That partial signatures do not leak information about the secret key x_k is
> implied by the security theorem for DahLIAS: If information would leak, the
> adversary could use that to win the unforgeability game. However, the
> adversary
> doesn't win the game unless the adversary solves the DL problem or finds a
> collision in hash function Hnon.
>
> > The side note also raises this point: would it be a good idea to
> explicitly
> > write down ways in which the usage of the scheme/structure can, and
> cannot,
> > be optimised for the single-party case?
>
> This is a very interesting point, probably out of scope for the paper. A
> single-party signer, given secret keys xi, ..., xn for public keys X1,
> ..., Xn
> can draw r at random, compute R := r*G and then set s := r + c1*x1 + ... +
> cn*xn. So this would only require a single group multiplication.
>
> > On that last point about "proof of knowledge of R", I suddenly realised
> > it's not a viable suggestion: of course it defends against key
> subtraction
> > attacks, but does not defend at all against the ability to grind nonces
> > adversarially in a Wagner type attack
>
> We believe Appendix B provides a helpful characterization of "Wagner-style"
> vulnerabilities. Roughly speaking, it shows that schemes where the
> adversary can
> ask the signer to produce a partial signature s = r + c*x or s' = r + c'*x
> such
> that c != c' then the scheme is vulnerable. In your "proof of knowledge of
> R
> idea", the adversary can choose to provide either R2 or R2' in a signing
> request, which would result in the same "effective nonce" r being used be
> the
> signer but different challenges c and c'.
>
--
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/a9f133ff-1d8e-45a3-8186-79fb52bbd467n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5189 bytes --]
prev parent reply other threads:[~2025-05-01 3:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 16:27 [bitcoindev] " Jonas Nick
2025-04-19 16:28 ` [bitcoindev] " waxwing/ AdamISZ
2025-04-22 15:29 ` Jonas Nick
2025-04-25 16:08 ` waxwing/ AdamISZ
2025-04-25 16:41 ` Jonas Nick
2025-04-26 15:30 ` waxwing/ AdamISZ
2025-04-26 17:05 ` waxwing/ AdamISZ
2025-04-30 7:59 ` Jonas Nick
2025-04-30 15:54 ` waxwing/ AdamISZ [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a9f133ff-1d8e-45a3-8186-79fb52bbd467n@googlegroups.com \
--to=ekaggata@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox