Security Risks of Deriving Crypto Wallet Seed Phrases Using Deterministically Derived Salt

Question

I'm working on a project where I want to generate a set of crypto wallet seed phrases from an existing seed phrase. The reason for this is so that using just the original seed phrase the wallet holder can access multiple connected accounts. My approach involves combining the original seed phrase with a deterministically derived salt. Specifically, the process is as follows:

1. Take the original seed phrase.
2. Generate a salt by hashing (SHA-256) the seed phrase with the first word of the seed phrase.
3. Derive the first new seed phrase using crypto.subtle.deriveBits to get the entropy of the existing key with the generated salt, and passing it to bip39.entropyToMnemonic.
4. Repeat the process, each time adding the next word of the original seed phrase to the hash input to create a new salt and derive a new seed phrase.

For example:

• Hash(seed + first word) → Salt1
• seed + Salt1 -> seed1
• Hash(seed + first word + second word) → Salt2
• seed + Salt2 -> seed2

While I understand that if an attacker obtains the original seed phrase, they could potentially generate all derived seed phrases if they guess the algorithm, I am concerned about other security risks associated with this approach.

Any insights or recommendations on how to address these risks and improve the security of this approach would be greatly appreciated. Thank you!

Answer 1

This scheme has several major issues.

First off, don't roll your own, i.e., don't try to invent your own cryptographic schemes. There are many ideas which look good on paper but turn out to be fatally flawed. Note that even experts make mistakes, so the only valid schemes are those which have gone through years of peer reviews, practical applications and revisions.

Secondly, you talk about how the attacker first has to “guess” the algorithm before they can “potentially” derive all seeds. Trying to keep the algorithm secret is security through obscurity and a well-known anti-pattern in cryptography. You should always assume that attackers know the algorithm. So in your case, they can in fact derive all seeds when they know the initial seed.

Then there's a misunderstanding of what a salt is. The purpose of salts is that they are an additional parameter besides the hash input, usually random byte sequences. Your “deterministic salts” aren't salts at all – the entire scheme only depends on the hash input and nothing else. You can see that your scheme is fundamentally broken when you imagine that it's applied to general passphrases, not just seed passphrases (which are designed to have very high entropy). An attacker could precalculate the results of your scheme for many possible passphrases and create a lookup table to speed up future attacks – this is exactly what salts are supposed to prevent.

Last but not least, a lot of design choices look completely arbitrary. For example, your “salts” are generated by taking the seed phrase, repeating the first n words of the same phrase and then hashing this string – it's entirely unclear what this is supposed to achieve.

Instead of trying to invent your own cryptographic schemes, use standard solutions. In your case, you want a key derivation which takes high-entropy input (the initial seed passphrase) and then expands it. A suitable choice would be HKDF which is available in the SubtleCrypto API.

As pseudo-code:

parameters:
  initial_seed_passphrase
  derived_seed_passphrases_count

hkdf_salt = generate_random_bytes(16)

# calculate required length of HKDF output
# I'm assuming 128 bits of initial entropy per seed passphrase
entropy_length_for_derived_seed_passphrases = derived_seed_passphrases_count * 128

# calculate initial entropy for derived seed passphrases with HKDF
entropy_for_derived_seed_passphrases = HKDF(
  input: initial_seed_passphrase,
  hash: "SHA-256", 
  salt: hkdf_salt,
  length: entropy_length_for_derived_seed_passphrases
)

derived_seed_passphrases = []
for i from 0 to derived_seed_passphrases_count - 1:
  # use 128-bit slice of the HKDF result as initial entropy 
  derived_seed_entropy = entropy_for_derived_seed_passphrases[16 * i, 16]
  derived_seed_passphrase = standard_bip39_procedure(derived_seed_entropy)
  derived_seed_passphrases += [derived_seed_passphrase]

Note that the random salt isn't secret and can therefore be stored as plaintext in arbitrary locations.

Using PBKDF2 instead of HKDF wouldn't make sense, because this algorithm is meant for low entropy input like user-chosen passwords and therefore has a cost factor to slow down brute-force attacks. This doesn't apply here. The seed passphrase is high-entropy input (at least 128 bits).

Answer 2

The scheme as presented seems more risky to me than it needs to be, because words from the mnemonic phrase are being fed back into a hash-function, and not a password-based key derivation function (pwd-kdf).

Under normal circumstances deriving the key for the wallet would see the mnemonic secret phrase sent to pbkdf2 to obtain seed. But, if any pair of salt_n hash-digests "somehow" leak, my understanding is they could then be used as an oracle for finding words that produced seed (because they are the same words, and only n-iterations of SHA2 now separate them).

• Salt0 <- H(seed)
• Salt1 <- H(seed).update(word1)
• SaltN <- H(seed).update(word1)...update(wordN)

How the hash-digests might leak is left to the imagination, but I just want to point out that this possible interaction now exists. The further apart these salts are, the harder it would be to compute... but, in the end it would still be easier than having to do it from the other side of the pwd-kdf!

Instead I'd consider sending some derivation of seed to a pwd-kdf, such as window.crypto.subtle.deriveKey.

seed_N <- mnemonic2Seed(
  entropy2Mnemonic(
    pbkdf2_sha512( H("seed-N" + seed) , 545323 , SALT_64BYTE ) 
  )
)