---
# System prepended metadata

title: HHD blogpost

---

# Hybrid Hierarchical Deterministic Wallets

# Introduction

<div style="border-left:4px solid #4E46DC;
            background:#F8FAFF;
            padding:14px 18px;
            border-radius:10px;
            margin:12px 0;
            color:#1E1E1E;
            line-height:1.6;">
    <strong style="color:#2D2B8F;">TL;DR</strong>
    
In this blogpost we present a hybrid design for a hierarchical deterministic wallet derived from a single seed phrase, that supports both post-quantum and non-post-quantum (a.k.a. classical) signatures. 
    
We open-sourced a Rust implementation, which you can check in our [Bedrock repo](https://github.com/tectonic-labs/bedrock/blob/main/src/hhd.rs), and its specification in the [hhd-spec repo](https://github.com/tectonic-labs/hhd-spec).
 
</div>

**Author:** Manuel B. Santos <manuel@tectonic.xyz>

## Motivation

Managing secret keys has always been one of the biggest pain points in crypto. Thankfully, over time, some BIP standards made this task easier and safer.

[BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) introduced hierarchical deterministic (HD for short) wallets, providing a way to derive an entire tree of keys from a single master key. [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) then standardized derivation paths so wallets could work across different providers, and [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) added mnemonic seed phrases that made backups simple: you just need to remember a few words to recover everything. These improvements definitely made wallets more user-friendly and interoperable.

[BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) also introduced two types of derivation: hardened and non-hardened. The former is usually used when we need total isolation between keys, such that leaking a child key does not compromise higher levels. The latter is crucial for generating public keys without private ones that is perfect for watch-only wallets or payment processors. Indeed, this approach powers real-world setups like [Blue Wallet](https://bluewallet.io/watch-only/) or [Blockstream Wallet](https://help.blockstream.com/hc/en-us/articles/19340800530713-Set-up-watch-only-wallet), which can monitor balances without knowing the private keys; and [BitPay Wallet](https://github.com/bitpay/bitcore/tree/master/packages/bitcore-wallet-service) or [BTCPay](https://docs.btcpayserver.org/Multisig/#step-2-create-the-multi-signature-wallet), which can generate addresses securely from a master extended public key. 

All these standards were initially designed with ECDSA in mind and [SLIP-10](https://github.com/satoshilabs/slips/blob/master/slip-0010.md) extended the idea to other algorithms like EdDSA. But with quantum computing and the **Q-Day** [1] **on the horizon**, both ECDSA and EdDSA face a ticking clock. The very signatures securing our transactions and wallets will one day be compromised by quantum computers, exposing funds if we don’t adapt in time. So the question becomes:

> ***How do we bring the same deterministic, user-friendly wallet model provided by BIP-32/39/44 to post-quantum signatures?***

Instead of jumping straight into less battle-tested cryptography, a more prudent path is a **hybrid HD wallet**: one that **deterministically derives both** classical (e.g., ECDSA) and post-quantum (e.g., Falcon) keys **from the same seed phrase**. This hybrid approach creates a security bridge between the present day (where the long battle-tested ECDSA sig is sure) and the Q-Day to come. In this blogpost, we present the design a hybrid HD wallet but first, let us see what others have done on this topic.

## What others have done

The community has already started paying attention to the challenge of building **HD wallets** that work with **post-quantum (PQ) signatures**. A few key questions have started to pop up:
1. Can we build hierarchical derivation for a post-quantum signature scheme?
2. Can we generate different post-quantum signatures from the same seed phrase?

The **first question** was explored in the [QIP-02](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0002.md) proposal, which adapts the hardened derivation logic from [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki). It uses deterministic seeds derived from the master key, which are then locally fed into a deterministic PQ key generation algorithm. The **second question** was tackled in a [recent blog post](https://blog.projecteleven.com/posts/generating-post-quantum-keypairs-from-a-single-24word-seed-phrase) by Project Eleven suggesting the use of [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) to generate independent entropy, that is then used to derive keypairs for different PQ signatures. [PQBIP39](https://github.com/ZKNoxHQ/PQBIP39) from ZKNoxHQ also proposed a solution to generate different 256-bit seeds for multiple signature schemes from a single [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) mnemonic. However, PQBIP39 approach uses the `coin_type` to branch out seeds according to the different signature schemes.

This naturally leads to a follow-up third question (the main focus of this blog post):

> Can we design a hierarchical derivation mechanism that supports both classical and post-quantum signature schemes from the same seed phrase?

This hybrid idea would let users manage both ECDSA and PQ keys within a single deterministic wallet, combining present-day compatibility with future-proof security.

On an orthogonal direction, while [QIP-02](https://github.com/Quantus-Network/improvement-proposals/blob/main/qip-0002.md) handles hardened derivations well (since they can apply to almost any scheme), non-hardened derivations are more complex and depend on the ability to derive public keys without private information. This derivation mechanism is very protocol-dependent and requires tailored approaches to each PQ signing scheme. We list below a non-exhaustive list of papers that address the non-hardened derivation for different schemes (we don't dive into those as this is out of scope for this blogpost). 

| Reference   |       Signature scheme       | 
| ----------- | ---------------------------- | 
| **[[HLZ24]](https://cybersecurity.springeropen.com/articles/10.1186/s42400-024-00216-w#Sec16)** | Hash-and-sign GPV framework (Falcon-like scheme) | 
| **[[SR25]](https://cic.iacr.org/p/2/3/3/pdf)**  | Adapted Dilithium            | 
| **[[ADE+20]](https://eprint.iacr.org/2020/1149)**    | qTesla                 | 

## A note on Falcon

We use Falcon as our main example for PQ signatures, mainly because of its ongoing adoption efforts, such as [ethfalcon by ZKNoxHQ](https://github.com/ZKNoxHQ/ETHFALCON), which explores Falcon integration within the Ethereum ecosystem. Besides that, it offers the [best tradeoff](https://blog.cloudflare.com/pq-2025/#be-careful-with-fn-dsa) between signature size and public-key size and relatively efficient signing and verification. Recent work on key generation deterministic implementations, like Thomas Pornin’s [ntrugen](https://github.com/pornin/ntrugen/tree/main) library, has also shown that [Falcon can generate reproducible key pairs from a fixed seed without weakening security](https://groups.google.com/u/1/a/list.nist.gov/g/pqc-forum/c/bjVkrZmI9VM/m/XZdyHwroAAAJ) [2]. These features make it an attractive candidate for deterministic and hierarchical wallet designs.

However, Falcon also comes with **some open questions** [3]. The process of deriving a Falcon key pair from a seed is still evolving: NIST’s upcoming FN-DSA standard (the formal Falcon specification) [is expected to change the key generation procedure](https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/CsWPP35LJWw/m/NPAuzmHaAAAJ) [4], and its first draft has not yet been released. Even Falcon’s co-author [Thomas Pornin has warned](https://github.com/pornin/rust-fn-dsa/pull/5) that current deterministic key generation approaches may not remain backward-compatible once the draft appears. Moreover, NIST has indicated that reproducible key generation may not be guaranteed in the official standard, partly to allow flexibility for different hardware implementations.

In practice, this means that any deterministic or seed-based Falcon wallet needs to lock a specific implementation to ensure reproducibility, at the cost of deviating from future NIST updates. For those reasons, while Falcon is our reference implementation, the ideas explored in this blog post can just as easily extend to other PQ schemes like [ML-DSA (Dilithium)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) where deterministic key generation is already standardized in its [FIPS](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf) document through `KeyGen_internal` function (Algorithm 6).



# Hybrid HD wallet

Let's start exploring the hybrid hierarchical deterministic derivation proposed in this blog post. The aim is to achieve the following features:

> Develop a derivation process that is capable of deterministically generate keypair tree hierarchies for quantum- and non quantum-resistant signatures, while following battle-tested standards that users have familiarity with.

This allows a single BIP-39 mnemonic to deterministically derive key hierarchies for multiple signatures without requiring independent mnemonic seeds. We adopt ECDSA under `secp256k1` curve and [Falcon-512](https://falcon-sign.info/) as the two signature schemes, but what we present can be generalized to any number of schemes. Also, we hybrid HD procedure uses the following standards: [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki), [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki), [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) and extends [SLIP-10](https://slips.readthedocs.io/en/latest/slip-0010/) to PQ signatures. 

## Overview

In summary, the process to generate a hierarchy of keypairs for both ECDSA and Falcon signatures is as follows. The [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) standard is used to generate a master seed from a mnemonic. Then, the [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) standard is used to generate two child seeds to feed the hierarchical structure of ECDSA and Falcon signatures. The [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) standard internally uses the [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) standard with hardened child key derivation (CKD) to produce those child seeds with the path given by `m/83696968'/83286642'/{index}'`. Then, the ECDSA branch (`index=1`) can follow the standard [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) mechanism (hardened or non-hardened) for its hierarchical derivation and the Falcon branch (`index=2`) follows a [SLIP-10](https://slips.readthedocs.io/en/latest/slip-0010/) approach. 

In other words, we have the following flow:

1. [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) for `Master Seed` generation.
2. [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) to generate two child seeds using the path `m/83696968'/83286642'/{index}'`:
    - ECDSA branch (`index=1`): follows the [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)/[BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) standards with hardened/non-hardened key derivation.
    - Falcon branch (`index=2`): follows the [SLIP-10](https://slips.readthedocs.io/en/latest/slip-0010/) standard adapted to Falcon signatures.

The diagram below describes the hybrid HD approach in a schematic way.

![Full](https://hackmd.io/_uploads/rye43XfDWl.png)


Let's go over each step and comment on the security of our proposal. You can also follow along with its Rust implementation [here](https://github.com/tectonic-labs/bedrock/blob/main/src/hhd.rs).



## Master seed generation

In order to provide a standard UX for wallet creation, we focus ourselves on the [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) standard to generate a mnemonic wordlist of 24 words, from which a master seed can be derived. We use the exact same master seed derivation mechanism as presented in [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki). The following diagram reviews the steps to generate a master seed:



![BIP-39](https://hackmd.io/_uploads/HyA_XsCLWl.png)



For a more visual description of all steps involved we refer to this [material](https://learnmeabitcoin.com/technical/keys/hd-wallets/mnemonic-seed/#generate-entropy).

### Security notes

A conservative choice of parameters allows only mnemonic with at least 24 words. The reason being twofold:
1. Falcon key generation requires a seed with 256 bits of entropy;
2. Grover's algorithm degrades hash-based strength by half.

Let's unpack that below.

#### NIST compliance

NIST signature approves seeded ML-DSA key generation using an approved random bit generator (RBG) [5]. Although Falcon first draft has not been proposed yet, a similar guideline is expected to apply in case a deterministic key generation is specified. Similar to ML-DSA [5] and as per [6] and [7], the seed for Falcon key generation procedure requires a minimum of 256 bits security. 

Therefore, one has to guarantee that the master seed generated in this process can indeed be considered equivalent to a RBG with 256 bits of entropy. The following (very informal) argument supports how that can be achieved. Given RBG strength of 256 bits, mnemonic generation uses SHA256 which preserves the 256 bit security level. Moreover, the PBKDF2 output bit strength is at most the bit security entropy of the password or the PRF strength. Since the entropy of the mnemonic passed as password is 256 bits and SHA512 is used as a PRF, we can conclude that PBKDF2 strength is at most 256 bits.

#### Grover degradation

From a quantum-threat perspective, all operations involved in [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) are quantum-resistant. It is important to note though that they come with some parameter degradation due to [Grover's algorithm](https://arxiv.org/pdf/quant-ph/9605043) and its impact on hash-based cryptography. As a general rule of thumb, if we want to keep the minimum 128-bit security, we need at least 256-bit security in the classical world [8].


## Child seeds generation

After having the master seed, we need to derive two child seeds corresponding to both signature types. For that, we follow the approach of [this proposal](https://blog.projecteleven.com/posts/generating-post-quantum-keypairs-from-a-single-24word-seed-phrase) and use the [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) standard.

Let's dive in a bit more to see how it works.

As described in its specification, [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) uses a fully hardened derivation path (by applying a CKD, a chain of functions we will see in the next section) from the [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) master root key. This master root key, according to [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), is computed using HMAC with the string "Bitcoin seed" as key and the master seed as the message. At the end of the chain, [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) additionally applies an entropy derivation function (HMAC-SHA512) to generate the final child seed. The process is summarized below is a schematic way.
 
![BIP-85](https://hackmd.io/_uploads/SkcUhXfPbx.png)



Let's first recall the hardened derivation function used in [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) and then specify the derivation path convention used in our hybrid HD derivation approach for both ECDSA (`ecdsa_path`) and Falcon (`falcon_path`) signatures.

### Child derivation procedure

Let's see how the child key derivation function (CKD) we mentioned above and defined in the original [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) standard works. This will be a bit mathy but hopefully it is clear enough. 

Let's set some notation for clarity. We denote the raw parent key as $k_{par}$, the raw parent chaincode as $c_{par}$ and index as $i$. With that in mind we can define the internal hardened function $\mathsf{CKD_{int}}((k_{par}, c_{par}), i) → (k_i, c_i)$ as follows:

1. Check whether $i ≥ 2^{31}$ (whether the child is a hardened key), output error otherwise.
2. Let $I = \mathsf{HMAC-SHA512}(\mathsf{key} = c_{par},\, \mathsf{data} = \texttt{0x00} || k_{par} || i)$. 
3. Split $I$ into two 32-byte sequences, $I_L$ and $I_R$.
4. Output: $(k_i, c_i) = (I_L, I_R)$

In order to support a hierarchic keychain, we define the child key derivation procedure (CKD) on some path L (a list of ordered indexes) as the recursive call of $\mathsf{CKD_{int}}$ function on the elements of L. Let us see an example below.

<div style="border-left:4px solid #4E46DC;
            background:#F8FAFF;
            padding:14px 18px;
            border-radius:10px;
            margin:12px 0;
            color:#1E1E1E;
            line-height:1.6;">
    <strong style="color:#2D2B8F;">Example 1 — Path derivation</strong>
    
Imagine the path is given by $L = [83696968\text{'}, 83286642\text{'}, 2\text{'}]$, the function $\mathsf{CKD}((k_{par}, c_{par}), L) → k$ is computed as follows:

$$\mathsf{CKD_{int}}(\mathsf{CKD_{int}}(\mathsf{CKD_{int}}((k_{par}, c_{par}), 83696968\text{'}), 83286642\text{'}), 2\text{'}) = k,$$

where $k$ is a 512 bit key. As we will see next, this is in fact the path used to generate the Falcon seed.
    
If you are wondering why we have a prime (') after the numbers, it denotes the **hardened path** and in practice it adds $2^{31}$ to the number.
 
</div>


#### Security notes

In order to use the above process in the generation of the child seeds we need to guarantee two security properties:

1. The CDK process preserves the original entropy (256 bits);
2. Key separation: this guarantees that the newly generated keys are independent from each other, meaning that compromise of one key does not degrade the security of the other keys.

Let's expand the above points below and (very) informally address them.

##### Key generation process security

The above CDK chained process follows the spirit of HMAC-based Key Derivation Function (HKDF-SHA512) specified in the original [[K10]](https://eprint.iacr.org/2010/264.pdf) paper and in [RFC5869](https://datatracker.ietf.org/doc/html/rfc5869). The HKDF scheme follows an **extract-and-expand** approach based on some initial secret key material (SKM). The extraction phase uses SKM to generate a pseudo random key (PRK) that is then passed to an expansion function to generate new key material. 

We can think of CDK procedure lacking an extraction phase and using the master seed directly as the PRK in the expansion phase. Indeed, as noted in ([[K10]](https://eprint.iacr.org/2010/264.pdf), Section D, Point 1), since the master seed is already a random string of the length of the HMAC key, one can simply use the master seed as the key to HMAC and jump over the extraction phase. Moreover, the HKDF security property allows the extraction phase to compute HMAC only once during extraction phase. This process is indeed extended in CKD due to the hierarchical nature of the derivation path as CKD computes not only one HMAC but several chained HMACs.

With the above argument we can be relatively convinced that CDK security relies on the security of HKDF analysed in [[K10]](https://eprint.iacr.org/2010/264.pdf) paper and in [RFC5869](https://datatracker.ietf.org/doc/html/rfc5869) [9].

##### Key separation

For the derivation of the child seeds it is **important to guarantee that any material leaked in one branch does not affect the security of the other branch**. This key separation principle is guaranteed by the key derivation function (KDF) mechanisms defined in [NIST SP 800-108](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1-upd1.pdf). Since HKDF is a valid KDF specified in the document, and CDK mechanism breaks down to HKDF (check [previous subsection argument](#key-generation-process-security)), we can be convinced that the CDK process achieves the key separation principle.


### Derivation path convention

Ok. After learning how the chained CDK procedure works, let us now see the structure of the derivation path for our design. 

In [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) a private key can be derived from the [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) master root key using a **fully hardened** derivation path. The derivation path follows the convention:

`
m/83696968'/{app_no}'/{index}'
`, 
where `{app_no}` is the path for the application, `{index}` is the index, and the prime `'` is used to refer to a hardened derivation (i.e., as we saw in the Example 1 above, in practice it adds $2^{31}$ to the corresponding number).

The hybrid HD derivation app number is `app_no = 83286642`, standing for Tectonic written in a T9 keyboard. `ecdsa-secp256k1` signature is given `index=1` and `falcon-512` signature is given `index=2`.

We recall that the hardened derivation path does not use an ECC specific construction as the $k_{par}$ is passed as raw bytes to the HMAC in the `Data` field. Therefore, this process can be applied to a generic derivation mechanism.

### Child master seed derivation

Finally! Now, we can finish with the [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) standard to get the final seed! 

The output of CKD denoted by `k` is passed to `HMAC-SHA512("bip-entropy-from-k", k)` to extract new entropy. The result (`child_master_seed`) is our child master seed for the derivation of either ECDSA or Falcon keypairs. 

## HD keychain

The **entropy derived** from [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki) procedure described above for the **two branches** can then be used as the **seed** for the generation of **two keychains**.

The **ECDSA branch** can follow the traditional [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) hierarchical derivation with either hardened or non-hardened derivation paths. The **Falcon branch** (or any other PQ signature) follows a hardened derivation path proposed in [SLIP-10](https://slips.readthedocs.io/en/latest/slip-0010/) for universal key derivation. We adopt a similar approach to ed25519 signature with a tailored domain separator string `"Falcon-512 seed"`, used in the master key generation step. 

As we discussed in the [motivation section](#motivation), the Falcon original proposal does not provide an out-of-the-box rerandomization key technique, which is the feature required for a non-hardened derivation path. 

Below we show a schematic diagram with the hierarchical derivation used by the two branches.


![HD keychain](https://hackmd.io/_uploads/ryxunXfPWx.png)


# Conclusion

In summary, our hybrid hierarchical deterministic wallet shows how a single [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) seed phrase can deterministically generate both classical (ECDSA) and post-quantum ([Falcon-512](https://falcon-sign.info/)) key hierarchies, maintaining usability while preparing for future quantum threats. By leveraging standards like [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), [BIP-39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki), [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki), [BIP-85](https://github.com/bitcoin/bips/blob/master/bip-0085.mediawiki), and [SLIP-10](https://slips.readthedocs.io/en/latest/slip-0010/), the design ensures strong key separation and preserves a user experience consistent with existing wallet workflows. While Falcon serves as our main example, the approach is flexible and can be extended to other post-quantum schemes, such as [ML-DSA](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf). 

An open-source Rust implementation is available in our [Bedrock repo](https://github.com/tectonic-labs/bedrock/blob/main/src/hhd.rs) for the community to explore and build upon. We also have its specification in the [hhd-spec repo](https://github.com/tectonic-labs/hhd-spec).

# References & comments

[1] The day quantum computers will become powerful enough to break the classical cryptographic assumptions that protect today’s blockchains.
[2] Also, as commented by Bas Westerbaan on [PQC Google group (22.12.2022)](https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/3Cu70s0doYY?pli=1): *For every scheme it's possible to make key generation deterministic by replacing "randombytes()" calls by calls to a XOF that has been seeded by the "private key seed".*
[3] Along with some implementation challenges as commented by [Cloudflare blog post.](https://blog.cloudflare.com/pq-2025/#be-careful-with-fn-dsa)
[4] As commented by Dustin Moody on [PQC Google group (28.08.2025)](https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/CsWPP35LJWw/m/NPAuzmHaAAAJ): *our current draft includes tweaks to the Gaussian sampler in Keygen made in consultation with the Falcon team, including an allowance for fixed point arithmetic – it’s **not identical to either the original Falcon submission** or to HAWK, though.*
[5] [FIPS 204 section 3.6.1](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf)
[6] Falcon original proposal [page](https://falcon-sign.info/) under "Performance" section: *Private key size (not listed above) is about three times that of a signature, and it could be theoretically compressed down to a small PRNG seed (say, 32 bytes), if the signer accepts to run the key generation algorithm every time the key must be loaded.*
[7] [Current](https://github.com/pornin/rust-fn-dsa/pull/5) implementations use 32 byte seed which is enough for Falcon-512 but arguably not for Falcon-1024 where a 40-byte seed should be passed (check [[P19] last paragraph of Section 5.1](https://eprint.iacr.org/2019/893.pdf)).
[8] SHA256 was recently analysed in [[GM19] Table 1](https://arxiv.org/pdf/1902.02332) and it provides a quantum security of 166 bits due to Grover's algorithm.
[9] In [[DEF+21]](https://eprint.iacr.org/2021/1287.pdf) the authors actually show a slight degradation in the security strength of BIP-32 from 128 bits to 91 bits. It would be interesting to have a more formal analysis of BIP-85 procedure and its relation to PQ key generation considering [[DEF+21]](https://eprint.iacr.org/2021/1287.pdf) result.