Should wallets warn users about low-quality entropy during SEED generation?

[satscraper]

Been thinking about this after the Coldcard drama.

Right now, most wallets ^{software and hardware} generate your SEED phrase and hand it to you with zero indication of whether the underlying randomness was actually good. No warning, no way to know.

In my view, it would be very welcome if wallets performed the relevant self checking  on the quality of the entropy used to generate  user's wallet, and warned  user if the entropy falls below, say, 128 bits. Either way, something as simple as: "Entropy below recommended minimum, proceed anyway? Yes/No" would at least surface the problem instead of silently handing someone SEED phrase that could potentially be compromised.

It's probably the right time to raise this matter with hardware wallet makers and software developers.

Curious what people think about this.

[Charles-Tim]

Example, how would Coldcard warn when its developers do not even know about it? Or maybe the developers know about it and are behind what happened.

Use open source wallet. Make use of passphrase that has strong characters or use a multisig wallet.

Adding your own protection (like passphrase or multisig) to it makes your wallet secure.

[satscraper]

How would Coldcard warn that when its developers do not even know about it? Or maybe the developers know and are behind what happened.

ColdCard and other wallet developers could implement self-testing feature based on NIST SP 800-90B standard.

4.2 Types of Health Tests

Start-up tests: run after power-up/reboot, before first use. "The specific conditions in which the startup tests must be run for FIPS-validated cryptographic modules are determined by the requirements of FIPS 140."

Continuous tests: "run indefinitely on the outputs of the noise source while the noise source is operating... these tests are run continuously on all digitized samples obtained from the noise source, and so tests must have a very low probability of raising a false alarm."

On-demand tests: "can be called at any time... it does require that the entropy source be capable of performing on-demand health tests." Rebooting is an acceptable way to trigger these if it re-runs the start-up tests.

 Make use of passphrase that has strong characters orr use a multisig wallet. Add your own protection to it.

This is trivial routine for me, but not for many users.

[hosemary]

Isn't the amount of entropy determined by the source of entropy and the algorithm the software uses to generate it? For example, if you generate millions of seed phrases through electrum, they all will have 132 bits of entropy, regardless of the final results.
Also, even if the algorithm is flawed, the final result will still look completely random and there is no way to tell how random it is just by checking the final result.

[satscraper]

Isn't the amount of entropy determined by the source of entropy and the algorithm the software uses to generate it?

Hardware noise sources may fail or degrade. But what would be suitable for given hardware wallet to catch the software bug ^{the current ColdCard case} that swaps out the hardware entropy source and  produces the plausible looking but predictable output I don't really know. That is why I have raised the discussion here.

[Mia Chloe]

Been thinking about this after the Coldcard drama.
Right now, most wallets ^{software and hardware} generate your SEED phrase and hand it to you with zero indication of whether the underlying randomness was actually good. No warning, no way to know.

First off, just like charles tim mentioned, no one was really aware of the firmware issue basically because if they were aware in the first place the developers would have notified them fixed it and that theft wouldn't have happened to start with, most walllets don't even give you option to change where your entropy comes from.

The average bitcoiner isn't even conscious about entropy and many people till date don't even know you can generate you own entropy source yourself and use it to hash for your seed phrase. To avoid complexities generally it's just best you pick the safest form of entropy generation you can get and allow softwares use it instead of complicating things.

[Zaguru12]

Isn't the amount of entropy determined by the source of entropy and the algorithm the software uses to generate it? For example, if you generate millions of seed phrases through electrum, they all will have 132 bits of entropy, regardless of the final results.
Also, even if the algorithm is flawed, the final result will still look completely random and there is no way to tell how random it is just by checking the final result.

Exactly the question I wish to ask about the randomness is that isn’t the software of the wallet actually unaware of the degree of the randomness? From my knowledge I think it’s dependent on the underlying software (or after generation they employ NIST to check) and this why in CSPRNG I have read about using Linux been one of the best. 

I think with this a wallet can not identify the true degree its randomness. The only reason why I think most people are challenging or blaming cold card is simply because there was reports that their system source (TRNG) wasn’t that random as it was broke but they didn’t take that warning or acted upon it and it was what lead to this, which is why I also call for them to be blamed

First off, just like charles tim mentioned, no one was really aware of the firmware issue basically because if they were aware in the first place the developers would have notified them fixed it and that theft wouldn't have happened to start with, most walllets don't even give you option to change where your entropy comes from.

Wasn’t there many warning about this flaws in the past, I have been reading about many links long this forum about that this flaw

[internetional]

Given what happened to Coldcard, if I were the developer of any wallet that generates seed phrases, I would audit the generation mechanisms used in every single version of my wallet. If it turns out that unreliable randomization tools were used, it is critical to find a way to urgently notify users - or at least the wider public, even if that might trigger a hunt for the discovered vulnerability. For instance, I heard somewhere that the Nunchuk wallet generated its private keys using Coldcard. If that is the case, it needs to be reported. On the flip side, if the audit shows that the randomization was always strong, that is also worth sharing.

On another note, I have seed phrases generated by wallets that are no longer supported by their developers. Just to be safe, I think I will stop using those seed phrases altogether.

[hosemary]

Hardware noise sources may fail or degrade. But what would be suitable for given hardware wallet to catch the software bug ^{the current ColdCard case} that swaps out the hardware entropy source and  produces the plausible looking but predictable output I don't really know.

