Topic: --- (Read 236 times)

That's not the point. Here is gmaxwell's opinion on this and I consider him more competent and credible than most: https://bitcointalksearch.org/topic/m.56590276.

I've had little experience with JS, specifically with regards to its security so I can't comment too much. I'll rather something that interfaces directly with the a CSPRNG than to have it ask the browser for entropy and risk the browser potentially not implementing it correctly.

If you consider using it on broswer in offline mode not comfortable, you can still run its HTML file on an airgapped device.

The Ian Coleman website is using javascript, in a browser to generate entropy and your seed... I'm not sure I would be comfortable calling it "safe".

It's certainly a useful tool, and open source, and nothing obviously malicious about the code it is using... however, none of that proves that it is cryptographically "safe"!


Not if you want to maintain compatibility with the BIP39 "standard"...
Entropy is in multiples of 32 bits, min length of 128, max length of 256. So, to be strictly "BIP39 compatible", your seed should be 12, 15, 18, 21 or 24 words long.

There is a long discussion about it on the issues section of IanColeman's BIP39 tool on GitHub. Here is the link: https://github.com/iancoleman/bip39/issues/435. It will explain it better than I can.

An easy way to think about is explained in this post on that thread: https://github.com/iancoleman/bip39/issues/435#issuecomment-690631830. If you take a six sided dice and roll it twice, then there are 36 possible outcomes. In binary, this gives you the following possible combinations:


The two least significant bits have a 50/50 split between 0 and 1. The next three bits, however, are all biased, with twenty 0s and sixteen 1s. The most significant bit is the most biased of all. Now obviously this bias is lessened with a 256 bit number, but it isn't eliminated.

Can you explain why 0 and 1 (base 2) would be preferable to 0, 1, 2, 3, 4, and 5 (base 6)?


It depends on the dice, and how you use them.

As an extreme, imagine a poorly constructed die that is unevenly weighted and rolls a two 50% of the time when thrown randomly.  Also, imagine always holding the die a half inch from the table with the number two facing upwards and then just dropping it.  Clearly, neither of these would result in much randomness.

If you are confident that you have "fair dice" (each face has an exactly equal chance of showing up when tossed randomly), and you are confident that you have come up with a reasonable method of tossing the dice in a random way, you have one other issue to consider.  You might think to save time by rolling multiple dice simultaneously.  However, if you do this, you need a way to make certain that you are randomly recording the results of each throw.  If you always record them from smallest value to largest (or largest to smallest) then you will have lost a LOT of randomness.  If you try to force yourself to choose at random, you may be subject to unconcous biases that you are unaware of.

Assuming that you've overcome biases in dice manufacture, and in your tossing method, and in your recording method, then dice could possibly be a good source of entropy.

A six sided dice provides a theoretical entropy of 2.58 per roll and you only need to theoretically roll it a little under a hundred times (99) for 256 bits of entropy for a 24 words (though you can get a 24 words seed with less entropy too). This is done under the assumption that each of the rolls are completely random and you throw it on the same way everytime and the dice is carefully designed to have zero bias, ie. Casino dice, etc. Crypto.getRandomValues() requests the browser for a cryptographically secure entropy and in Chromium's case, references /dev/urandom.

I'd say no. There are various variables affecting your dice roll and potentially lower its entropy below 256bits, even if you don't realize it. Problem with Crypto.getRandomValues() is that the way it gets the entropy can differ across each browser as there is no standardization on this though mostly it does use the system's CSPRNG. If you want to be extra careful, then you can XOR your own sourced entropy with the entropy generated from /dev/urandom and that should be secure enough for most uses. The amount of entropy would be thus the source with the most entropy (of the two).

I assume you're talking about generating your seed off the HW wallet and then using the generated seed on your Trezor by recovering it? You should assume the security of the seed to be that of an airgapped wallet and the hardware wallet only protects you from any compromise during its usage but not during the seed generation.

Iamcoleman is open source, if used in a safe offline or airgapped devices, then it is safe. If anything happens, it will only be the fault of the user not the Iancoleman HTML file.

All I know is that generating seed phrase directly on Iancoleman which follow BIP39 standard is safe, also generating that on an open source wallets like Trezor that follow the BIP39 standard is also safe. If you do not generate the entropy carefully, you can make mistake, you will need to throw coins 256 times to write down the binary outputs, and the result should be as exactly as the coin is tossed. But, I will still again recommend you to generate the seed phrase directly.

Less than 12 words seed phrase are not secure, but it is not more than 24 words on Iancoleman, but you can make use of passphrase to extent the words, maybe it is what you meant. More than 24 words seed phrase can be gotten, but not on Iancoleman and not on any wallet I have used, the maximum word is 24 unless you extend it with optional passphrase.

If it is optional passphrase, it can help especially if an attacker saw the seed phrase and did not know the passphrase, he will still not be able to access your coins because passphrase generate another seed, keys and addresses entirely.

To recover back your coins, keys or address
https://blog.trezor.io/learn-about-trezor-recovery-seed-offline-backup-fe235873c69f
https://wiki.trezor.io/User_manual:Advanced_recovery#:~:text=Start%20by%20plugging%20your%20uninitialized,check%20the%20Advanced%20recovery%20checkbox.

If you have doubts about the randomness of the entropy being provided by your OS, then flipping a coin 256 times is a perfectly reasonable alternative. If you plan on rolling a dice, then doing something like odd=1 and even=0 is preferable to assigning a different entropy value to each number.

Adding additional words to your seed phrase is a bad idea. If you think the first 24 words are insecure, then find a different method to generate them. Although you can still derive a wallet and keys from 36 words, most wallets (the Trezor you mentioned included) won't accept 36 word seed phrases.

On the Trezor T you enter your seed phrase via your computer. On the Trezor One you enter it in to the device itself. See the following pages:
https://wiki.trezor.io/User_manual:Recovery
https://wiki.trezor.io/User_manual:Recovery__T1

It depends on how you define randomness. If you shake a dice n number of times, you can prove to yourself that your entropy is completely unpredictable. Once you tell your computer to run the getRandomValues() function, it returns you an unpredictable result. At least, this is what it promises you.

Generating entropy from a computer isn't that strong randomly as it is with a dice. With the dice, you're proving it to yourself, directly! Not to mention about the RNG's weaknesses or non-randomly generated seeds from a maliciously affected computer.  

I've had same issues in the past, that's why I made this: [Open Source] Coin Flipped Seed

It's an overkill.

---