Add anti nonce-sidechannel protocol to schnorrsigs [̶a̶l̶t̶e̶r̶n̶a̶t̶i̶v̶e̶]̶ #590

pull jonasnick wants to merge 8 commits into bitcoin-core:master from jonasnick:schnorrsig-s2c-only-new-ans changing 16 files +2445 −7
  1. jonasnick commented at 1:35 pm on February 15, 2019: contributor
    This is an alternative to #572 based on #589 (EDIT: this seems to be generally preferred now). It’s a demonstration that the anti nonce-sidechannel protocol can be build just as well on #589 as on #588.
  2. jonasnick cross-referenced this on Feb 15, 2019 from issue Allow sign-to-contract commitments in schnorrsigs [̶a̶l̶t̶e̶r̶n̶a̶t̶i̶v̶e̶]̶ by jonasnick
  3. in include/secp256k1_schnorrsig.h:103 in ae5fb7f8f1 outdated
    82+/** Create a randomness commitment on the host as part of the Anti Nonce Sidechannel Protocol.
    83+ *
    84+ *  Returns 1 on success, 0 on failure.
    85+ *  Args:              ctx: pointer to a context object (cannot be NULL)
    86+ *  Out: rand_commitment32: pointer to 32-byte array to store the returned commitment (cannot be NULL)
    87+ *  In:             rand32: the 32-byte randomness to commit to (cannot be NULL)
    


    real-or-random commented at 2:54 pm on February 15, 2019:

    Maybe it’s even better to make this function responsible for calling secp256k1_rand256 to avoid that the user screws up when producing randomness.

    (But then the user can’t use his fancy hardware RNG… If we want to support that, then maybe there could also a callback to a randomness function, and if it’s NULL, then just call lsecp256k1_rand256. But in general, I don’t like the idea of the user providing randomness, unless really necessary.)

  4. real-or-random commented at 2:55 pm on February 15, 2019: contributor
    Concept ACK
  5. in include/secp256k1_schnorrsig.h:72 in ae5fb7f8f1 outdated
    67+ *  1. The host draws the randomness, commits to it with the `anti_nonce_sidechan_host_commit`
    68+ *     function and sends the commitment to the client.
    69+ *  2. The client commits to its sign-to-contract original nonce (which is the nonce without the
    70+ *     sign-to-contract tweak) using the hosts commitment by calling the
    71+ *     `secp256k1_schnorrsig_anti_nonce_sidechan_client_commit` function. The client sends the
    72+ *     rusulting commitment to the host
    


    benma commented at 9:59 am on June 11, 2019:
    rusulting -> resulting :)
  6. in include/secp256k1_schnorrsig.h:123 in ae5fb7f8f1 outdated
    102+ *                       be NULL)
    103+ *  In:           msg32: the 32-byte message hash to be signed (cannot be NULL)
    104+ *             seckey32: the 32-byte secret key used for signing (cannot be NULL)
    105+ *    rand_commitment32: the 32-byte randomness commitment from the host (cannot be NULL)
    106+ */
    107+SECP256K1_API int secp256k1_schnorrsig_anti_nonce_sidechan_client_commit(
    


    benma commented at 11:25 am on June 11, 2019:
    To keep the api / interface smaller, the client could also call the sign function and get the commitment from the signature. Would there be any security downside in that (except for code readability?).

    jonasnick commented at 8:51 pm on June 11, 2019:
    That doesn’t seem to work if I understand you correctly. The client needs the hosts randomness to produce the signature which it doesn’t get until it sends the commitment.

    benma commented at 9:15 pm on June 11, 2019:
    I meant a first of two calls to the signing function, with the first one being a plain call with no host randomness, just to extract the client commitment (R = k*G like secp256k1_schnorrsig_anti_nonce_sidechan_client_commit computes, but, R can also be reconstructed from the sig).

    jonasnick commented at 9:26 pm on June 11, 2019:
    If you call sign twice your wasting a lot of time producing a signature that’s unnecessary?

    benma commented at 9:36 pm on June 11, 2019:
    :+1: I see.
  7. benma cross-referenced this on Jun 11, 2019 from issue ecdsa sign-to-contract module, with anti nonce covert chan util functions by benma
  8. in src/modules/schnorrsig/main_impl.h:87 in ae5fb7f8f1 outdated
    82+
    83+    if (!secp256k1_nonce_function_bipschnorr(nonce32, msg32, seckey32, NULL, rand_commitment32, 0)) {
    84+        return 0;
    85+    }
    86+
    87+    secp256k1_scalar_set_b32(&k, nonce32, NULL);
    


    benma commented at 10:41 am on June 16, 2019:
    Is there an overflow check missing here?

    real-or-random commented at 4:30 pm on June 16, 2019:
    No, the BIP draft intentionally does not check for overflow here. (It happens with negligible probability.)

    benma commented at 4:35 pm on June 16, 2019:
    :+1:
  9. jonasnick cross-referenced this on Jul 3, 2019 from issue Add anti nonce-sidechannel protocol to schnorrsigs by jonasnick
  10. jonasnick renamed this:
    Add anti nonce-sidechannel protocol to schnorrsigs [alternative]
    Add anti nonce-sidechannel protocol to schnorrsigs [̶a̶l̶t̶e̶r̶n̶a̶t̶i̶v̶e̶]̶
    on Jul 3, 2019
  11. add chacha20 function 2f40e1ec2e
  12. Add schnorrsig module which implements BIP-schnorr [0] compatible signing, verification and batch verification.
    [0] https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
    82645729cc
  13. Add ec_commitments which are essentially the pay-to-contract-style tweaks of public keys.
    The functionality is not exposed.
    0b4bef4527
  14. Add and expose sign-to-contract opening with parse and serialize functions 854c1c495f
  15. Allow creating and verifying Schnorr sign-to-contract commitments 9037bcf5e8
  16. Add anti nonce sidechannel protocol for schnorrsigs f8f9337a49
  17. jonasnick commented at 10:40 pm on July 4, 2019: contributor
    This thing needs a better name. Covert channel is a much better term for this than side channel. If no one comes up with something better I’ll go on with anti_covert_channel.
  18. f add rationale to protocol doc ed4add7ec2
  19. jonasnick force-pushed on Jul 5, 2019
  20. jonasnick commented at 8:48 pm on July 5, 2019: contributor
    Rebased
  21. in src/modules/schnorrsig/main_impl.h:83 in ed4add7ec2 outdated
    78+    ARG_CHECK(client_commit != NULL);
    79+    ARG_CHECK(msg32 != NULL);
    80+    ARG_CHECK(seckey32 != NULL);
    81+    ARG_CHECK(rand_commitment32 != NULL);
    82+
    83+    if (!secp256k1_nonce_function_bipschnorr(nonce32, msg32, seckey32, NULL, rand_commitment32, 0)) {
    


    benma commented at 3:57 pm on July 18, 2019:

    ~since secp256k1_schnorrsig_sign accepts ndata and s2c_data32 and combines them as input to the nonce function, would it make sense that this client_commit function also gets an ndata param which is mixed in in the same way?~

    pls disregard ;) of course this is impossible here, as only the caller can do this with the preimage :see_no_evil:

  22. f simplify setting a gej bdad1402f1
  23. in src/secp256k1.c:784 in ed4add7ec2 outdated
    779+    }
    780+
    781+    /* Return commitment == commitment_tmp */
    782+    secp256k1_gej_set_infinity(&pj);
    783+    secp256k1_pubkey_load(ctx, &p, &commitment_tmp);
    784+    secp256k1_gej_add_ge_var(&pj, &pj, &p, NULL);
    


    elichai commented at 3:15 am on July 28, 2019:
    You can use secp256k1_gej_set_ge() instead of setting to infinity and adding
  24. landanhu cross-referenced this on Dec 29, 2019 from issue Problem: rust-secp256k1 fork diverged from upstream by landanhu
  25. jonasnick cross-referenced this on Nov 2, 2020 from issue schnorrsig API overhaul by jonasnick
  26. real-or-random referenced this in commit 0440945fb5 on Jul 3, 2021
  27. real-or-random cross-referenced this on Mar 24, 2022 from issue antiklepto / anti-exfil protocol for Schnorr sigs by benma
  28. jonasnick commented at 2:08 pm on March 24, 2022: contributor
    Closing this PR since it’s based on a closed sign-to-contract PR. Another attempt at adding an anti-nonce-sidechannel should have a close look at the same protocol for ECDSA in secp256k1-zkp which was inspired by this PR (https://github.com/ElementsProject/secp256k1-zkp/blob/master/include/secp256k1_ecdsa_s2c.h).
  29. jonasnick closed this on Mar 24, 2022


github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin-core/secp256k1. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-11-23 03:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me