📅 Original date posted:2023-07-26
🗒️ Summary of this message: POSK (proof of secret key) is not a perfect solution for preventing rogue key attacks and has logistical difficulties in implementation.
📝 Original message:
On Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wrote:
> personally, i think *any* time a public key is transmitted, it should come
> with a "proof of secret key". it should be baked-in to low level
> protocols so that people don't accidentally create vulns. alt discussion
> link: https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406
>
POSK is not a panacea. For example, if you were to try to eliminate
rogue key attacks in MuSig by using POSK rather than by rerandomizing
the keys, the last person to contribute a key could add a Taproot
commitment to their key, thereby modifying the final key to have a
Taproot spending path that other participants don't know about. If they
did this, they'd have no problem producing a POSK since Taproot
commitments don't affect knowledge of the secret key.
POSKs are also logistically difficult to produce in many contexts. They
essentially require an interactive challege-response (otherwise somebody
could just copy a POSK from some other source), meaning that all
participants need to be online and have secret key access at key setup
time.
In some contexts maybe it's sufficient to have a static POSK. Aside from
the complexity of determining this, you then need a key serialization
format that includes the POSK. There are standard key formats for all
widely used EC keys but none have a facility for this. If you are trying
to use already-published keys that do not have a POSK attached, you are
out of luck.
If your protocol requires POSKs to be provably published, you also run
into difficulties because they don't make sense to embed on-chain (since
blockchain validators don't care about them, and they're twice as big as
the keys themselves) so you need to establish some other publication
medium.
If you want to support nested multisignatures, you need to jointly
produce POSKs, which requires its own protocol complexity.
The MuSig and MuSig2 papers say essentially the same thing as the above;
it's why we put so much effort into developing a scheme which was
provably secure in the plain public key model, which means that POSKs
are superfluous and you don't need to deal with all these logistical
hurdles.
--
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web: https://www.wpsoftware.net/andrew
The sun is always shining in space
-Justin Lewis-Webster
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230726/84e90df1/attachment.sig>
📅 Original date posted:2023-07-26
🗒️ Summary of this message: Attacks on nonces and challenges cannot be prevented by proving knowledge of the signing key (proof of possession, PoP).
📝 Original message:
None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
attack on the nonces, I mentioned an attack on the challenge c) can be prevented
by proving knowledge of the signing key (usually known as proof of possession,
PoP).
📅 Original date posted:2023-07-26
🗒️ Summary of this message: Proving knowledge of the r values used in generating each R can prevent the Wagner attack, not signing or secret keys.
📝 Original message:
Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
knowledge of the r values used to generate each R used prevents the Wagner
attack, no?
On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick
> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
> attack on the nonces, I mentioned an attack on the challenge c) can be
> prevented
> by proving knowledge of the signing key (usually known as proof of
> possession,
> PoP).
>
-------------- next part --------------
An HTML attachment was scrubbed...
📅 Original date posted:2023-07-26
🗒️ Summary of this message: The email discusses attacks on nonces and challenges in cryptography and the need for proof of knowledge of signing keys to prevent them.
📝 Original message:
correct. you cannot select R if it is shipped with a POP
On Wed, Jul 26, 2023, 4:35 PM Tom Trevethan
> Not 'signing' but 'secret' i.e. the r values (ephemeral keys). Proof of
> knowledge of the r values used to generate each R used prevents the Wagner
> attack, no?
>
> On Wed, Jul 26, 2023 at 8:59 PM Jonas Nick
>
>> None of the attacks mentioned in this thread so far (ZmnSCPxj mentioned an
>> attack on the nonces, I mentioned an attack on the challenge c) can be
>> prevented
>> by proving knowledge of the signing key (usually known as proof of
>> possession,
>> PoP).
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
📅 Original date posted:2023-07-24
🗒️ Summary of this message: The sender is discussing with Jonas the need for a method to blind the value of c in order to prevent the server from learning the value of m.
📝 Original message:
Hi Jonas,
Seems you are right: for every tx, compute c from the on-chain data, and
the server can match the c to the m (tx). So there would need to be a
method for blinding the value of c.
On Mon, Jul 24, 2023 at 4:39 PM Jonas Nick
> > Party 1 never learns the final value of (R,s1+s2) or m.
>
> Actually, it seems like a blinding step is missing. Assume the server
> (party 1)
> received some c during the signature protocol. Can't the server scan the
> blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as
> in
> signature verification and then check c == c'? If true, then the server
> has the
> preimage for the c received from the client, including m.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230724/2bc0b366/attachment.html>
📅 Original date posted:2023-07-26
🗒️ Summary of this message: Blind Schnorr signatures can solve the issue of blinding, but not the problem of client-controlled forged signatures. Recent work proposes alternative approaches for blind Schnorr signatures.
📝 Original message:
While this may solve blinding, I don't see how it solves the problem that the
client can forge signatures because the client is in control of challenge e'.
This is not special to MuSig(2), but is also the reason why original blind
Schnorr signatures are insecure (as demonstrated in David Wagner's "A
Generalized Birthday Problem" paper).
For some more recent work on blind Schnorr signatures, see:
- https://eprint.iacr.org/2019/877.pdf Blind Schnorr Signatures and Signed
ElGamal Encryption in the Algebraic Group Mode
- https://eprint.iacr.org/2020/1071.pdf On Pairing-Free Blind Signature Schemes
in the Algebraic Group Model
In particular, the first paper proposes a less-efficient variant of blind
Schnorr signatures that is secure under concurrent signing if the "mROS" problem
is hard (which is imho plausible). Another potential approach is using
commitments and a ZKP as I mentioned earlier in this thread. This scheme is
"folklore", in the sense that it is being discussed from time to time but isn't
specified and does not have a security proof as far as I am aware.
📅 Original date posted:2023-07-26
🗒️ Summary of this message: The protocol described in the text is an interesting idea for incorporating 2FA authentication into blind signing. However, there may be vulnerabilities in the protocol that need to be addressed.
📝 Original message:
It's an interesting idea for a protocol. If I get it right, your basic idea here is to kind of "shoehorn" in a 2FA authentication, and that the blind-signing server has no other function than to check the 2FA?
This makes it different from most uses of blind signing, where *counting* the number of signatures matters (hence 'one more forgery etc). Here, you are just saying "I'll sign whatever the heck you like, as long as you're authorized with this 2FA procedure".
Going to ignore the details of practically what that means - though I'm sure that's where most of the discussion would end up - but just looking at your protocol in the gist:
It seems you're not checking K values against attacks, so for example this would allow someone to extract the server's key from one signing:
1 Alice, after receiving K2, sets K1 = K1' - K2, where the secret key of K1' is k1'.
2 Chooses b as normal, sends e' as normal.
3 Receiving s2, calculate s = s1 + s2 as normal.
So since s = k + ex = (k' + bx) + ex = k' + e'x, and you know s, k' and e', you can derive x. Then x2 = x - x1.
(Gist I'm referring to: https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb)
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, July 26th, 2023 at 03:44, moonsettler via bitcoin-dev
> Hi All,
>
> I believe it's fairly simple to solve the blinding (sorry for the bastard notation!):
>
> Signing:
>
> X = X1 + X2
> K1 = k1G
> K2 = k2G
>
> R = K1 + K2 + bX
> e = hash(R||X||m)
>
> e' = e + b
> s = (k1 + e'*x1) + (k2 + e'*x2)
> s = (k1 + k2 + b(x1 + x2)) + e(x1 + x2)
>
> sG = (K1 + K2 + bX) + eX
> sG = R + eX
>
> Verification:
>
> Rv = sG - eX
> ev = hash(R||X||m)
> e ?= ev
>
> https://gist.github.com/moonsettler/05f5948291ba8dba63a3985b786233bb
>
> Been trying to get a review on this for a while, please let me know if I got it wrong!
>
> BR,
> moonsettler
>
>
> ------- Original Message -------
> On Monday, July 24th, 2023 at 5:39 PM, Jonas Nick via bitcoin-dev bitcoin-dev at lists.linuxfoundation.org wrote:
>
>
>
> > > Party 1 never learns the final value of (R,s1+s2) or m.
> >
> > Actually, it seems like a blinding step is missing. Assume the server (party 1)
> > received some c during the signature protocol. Can't the server scan the
> > blockchain for signatures, compute corresponding hashes c' = H(R||X||m) as in
> > signature verification and then check c == c'? If true, then the server has the
> > preimage for the c received from the client, including m.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev