Concern about RNG

[BlackHatCoiner]

Around a year ago I had earnt some bitcoins which I sent them to a cold storage address with the mindset of keeping them long term. I recently read about RNG and its weaknesses and I'd like you to tell me your opinion about the way I did it.

• I formatted a laptop and installed windows 7.
• I downloaded the iancoleman website as an html file.
• I opened it with firefox and then clicked generate.
• Then I wrote the mnemonic on a piece of paper and closed the browser.

I could have done the same with electrum, but I chose iancoleman. Is RNG strong enough with a site's javascript? How should I be aware of RNG? I mean, how can I know if it's strong or weak?

[1714145442]

1714145442

[1714145442]

1714145442

[1714145442]

1714145442

[ranochigo]

Iancoleman's site uses the same entropy source as bitaddress, which is Crypto.getrandomvalues(). Not to be confused with math.random which isn't a CSPRNG. It should provide similar entropy levels as it does gather extra entropy from the OS. There really isn't a way to ensure entropy, just ensuring that iancoleman is getting the entropy from a secure source is sufficient.

[Charles-Tim]

I could have done the same with electrum, but I chose iancoleman. Is RNG strong enough with a site's javascript? How should I be aware of RNG? I mean, how can I know if it's strong or weak?

Everything about iamcoleman is open source and it is highly recommended. Iamcoleman make use of 128 bits to 256 bits of entropy to generate seed phrase using a open source codes which the 128 bits is even secure enough and safe to use. You have nothing to worry about, it is as secure as it is BIP39 standard using cryptographic secure pseudo random number generator and open source.

[Husires]

You make it worse, format your OS is not considered safe. You need to buy a hardware wallet, or at least buy a USB, burn an open source operating system, and then run the wallet on it while removing network part.

Using iancoleman will complicate your way because the private key is generated using your the browser, but they are supposed to have the same level of electrum.

it is better to use electrum than iancoleman


for RNG attack it only require single access to the system. format your OS will make that bug.

[ranochigo]

Iamcoleman make use of 128 bits to 256 bits of entropy to generate seed phrase using a open source codes which the 128 bits is even secure enough and safe to use. You have nothing to worry about, it is as secure as it is BIP39 standard using cryptographic secure pseudo random number generator and open source.

You can use less if you're choosing seed phrases shorter than 12 words.

Anyways, while it does indeed appear to be using the RNG correctly, provided that your browser correctly provides the entropy. I don't believe that open source codes means anything unless it is signed by someone you trust; for which the PGP is signed and available on github as well.

You make it worse, format your OS is not considered safe. You need to buy a hardware wallet, or at least buy a USB, burn an open source operating system, and then run the wallet on it while removing network part.

for RNG attack it only require single access to the system. format your OS will make that bug.

Formatting OS is safe enough, unless you're messing it up badly. Using a USB as a liveCD doesn't eliminate any BIOS rootkit or anything similar. While I personally wouldn't run Windows to do anything like generating a cold wallet, its still okay as long as it is offline.

[Charles-Tim]

You can use less if you're choosing seed phrases shorter than 12 words.

Recommended
128 bits of entropy generate 12 words after checksum, 160 bits generate 15 words, 192 bits generate 18 words, 224 bits generate 21 words, 256 bits generate 24 words.

100% prone to attack
96 bits will generate 9 words, 64 bits will generate 6 words, 32 bits will generate 3 words.

It is even states on iamcoleman that 'mnemonics with less than 12 words have low entropy and may be guessed by an attacker' in the process of generate less than 12 words seed phrase.

Anyways, while it does indeed appear to be using the RNG correctly, provided that your browser correctly provides the entropy. I don't believe that open source codes means anything unless it is signed by someone you trust; for which the PGP is signed and available on github as well.

The source code is on GitHub and recommended by developers including experienced members Bitcointalk community.

[ranochigo]

Recommended
128 bits of entropy generate 12 words after checksum, 160 bits generate 15 words, 192 bits generate 18 words, 224 bits generate 21 words, 256 bits generate 24 words.

100% prone to attack
96 bits will generate 9 words, 64 bits will generate 6 words, 32 buts will generate 3 words.

It is even states on iamcoleman that 'mnemonics with less than 12 words have low entropy and may be guessed by an attacker' in the process of generate less than 12 words seed phrase.

Thanks for the warning as well. Thought that it was obvious that it shouldn't be done.

[dkbit98]

Random Number Generation is a tricky thing and I did some research about it when I explored how hardware wallets are doing entropy.
Real randomness can be achieved with good old dices, coin flipping, or gambling cards, and we can argue that many random generated numbers are not really random.
If we can reproduce some numbers that look random then we call this PRNG - Pseudo Random Number Generators, and there are also TRNG - True Random Number Generator
and HRNG - Hardware Random Number Generator.

I was using one software password generator that is open source, but how can I really know it generates truly random passwords that can't be reproduced?
I need bigger brain to understand this 

