Topic: Concern about RNG (Read 577 times)

Since i only code Python, i wonder if it's possible with WebAssembly? AFAIK WebAssembly can be used on various browser on any OS and you can compile C/C++ module to WebAssembly.

Unfortunately it's hard to safely implement a RNG in a C-callable and OS agnostic way that is thread safe, fork()ing safe, and being fork/thread safe is pretty important for this sort of thing.   Within Bitcoin Core it's easier because it's all C++ and threading/locking is accomplished in a particular way and the project can guarantee that it's not going to fork() and do something bad.

There are ways to handle fork safely but they're ugly and not particularly portable.

The proc reading stuff is system specific though the code in Bitcoin core already supports handling the normal platforms bitcoin core runs on (linux/windows/osx/openbsd/freebsd/windows/etc.).

I strongly believe that somebody should make this RNG available for end-users in an external library such as libbitcoinconsensus or at least extract the code into a separate project. It seems very beneficial for secure random number generation.

Even better if it's implemented in an OS-agnostic way such as C/C++, without opening and special files in places like /proc so it can be inserted into Windows/MacOS/Linux/BSD programs at the same time.

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.

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

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).

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!"

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.

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.

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.

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

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.

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/

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).

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.

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.

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.

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 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.

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.

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 

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

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.

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

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.

---

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.

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.