The problem is you can't tell how good the randomness is just by checking a single seed phrase.
If you want to determine whether the generated seed phrases are truly random or not, you have to generate a large number of seed phrases, and analyse them to see if they cover the entire 128 bit space uniformly.

[dkbit98]

It would be a good idea that all wallets are showing how strong entropy is when you are generating, but that would be worthless if you had to trust them only.
Only good way would be to give you proof that you can easily check and verify yourself that entropy is strong enough.
I am not sure this is going to be easy to implement for newbies to understand.

[Mia Chloe]

It would be a good idea that all wallets are showing how strong entropy is when you are generating, but that would be worthless if you had to trust them only.
Only good way would be to give you proof that you can easily check and verify yourself that entropy is strong enough.
I am not sure this is going to be easy to implement for newbies to understand.

If this was a feature will basically any wallet not automatically conclude their entropy level is very safe and okay? Basically most centralized wallet and custodial wallets could go out of business if they end up telling you your entropy is weak at the point of seed generation knowing fully well they provided the entropy.

Instead, what would be more interesting is if we could perfectly mimic random events like die rolls. To make things more complex say 6 dies 100 times if possible to compress.

[PrivacyG]

They definitely should.  It would be some type of 'fail safe' to prevent situations like the Coldcard one.  I suppose other unknown bugs in the code could lead to a similar low quality entropy too with out the user even knowing.

[pooya87]

Obviously such a feature would be great to have and it may even prevent some losses, but the problem is implementing such a feature is very difficult and to some extent it is impossible since certain bugs would produce an entropy that by all standards look strong but it is not. That's not something that can be caught by the consumer of the entropy (aka the wallet).

Let me give you a simplified example. Is this a secure entropy?

Code:

20b2107b5543df08fdb198d8650e50abb36c1dcefb4e2478413d10538a213dde

It looks like it. It is 256 bits and it looks random. Look at the binary:

Code:

00100000_10110010_00010000_01111011_01010101_01000011_11011111_00001000_11111101_10110001_10011000_11011000_01100101_00001110_01010000_10101011_10110011_01101100_00011101_11001110_11111011_01001110_00100100_01111000_01000001_00111101_00010000_01010011_10001010_00100001_00111101_11011110

But it is not secure at all. It is double SHA256 hash of my username. At best if we assume it was random characters it provides 41 bits of entropy. Realistically it's 0 bits since it is a known phrase. And this is produced from a "flawed implementation" that does "SHA256d.Compute(userInput)". This can't be caught at the end of the line by the wallet. It can only be caught by looking at the code. That's somewhat what the ColdCard bug is like.

[nc50lc]

Right now, most wallets ^{software and hardware} generate your SEED phrase and hand it to you with zero indication of whether the underlying randomness was actually good. No warning, no way to know.

AFAIK, detecting if the underlying PRNG/CSPRNG/MT is not working is already being used by well-written software.
Without it, the software should prevent the user from generating a seed phrase or return with related errors.
Take IanColeman's BIP39 tool just for example, it will prevent the user from clicking "Generate" and will display a warning if CSPRNG isn't available.
Ref: iancoleman.io/bip39

But the thing is, that's the best they can do.
Once they detected that there's a working PRNG that the software requires, it'll work normally without errors since there's no reliable way
to verify that the randomly generated number by the OS/software is indeed random.
The code should be audited instead.

If it's a bug like Coldcard's issue:
It's a bug, obviously, the developer doesn't know that the vulnerability exist so they can't preemptively add a warning that there could be a bug.

[satscraper]

Obviously such a feature would be great to have and it may even prevent some losses, but the problem is implementing such a feature is very difficult and to some extent it is impossible since certain bugs would produce an entropy that by all standards look strong but it is not.

If they reduce the attack surface, eliminating even a single bug, it would be appraise as positive.

But the thing is, that's the best they can do.
Once they detected that there's a working PRNG that the software requires, it'll work normally without errors since there's no reliable way

I think you are right.

HW makers could at least be capable of checking  whether  imbeded hardware TRNG ^{or any other external entropy source} is working or not and throw the warning in the case it is out off commission provideng the relevant self test module was in there firmfare implemented and give the chance to user to select the following actions.

[ABCbits]

How would Coldcard warn that when its developers do not even know about it? Or maybe the developers know and are behind what happened.

ColdCard and other wallet developers could implement self-testing feature based on NIST SP 800-90B standard.

4.2 Types of Health Tests

Start-up tests: run after power-up/reboot, before first use. "The specific conditions in which the startup tests must be run for FIPS-validated cryptographic modules are determined by the requirements of FIPS 140."

Continuous tests: "run indefinitely on the outputs of the noise source while the noise source is operating... these tests are run continuously on all digitized samples obtained from the noise source, and so tests must have a very low probability of raising a false alarm."

On-demand tests: "can be called at any time... it does require that the entropy source be capable of performing on-demand health tests." Rebooting is an acceptable way to trigger these if it re-runs the start-up tests.

FWIW, the implementation for that standard already exist on https://github.com/usnistgov/SP800-90B_EntropyAssessment. NIST code and PDF doesn't mention how long the test took. But i found a research that benchmark the test time.

   NIST program written in Python    NIST program written in C++
IID test    17 h    1 h 10 min
[IID track] Estimation entropy    −    −
[Non-IID track] Estimation entropy    15 min    20 s
Restart tests    2 s    2 min
Total execution time    17 h 16 min    1 h 13 min

Over 1 hour for full test isn't practical, i expect most people don't want to wait that long.