[BlackHatCoiner]

it is better to use electrum than iancoleman

I don't understand. Why is electrum better than iancoleman? What part of security does electrum offer that differs from an html page with javascript?

Real randomness can be achieved with good old dices, coin flipping, or gambling cards, and we can argue that many random generated numbers are not really random.

I think you're right, but I wouldn't call it "Real". I'd rather call it "Proved randomness", because you're seeing it by yourself that it's been chosen randomly.

Formatting OS is safe enough, unless you're messing it up badly. Using a USB as a liveCD doesn't eliminate any BIOS rootkit or anything similar. While I personally wouldn't run Windows to do anything like generating a cold wallet, its still okay as long as it is offline.

I agree, I think it's an overreaction to say that by formatting the OS I'm still not safe. Even if I installed ubuntu, onto a laptop that had malicious programs on windows, there would still be a chance of affecting the other OS.

I'd like to make another question regarding iancoleman:  When you run a javascript script from your browser, is it stored on your memory or hard drive? For example, electrum mnemonics can be found on the wallet file.

[BrewMaster]

I'd like to make another question regarding iancoleman:  When you run a javascript script from your browser, is it stored on your memory or hard drive? For example, electrum mnemonics can be found on the wallet file.

electrum mnemonics are found on your hard drive because the wallet is supposed to save them on your hard drive (for future usage) by default but web tools such as iancoleman tool are not supposed to save anything to disk (they have no future usage). they must run completely from memory and nothing else. and i think it is doing that but i have never checked the source code of it because i am not well versed in the language although i know a little.

[ranochigo]

I don't understand. Why is electrum better than iancoleman? What part of security does electrum offer that differs from an html page with javascript?

I concur, in normal scenarios, they are both safe. Browsers are however another security risk as you won't know how it'll behave while the seed is being generated. Not that I really dislike it, just that using Electrum can probably achieve the same thing.

I'd like to make another question regarding iancoleman:  When you run a javascript script from your browser, is it stored on your memory or hard drive? For example, electrum mnemonics can be found on the wallet file.

Iancoleman's script cannot control how your browser function; entirely possible that the browser caches parts of the webpage and accidentally reveals your seed phrase. Not that big of an issue if you choose to do it offline and wipe your drive again after using it.

[NotATether]

It should provide similar entropy levels as it does gather extra entropy from the OS.

The operating system is the only place that has access to a hardware random source (a la CPU) and mouse/keyboard movement from drivers. Everything the browser adds just mixes this random entropy as a second layer - if browsers even do that and don't just return the OS entropy - but a browser's CSRNG can't create additional entropy than what it can get from the OS since it's using the same source that would've been used by any other program. The mouse/keyboard input after all comes from OS events.

Even kernels themselves have their own software RNG that mixes the hardware entropy before it gets to the browser (this is true at least for Linux, the same cannot be said for Windows NT kernels assuming that bug was never fixed after XP).

[coinableS]

I've had similar concerns about RNG when it comes to a mnemonic phrase, so I built one that takes your mouse entropy and then adds CSPRNG random bytes for additional entropy. It uses bitcoinjs-lib which is a well-known trusted library. 

Demo: https://coinables.github.io/bip39/

[dkbit98]

I've had similar concerns about RNG when it comes to a mnemonic phrase, so I built one that takes your mouse entropy and then adds CSPRNG random bytes for additional entropy. It uses bitcoinjs-lib which is a well-known trusted library.  

Demo: https://coinables.github.io/bip39/

It is looking very good but one suggestion I have is that area for mouse movement should be bigger or even full screen can be used to increase randomness.
I would still like to see code being checked and reviewed by other coders for issues and bugs since it is open source.

[ABCbits]

When you're in doubt, it's safer to use RNG proven to be secure (assuming the software let you enter your own entropy). Besides, researching whether the software use secure RNG could take some time. Usually i would rely /dev/urandom

Code:

cat /dev/urandom | xxd -l 64

[gmaxwell]

I would not use any javscript key generator.

1. the underling cryptographic software is almost entirely untested.  For every JS ecc library I've seen the tests consist of a couple static test vectors.  The underlying software has previously had bugs where it would frequently (e.g. one out of a few hundred to few thousand uses) generate an incorrect pubkey and even since the tests have not been improved to the point where they would catch such flaws.  The extremely poor performance of the JS enviroment would make such testing burdensome and the inconsistent execution environment makes testing less useful.

2. Javascript VMs are extremely complex and have a long history of incorrect computation bugs.  As referenced above this means that even if robust testing did exist it would really need to be executed for each user.  Corruption by JS VMs have resulted in incorrect key generation.

3. Access to strong random data in the browser/js environment is limited and extremely fragile.  Widely used libraries for accessing strong randomness have had flaws where they returned extremely weak randomness that went unnoticed resulting in funds loss.  JS dynamic loading and overriding behavior makes it hard to nearly impossible to review a piece of JS code and be confident that what you think is running is actually running.  The extremely difficulty of competent review means it substantially doesn't happen.

