BIP-360: QuBit - Pay to Quantum Resistant Hash

[cryptoquick]

This spent several months gathering feedback from the mailing list and from other advisors. This is hopefully polished enough to submit upstream.

Let me know if you have any questions or feedback, and of course feel free to submit suggestions.

Thank you for your time.

[jonatack]

Interesting (the question of resistance to quantum computing may have resurged lately with the publication of https://scottaaronson.blog/?p=8329, see also https://x.com/n1ckler/status/1839215426091249778).

[jonatack]

@cryptoquick Can you begin to write up the sections currently marked as TBD, along with a backwards compatibility section (to describe incompatibilities, severity, and suggest mitigations, where applicable/relevant)? We've begun to reserve a range of BIP numbers for this topic, pending continued progress here.

[jonatack]

@cryptoquick ping for an update here. Have you seen https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw / https://github.com/chucrut/bips/blob/master/bip-xxxx.md? It may be interesting to review each other and possibly collaborate.

[cryptoquick]

Have you read the mail list discussion at https://groups.google.com/g/bitcoindev/c/8O857bRSVV8? It might be good to weigh in there if you're inclined.

I did write a response in the mailing list many months ago, but it never showed up. Not sure what happened. I really don't want to repeat my analysis... It was a good amount of work that was lost.

[murchandamus]

And is it not in your send folder?

[cryptoquick]

And is it not in your send folder?

I composed it in the Google GUI ... Last I checked there wasn't a way to check back on it.

[murchandamus]

If you sent it from there, it should be in your "Sent" or "Drafts" folder, unless you deleted it.

[cryptoquick]

I don't see anything like that here...

[murchandamus]

Oh, I thought you meant from the GUI of a Gmail account.

[murchandamus]

I’m a bit confused that another review was requested from me. As I said in my prior review:

This is all that I have at this time from an editorial standpoint. It would be good if this proposal got more feedback and/or endorsements from domain experts in the next steps.

I don’t think this needs another review from me, but rather it needs more engagement and support from other domain experts. Personally, I’m pretty skeptical about the approach of introducing a multitude of different signature schemes at once.

[murchandamus]

Once someone just starts stealing ~5% of the supply, it seems that it would be too late?

[cryptoquick]

I don't think anything can be done about the vulnerability of Satoshi's coins without also introducing confiscatory changes. They do serve a useful purpose, however, in that they provide cover to the migration of smaller value transactions in the mempool.

I'm just thinking worst case scenario, where the process to upgrade Bitcoin's quantum security takes much longer than we all expect.

[mraksoll4]

To start, I think we need to create a "skeleton" for integrating signature algorithms, such as Falcon-512 - 1024, as it seems to be the most optimal candidate at the moment. Since Falcon-512 - 1024 but it does not support key derivation for private and public keys, we can introduce an additional field in the wallet.dat to store the keys specifically for post-quantum signature algorithms.

Naturally, the descriptor would also need to be designed to handle single keys, ensuring compatibility with Falcon . This "skeleton" would serve as a foundation for integrating Falcon and similar post-quantum algorithms into the system. It will allow us to expand functionality while maintaining separation from existing ECDSA or other elliptic-curve-based algorithms.

I'm already trying to implement something similar using the available API, with slight extensions such as key generation from a seed and deriving a public key from a private key to match the expected logic

[mraksoll4]

[cryptoquick]

@murchandamus

I’m a bit confused that another review was requested from me. As I said in my prior review:

This is all that I have at this time from an editorial standpoint. It would be good if this proposal got more feedback and/or endorsements from domain experts in the next steps.

I don’t think this needs another review from me, but rather it needs more engagement and support from other domain experts. Personally, I’m pretty skeptical about the approach of introducing a multitude of different signature schemes at once.

That makes sense. I'll try to solicit more feedback from SMEs. The only reason I re-requested review was because I was hoping to get an approval and merge, but I'm not sure how far off we are from that.

The reason four were proposed to be introduced was, not only does it make sense from a hybrid cryptography perspective (some may sign high-value transactions with multiple types for redundancy), it's also possible that this early on, there might be vulnerabilities in the PQC algorithms chosen. There is skepticism about algorithms that make more modern security assumptions. Some prefer hash-based algorithms like SPHINCS, which was a strong preference from people like Antoine Riard and Matthew Corallo. There are problems with SPHINCS, however, in that it's quite large, and also it doesn't support signature aggregation so far as I'm aware.

Do you think it might make sense to edit this to omit the specific signature algorithms? The only problem with that is, that makes it so I can't implement valid test vectors, and when I eventually go to implement BIP-360, it's unclear from the spec which algorithms to support.

My stance has evolved on this over time... In my opinion, we should wait as long as possible until PQC algos are better understood, verified, and implemented. That said, P2QRH, as it was introduced on the mailing list, is meant to just be a concrete starting point for these discussions, and it's essentially an imperfect compromise between multiple different competing interests.

Additionally, I'd like to have another conversation around how multisig should work. Currently specified is a merkle tree approach, but I'm considering instead going with an approach similar to P2SH as I outlined in one of my comments. I'm not sure if that should go into this PR or into a separate PR.

I also would like to work on an alternative BIP, one that's more conservative and informed by lessons learned from this BIP, for Pay to Taproot Hash (P2TRH, with SegWit v2 addresses), but I'm reticent to open multiple BIP PRs at once. I think it makes sense as a sort of stopgap for those who rely on signature aggregation such as FROST multisig, and it's a much less heavy a lift. It would be less controversial due to lack of PQC algo bikeshedding, and while it's imperfect because it doesn't make the mempool trustless to use, we can then point to P2QRH as the proposal to support if that's where community consensus is.

So, yes, there are a lot of considerations to be had here. I'm also likely going to need to deprecate SQIsign due to its terrible performance (100,000 times more computationally expensive to verify than ECDSA according to @EthanHeilman), and I might also want to include RACCOON because there's definitely demand for signature aggregation. Additionally, I've heard concerns about the constants chosen for FALCON in favor or NTRU Prime, but there are also people working on signature aggregation for FALCON which could improve the utility of the proposal.

One other possibility is that we make signature aggregation a requirement for any PQC algo included from this point forward so as to not have a significant reduction in functionality available with Taproot / Schnorr signatures. This requirement, which has been expressed to me by a number of users, would dramatically narrow down the number of valid signature algorithm candidates.

@mraksoll4

Since Falcon-512 - 1024 but it does not support key derivation for private and public keys

I believe this is actually an implementation detail. pqclean is unsuitable for bitcoin pqc because of its lack of BIP-32 support, but it might be useful as a basis. It just lacks an API to provide your own entropy, but that's not the fault of the signature algorithm, it's instead the fault of the implementation, which can be corrected in a more unified bitcoin pqc library designed in support of this BIP.

[mraksoll4]

most post-quantum algorithms that are not yet cracked are lattice structures (unless we want the signature size to be several megabytes) their mathematical basis does not allow for tweaks, as in eleptic curves. These are different mathematical structures, for example RSA, the problem with dilithium and falcon is that there is no analogous G, even potential components f and g are secrets

This is not native functions of of clean , i created self based at exist function ( you can see it via added memory cleanse .. native does not clear temp buffers )

#include <stddef.h>
#include <string.h>
#include <stdio.h>

#include "api.h"
#include "inner.h"
#include "memory_cleanse.h"

#define NONCELEN   40

#include "randombytes.h"
/* keypair from fixed seed*/
int
PQCLEAN_FALCON512_CLEAN_crypto_sign_keypair_from_fseed(
    uint8_t *pk, uint8_t *sk, const uint8_t *seed) {
    union {
        uint8_t b[FALCON_KEYGEN_TEMP_9];
        uint64_t dummy_u64;
        fpr dummy_fpr;
    } tmp;
    int8_t f[512], g[512], F[512];
    uint16_t h[512];
    inner_shake256_context rng;
    size_t u, v;

    /*
     * Checking the input seed parameter.
     * If the seed is NULL, return an error.
     */
    if (seed == NULL) {
        return -1;  // Error: seed is not provided.
    }

    /*
     * Initialize the SHAKE256 random number generator using the seed.
     * We now pass the seed directly to the generator.
     */

    /*
     * print seed for debug 
	 */
    print_hex_debug("Generated Seed Keypair from fseed 1", seed, 48);

    inner_shake256_init(&rng);
    inner_shake256_inject(&rng, seed, 48);

    /*
     * print seed for debug 
	 */
    print_hex_debug("Generated Seed Keypair from fseed 2", seed, 48);

    memory_cleanse((void*)seed, 48);
    inner_shake256_flip(&rng);
    PQCLEAN_FALCON512_CLEAN_keygen(&rng, f, g, F, NULL, h, 9, tmp.b);
    inner_shake256_ctx_release(&rng);

	memory_cleanse(&rng, sizeof(inner_shake256_context));

    /*
     * Encode private key.
     */
    sk[0] = 0x50 + 9;
    u = 1;
    v = PQCLEAN_FALCON512_CLEAN_trim_i8_encode(
            sk + u, PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES - u,
            f, 9, PQCLEAN_FALCON512_CLEAN_max_fg_bits[9]);
    if (v == 0) {
		memory_cleanse(f, sizeof(f));
        memory_cleanse(g, sizeof(g));
        memory_cleanse(F, sizeof(F));
        memory_cleanse(h, sizeof(h));
        memory_cleanse(tmp.b, sizeof(tmp.b));
        return -1;
    }
    u += v;
    v = PQCLEAN_FALCON512_CLEAN_trim_i8_encode(
            sk + u, PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES - u,
            g, 9, PQCLEAN_FALCON512_CLEAN_max_fg_bits[9]);
    if (v == 0) {
		memory_cleanse(f, sizeof(f));
        memory_cleanse(g, sizeof(g));
        memory_cleanse(F, sizeof(F));
        memory_cleanse(h, sizeof(h));
        memory_cleanse(tmp.b, sizeof(tmp.b));
        return -1;
    }
    u += v;
    v = PQCLEAN_FALCON512_CLEAN_trim_i8_encode(
            sk + u, PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES - u,
            F, 9, PQCLEAN_FALCON512_CLEAN_max_FG_bits[9]);
    if (v == 0) {
		memory_cleanse(f, sizeof(f));
        memory_cleanse(g, sizeof(g));
        memory_cleanse(F, sizeof(F));
        memory_cleanse(h, sizeof(h));
        memory_cleanse(tmp.b, sizeof(tmp.b));
        return -1;
    }
    u += v;
    if (u != PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES) {
		memory_cleanse(f, sizeof(f));
        memory_cleanse(g, sizeof(g));
        memory_cleanse(F, sizeof(F));
        memory_cleanse(h, sizeof(h));
        memory_cleanse(tmp.b, sizeof(tmp.b));
        return -1;
    }

    memory_cleanse(f, sizeof(f));
    memory_cleanse(g, sizeof(g));
    memory_cleanse(F, sizeof(F));

    /*
     * Encode public key.
     */
    pk[0] = 0x00 + 9;
    v = PQCLEAN_FALCON512_CLEAN_modq_encode(
            pk + 1, PQCLEAN_FALCON512_CLEAN_CRYPTO_PUBLICKEYBYTES - 1,
            h, 9);
    if (v != PQCLEAN_FALCON512_CLEAN_CRYPTO_PUBLICKEYBYTES - 1) {
        memory_cleanse(h, sizeof(h));
        memory_cleanse(tmp.b, sizeof(tmp.b));
        return -1;
    }

    memory_cleanse(h, sizeof(h));
    memory_cleanse(tmp.b, sizeof(tmp.b));

    return 0;
}

/*
 * This function reconstructs the public key from a given private key.
 * It decodes the private key components (f and g) from the secret key
 * and uses them to regenerate the corresponding public key (h).
 * The generated public key is then encoded into the provided pk array.
 * 
 * public (pk):  The output buffer where the public key will be stored (must be at least PQCLEAN_FALCON512_CLEAN_CRYPTO_PUBLICKEYBYTES in size).
 * private (sk):  The input secret key (private key) in byte array format (must be PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES in size).
 * Return value: 0 on success, -1 on error.
 */
int
PQCLEAN_FALCON512_CLEAN_crypto_sign_pubkey_from_privkey(
    uint8_t *pk, const uint8_t *sk) {
    union {
        uint8_t b[FALCON_KEYGEN_TEMP_9];
        uint64_t dummy_u64;
        fpr dummy_fpr;
    } tmp;
    int8_t f[512], g[512];
    uint16_t h[512];
    size_t u, v;

    /*
     * Decode the private key.
     */
    if (sk[0] != 0x50 + 9) {
        return -1;
    }
    u = 1;
    v = PQCLEAN_FALCON512_CLEAN_trim_i8_decode(
            f, 9, PQCLEAN_FALCON512_CLEAN_max_fg_bits[9],
            sk + u, PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES - u);
    if (v == 0) {
        return -1;
    }
    u += v;
    v = PQCLEAN_FALCON512_CLEAN_trim_i8_decode(
            g, 9, PQCLEAN_FALCON512_CLEAN_max_fg_bits[9],
            sk + u, PQCLEAN_FALCON512_CLEAN_CRYPTO_SECRETKEYBYTES - u);
    if (v == 0) {
        return -1;
    }

    /*
     * Reconstruct the public key using f and g by calling the compute_public function.
     */
    if (!PQCLEAN_FALCON512_CLEAN_compute_public(h, f, g, 9, tmp.b)) {
		memory_cleanse(f, sizeof(f));
        memory_cleanse(g, sizeof(g));
        memory_cleanse(tmp.b, sizeof(tmp.b));
	    memory_cleanse(h, sizeof(h));
        return -1;
    }

    /*
     * Encode public key.
     */
    pk[0] = 0x00 + 9;
    v = PQCLEAN_FALCON512_CLEAN_modq_encode(
            pk + 1, PQCLEAN_FALCON512_CLEAN_CRYPTO_PUBLICKEYBYTES - 1,
            h, 9);
    if (v != PQCLEAN_FALCON512_CLEAN_CRYPTO_PUBLICKEYBYTES - 1) {
		memory_cleanse(f, sizeof(f));
        memory_cleanse(g, sizeof(g));
        memory_cleanse(tmp.b, sizeof(tmp.b));
	    memory_cleanse(h, sizeof(h));
        return -1;
    }

    // Securely clear sensitive buffers
    memory_cleanse(f, sizeof(f));
    memory_cleanse(g, sizeof(g));
    memory_cleanse(tmp.b, sizeof(tmp.b));
	memory_cleanse(h, sizeof(h));
    return 0;
}

[cryptoquick]

@mraksoll4 I'm not sure I understand the point you're trying to make.

[mraksoll4]

@mraksoll4 I'm not sure I understand the point you're trying to make.

I meant that the capabilities of elliptic curves cannot and should not be directly projected onto post-quantum algorithms. A different approach is needed. BIP32 and the ability to derive public keys from public keys is a unique feature of elliptic curves. Even isogeny-based cryptography, which no longer holds against certain attacks, doesn’t support such functionality. The key difference lies in the underlying mathematical structures.

But we can still build a key tree for private keys using abstractions on top of the seed.

The problem lies specifically with public keys.

[cryptoquick]

No, it's not. BIP-32 doesn't rely on key tweaking. It just produces entropy (private keys) in a deterministic way.

I think you're confused because you're only working from one implementation. For example, this implementation of FALCON would support BIP-32:

https://docs.rs/falcon-rust/latest/falcon_rust/falcon1024/fn.keygen.html#:~:text=pub%20fn%20keygen(-,seed%3A%20%5Bu8%3B%2032%5D,-)%20-%3E%20(SecretKey%2C

[mraksoll4]

No, it's not. BIP-32 doesn't rely on key tweaking. It just produces entropy (private keys) in a deterministic way.

I think you're confused because you're only working from one implementation. For example, this implementation of FALCON would support BIP-32:

https://docs.rs/falcon-rust/latest/falcon_rust/falcon1024/fn.keygen.html#:~:text=pub%20fn%20keygen(-,seed%3A%20%5Bu8%3B%2032%5D,-)%20-%3E%20(SecretKey%2C

As far as I understand, this also works directly with key pairs. Earlier, I mentioned that we can manipulate the seed to generate child key pairs. The issue lies in the fact that we cannot derive public keys from other public key

shake256(seed + some data + some data  + index)=seed (48 bytes) --> int
PQCLEAN_FALCON512_CLEAN_crypto_sign_keypair_from_fseed(
    uint8_t *pk, uint8_t *sk, const uint8_t *seed)

[cryptoquick]

I see your point now. For example, using an xpub alone to generate more keys for, say, a watch-only wallet, might not be possible with FALCON.

I'll need to think about that.

[mraksoll4]

I see your point now. For example, using an xpub alone to generate more keys for, say, a watch-only wallet, might not be possible with FALCON.

I'll need to think about that.

Yes, but nothing prevents us from using single keys for watch-only wallets. For example, if a user tries to export an xpub for a post-quantum algorithm, we could display a message like:

"Post-quantum algorithm [name] does not support xpub keys. You need to explicitly export the key using a command to retrieve it from the descriptor or key cache."

Alternatively, we could provide a list of existing keys in a serialized format. For instance:

Generate 2000 keys on-demand when the user requests a key list.
Offer an option to save the corresponding private keys to wallet.dat or not, securely wiping the buffer after generation.
This approach would give flexibility while acknowledging the limitations of post-quantum algorithms and maintaining compatibility with watch-only and partially signed setups.

[mraksoll4]

There is another option where multiple addresses can be linked to a single key pair through key packing and unpacking using additional parameters, with the index influencing the final address. However, this approach has limited practical value. While it makes it impossible to determine any connection between the addresses before a transaction is conducted, it resembles the concept of non-hardened derivation.

[murchandamus]

Do you think it might make sense to edit this to omit the specific signature algorithms? The only problem with that is, that makes it so I can't implement valid test vectors, and when I eventually go to implement BIP-360, it's unclear from the spec which algorithms to support.

Perhaps it would make sense to describe the general output type mechanism, and then to have a separate BIP per signature algorithm to plug in?

[cryptoquick]

That's an interesting idea. Do you think it would make sense to showcase the new transaction structure and commitment scheme, which by default still requires Schnorr signatures, just without the additional signature algorithms? Then the test vectors for this BIP would only be for secp256k1, and then we work out the requirements for specific PQC algorithms into a separate BIP...?

This would have the advantage that it would simplify large sections of the BIP dedicated to signature algorithm selection and we can have those discussions separately.

The only problem with that is, it really takes the fangs out of BIP-360 as a quantum hardening BIP. It does make the improvement that it secures Taproot against long exposure attacks, so we don't need a BIP, like say, Pay to Taproot Hash. Do you think it might make sense to implement just one algorithm in this also, maybe FALCON? Maybe we make the stipulation that FALCON is provisional and that a more authoritative set of signature algorithms will be provided in a separate BIP?

One argument for having a separate P2TRH BIP is that it's a much simpler implementation, since it doesn't require a change to transaction structure and commitment scheme. I've already worked on a draft of that, but it's not polished and I'm not sure if I want to announce it since we might go with an abbreviated BIP-360.

[mraksoll4]

I believe the solution would be to use multithreading for signing and verification processes to mitigate the slowness of post-quantum algorithms. In my opinion, the most promising algorithms so far are lattice-based ones. Ideally, they should be used in combination with hash-based approaches, such as sponge constructions like Keccak (e.g., SHA-3, SHAKE256).
SHAKE256 will be convenient for replacing HMAC when working with seeds for building derivations. Additionally, I believe the approach should be independent of ECDSA to avoid even the slightest potential vulnerability. As for the address, it should either be purely post-quantum-based or a hybrid of public keys.

In the case of hybrid public keys, for each ECDSA-derived child address generation, there should be an automatic request for parallel derivation of a corresponding public key - using a post-quantum algorithm (if the attestation field method is used).

I’m talking about real-world scenarios that are already available now. So, while there might be something new in the future, it’s likely that the evolution of post-quantum addresses will follow a similar path as P2SH -> Taproot.

Regarding old addresses, there could be a separate rule with flexible timeframes where the attestation field would be required
for subsequent transactions, even for existing ones, in case of a critical situation—such as the emergence of a real threat of address compromise. This would act as a kind of "hotfix" that could be activated if necessary to minimize damage to the network, provided it is approved by a majority (enforcing a "ONLYPOSTQUANTUMCANPAY" mechanism).

[cryptoquick]

@mraksoll4

multithreading

Some things are not easy to multithread, such as WASM implementations, like that used by BDK web wallets, so we can't rely on that to address those concerns. SQIsign's performance was particularly terrible, and so it was removed.

Ideally, they should be used in combination with hash-based approaches, such as sponge constructions like Keccak (e.g., SHA-3, SHAKE256)

Given that the threat Grover's poses is more remote than the threat posed by Shor's, I'd really rather restrict this BIP to only changes to signature algorithms and not to any hash functions used by Bitcoin.

I believe the approach should be independent of ECDSA to avoid even the slightest potential vulnerability.

Absolutely not. It's fine to support secp256k1 even in a post-quantum regime so long as it's combined with PQC.

[mraksoll4]

@mraksoll4

multithreading

Some things are not easy to multithread, such as WASM implementations, like that used by BDK web wallets, so we can't rely on that to address those concerns. SQIsign's performance was particularly terrible, and so it was removed.

Ideally, they should be used in combination with hash-based approaches, such as sponge constructions like Keccak (e.g., SHA-3, SHAKE256)

Given that the threat Grover's poses is more remote than the threat posed by Shor's, I'd really rather restrict this BIP to only changes to signature algorithms and not to any hash functions used by Bitcoin.

I believe the approach should be independent of ECDSA to avoid even the slightest potential vulnerability.

Absolutely not. It's fine to support secp256k1 even in a post-quantum regime so long as it's combined with PQC.

It’s more convenient to store a separate descriptor with a separate seed for post quantum addresses and separation of generation; in addition to security, this is convenient if we later want to add more signature algorithms

in case of combination it is also important what do we want to use for quantum algorithm as a seed? If keys are what they are and convert them to 48 bytes of seed, then what is the point? It will be enough for an attacker to crack ecdsa, because they are connected, if they have their keygen with their seed and are connected almost exclusively by paths, that is, an additional level of protection. Sha3 algorithms are less susceptible to Sha256 problems, shake256 is simply convenient as a converter for obtaining good cryptographic bytes from combined paths with a base seed.

qrh key descritpor(ECDSA + Master seed with base path as simple example)
       │                                           │  
       │                                           │  
Master Key(ECDSA)                           Master Seed (PQ) 
       │                                           │
       │                                           │
       │                                           │
       │                                           │                                           
       │                                           │               
       │                                           │
       ▼                                           │                                   
   xpub (ECDSA)                                    │                       
       │                                           │
       │                                           │
Drive Path (ECDSA)                      shake256(Derived path + seed (PQ))
       │                                           │
       │                                           │
┌──────▼─────────┐                         ┌───────▼───────┐
│                │                         │               │
│ Pub Key (ECDSA)│                         │ Pub Key (PQ)  │
│                │                         │               │
│                │                         │               │
└───────┬────────┘                         └───────┬───────┘
        │                                          │
        │                                          │
        ├──────────────────────────────────────────┤
        │                                          │
        ▼                                          ▼
┌───────────────────────────────────────────────────────────┐
│                     Merkle Tree Root                      │
│ (Combining Pub Keys from ECDSA and PQ for Merkle Root)    │
└───────────────────────────────────────────────────────────┘

this is a simplified scheme without scripts, in a real scheme we also include scripts

in essence, 2 signature algorithms converge for us through the use of 1 path in relation to the child keys of ecdsa, simultaneously requesting for the attestation field a public key for PQ, or a private key when we need a signature

it is also possible to do caching, but due to the fact that the keys are huge, this should be optional for anyone who needs it, for everyday use we store only the master and the paths associated with it