4. Web page applications are subject to remote replacement unless your usage is just perfect and there are absolutely no externally loaded pieces of content. Even running with a machine unplugged from the network is not an absolute assurance because there may be cached remotely loaded content that could be replaced while the system is online.  A system which is only secure with perfect use is simply not secure because no human is perfect.

5. the JS loader/linker solution provides no strong guarantee that the various modules implementing a program are atomically updated. You might get a newer version of an application but be using a cached copy of older modules in other files, the two could be silently incompletely.  This has resulted in total funds loss for some users of one web wallet in at least one instance in the past.

6. Uniformly JS implemented cryptographic code has absolutely no protection against timing, cache, power/emi side channels.  It is far from clear if it is even possible to do so.  Even if your threat model does not include physically present attackers,  pratical demonstrations have been made where JS code running in a separate tab are able to steal cryptographic data from unrelated tabs via these sidechannels.  If it's not even possible to implement the basic best practices this may create a bad culture that doesn't even bother being good (as evidence by the lack of testing) since being great isn't on the table.

7. No JS implemented key generation code that I'm aware of performs after the fact validation of its operations, so even if the software is perfect a bitflip can cause an incorrect key (or a private key leaking signature), resulting in a total loss of funds.  (By contrast, Bitcoin core validates key generation and signatures after the fact).

8. The aforementioned issues mean that most competent developers and reviewers won't bother making or reviewing these things, greatly increasing the odds that any such tools you use were not made or reviewed by competent persons.


As far as OS RNG's go, unfortunately /dev/(u)random on a number of systems has multiple instances of insecurity (e.g. see netbsd).  The RNG in Bitcoin core is hardened against weakness of the OS rng by using a hash to combine the OS rng, hardware rngs (if available), and various sources of non-cryptographic entropy (timestamps, network counters, host info, etc.) and passes the result through an computationally expensive hardening function so that even if there is a total failure of cryptographic entropy you still have a fighting chance.

[coinableS]

As we all know Greg hates bitcoinjs-lib. The bitcoinjs library is pretty clear about never re-using any address due to javascript constantly working against them for possible key leakage in signatures.

What it really comes down to is users wanting more features and options that bitcoin core doesn't satisfy, so other developers build it on different stacks. Case and point, bip39 mnemonics.

Bitcoin core does not utilize BIP39 at all, so I'm not sure why you are bringing it up in this thread as what people should use.

[pooya87]

What it really comes down to is users wanting more features and options that bitcoin core doesn't satisfy, so other developers build it on different stacks. Case and point, bip39 mnemonics.

That's true but they don't have to build those features using an inherently weak programming language. Take Electrum for example, it is secure, it offers a lot of features that core doesn't (SPV, mnemonic, user friendly, cold storage,...) and it is written in python which is so much safer than JS.

[gmaxwell]

As we all know Greg hates bitcoinjs-lib.

The standard practice of automatically characterizing specific actionable criticism as an unsubstantiated emotional response ('hate') is an indication of defective culture that puts users at risk.

I don't hate any of it-- it just has an objective history of both theoretical and actual flaws which have lost users money, and AFAICT little has been done to address the process errors which allowed those flaws to end up in production (and for some of the issues, it's not clear to me that much really can be done).

possible key leakage in signatures

Not reusing addresses might make some leaks harder to exploit but it's an extremely weak protection,  particularly because the user themselves is not actually in control when it comes to reuse -- someone can send funds with multiple outputs and there isn't much they can do about it.  It's also not realistic because users widely and regularly reuse addresses regardless of what advice they're given, and some services essentially require them to do so (e.g. by only allowing a single static withdraw address.).

To me that seems more like blame shifting rather than an actual protection for users. "We told the drivers of the pinto to drive carefully and not get in any collisions! It isn't our fault the cars exploded on them!"

[BlackHatCoiner]

I would not use any javscript key generator.

That was a well-read and thank you for writing it. I want to state that I had tried it before doing anything with iancoleman, I had firstly test to generate twelve words and then I imported them on an electrum to test if it's working correctly. Although, I can't know the second time I tried, because I've never typed my mnemonic on an electronic device. But that's not the point, you justified why I should use Bitcoin Core or Electrum from now on, but I personally don't want to move my funds right now. I find it an overreact. A little paranoid.

Whether I change it or not, it won't have any difference. Even if it was wrongly generated, I wouldn't be able to recover my funds and move them on electrum. The only positive thing I see by moving them to an electrum generated address is the randomness' strength.

The RNG in Bitcoin core is hardened against weakness of the OS rng by using a hash to combine the OS rng, hardware rngs (if available), and various sources of non-cryptographic entropy (timestamps, network counters, host info, etc.) and passes the result through an computationally expensive hardening function so that even if there is a total failure of cryptographic entropy you still have a fighting chance.

Can you tell me the line and file of the source code that does this job?