Using mouse input for extra entropy

[AndreyVen]

A compromised computer producing not truly random numbers is unlikely to produce a collusion after two 'random' events. They will rather produce random numbers in a smaller space. The output will appear random without testing, but someone with knowledge of the specific space numbers will be generated will be able to generate a collusion with fairly low effort.

The movement of the mouse is intended to counter the above risk in adding user specific random to create a larger space of possible private keys even if the computer's random function is compromised.

If computer/OS random function (such as /dev/random) is compromised, then that means your computer most likely is compromised as well since you need superuser access to compromise it.
<>
Besides, good entropy won't help if the output is biased.

Using your mouse for additional 'randomness' will only help against a narrow subset of possible attacks, but one that is difficult to detect.

This might help you if you are using an 'offline' computer to generate private keys that has previously been exposed to the internet, but that will not be connected to the internet in the future. An attacker may anticipate this and mess with the /dev/random function and nothing else.

I understand this private key generation will take both the output from the /dev/random and the mouse movements converted into a number, and display a private key based on both. So if the /dev/random produces the same output two times, the difference in mouse movements will cause the software to produce two private keys.

The duration of mouse movements play a huge role as well. It gets exponentially more secure the longer you move your mouse around. every movement of the mouse so to say makes its predictability increasingly more difficult. So even if you move the mouse in a predictable manner for 10 seconds, if you move it in a non-standard way for 1 additional movement it becomes practically impossible to predict. Now do this for 30 seconds and you see where this is going. I don't have the math for this at hand right now, but it is simple statistics.

[1713561106]

1713561106

[1713561106]

1713561106

[Kakmakr]

No, you are mistaken. If the site is malicious it could be programmed to generate private keys known to the site owner. In that case it doesn't need network connectivity to compromise wallets so using it offline doesn't make a damn bit of difference.

Well, until you have some evidence that this is happening, you can't condemn the website.

You showed me a link of a newbie that lost hia funds because he didn't take any precaution and didn't follow website recommendations.

Another victim of bitcoin paper wallet dot com: https://www.reddit.com/r/CryptoCurrency/comments/cyd6uj/bitcoinpaperwalletcom_scam_or_not_4_btc_stolen/ .

I use https://www.bitaddress.org for my paper wallets and they also use mouse input for extra entropy, but I see a article posted in 2016 says it is not safe to use it? https://www.newsbtc.com/2016/12/11/bitcoin-users-stop-using-bitaddress-org-look-alternatives/

I have not had one of the 100's of Paper wallets that I created "offline" with this script, being compromised. I used a old second hand computer & printer that were not connected to the internet to create these wallets and then I physically destroyed it. 

Anyone else care to explain why https://www.bitaddress.org would not be safe to use?

[pooya87]

Anyone else care to explain why https://www.bitaddress.org would not be safe to use?

from reddit by luke-jr taken from that article:

1. It's a website. Even if you download it locally, you're setting yourself a habit of putting private data in your web browser.
2. It's Javascript, which is an extremely poor record for security and crypto, and is super-flexible to the extent that it can be hijacked in subtle ways (think browser extensions that quietly redefine how basic mathematics works).
3. It encourages either address reuse (which has no shortage of problems, as /u/sQtWLgK pointed out), or managing multiple keypairs by hand (which is liable to accidental loss, since key management is excessively complicated and humans screw up eventually).

although i have to disagree about calling the "tool" unsafe just because users may use it wrong (points 1 and 3 and partly 2). for example if someone is using the website then they don't understand what this tool is for, and for these types of users no wallet or other tool is safe because they can lose their money just the same way.
or regarding #3 paper wallets have a clear purpose, they are meant to be used as a cold storage which means when you have a certain amount of bitcoin and want to "store" that for a long time. again if you are reusing that address then you are using the tool wrong.
as for point #2, if the source code is run on a clean and offline computer (like a live Linux from a DVD) then i don't see how this could even be an issue.

[bob123]

as for point #2, if the source code is run on a clean and offline computer (like a live Linux from a DVD) then i don't see how this could even be an issue.

There could be bugs in the implementation of some algorithms, for example regarding PRNG's.
Or they might be simply using outdated libraries, which even could already contain known vulnerability, decreasing the entropy used to generate the private key(s).

The javascript aspect isn't really influenced by where it is run (online / offline pc), but by the code and libraries itself.
A faulty implementation could result in easily crackable private keys. And you have no proper and comfortable way of checking the code / libraries.


A better way would be to simply create a wallet (e.g. core or electrum) on an offline computer with a live distro and use that private key for a paper wallet.

[pooya87]

as for point #2, if the source code is run on a clean and offline computer (like a live Linux from a DVD) then i don't see how this could even be an issue.

There could be bugs in the implementation of some algorithms, for example regarding PRNG's.

well, the same argument could be made about any other implementation and it would be true!

Or they might be simply using outdated libraries, which even could already contain known vulnerability, decreasing the entropy used to generate the private key(s).

i am not an expert and since i have never used this project for anything serious i have never needed to check the source code but it is open source and you could check it. if you found a vulnerability in the implementation, the libraries and the way it is using them then let us know with specifics. otherwise only talking about possibilities covers all the tools, libraries, wallets and implementations out there.

[bob123]

~snip~

This would still require people to download and run the source code, not to simply download the webpage (what everyone is suggesting to do).
And most of the time it is easier to check C/Java/Python code than javascript. Most websites use tons of JS libraries which makes it almost impossible to check them all.

JS is known to be somewhat risky when dealing with crypto operations.

My way to go would still be to either 1) generate a private key using the linux command line or 2) to use a well-known wallet (e.g. electrum / core).

[Artemis3]

You move your mouse until you make the necessary entropy. You can use your keyboard as well with your mouse movements. After that, your private key is generated.

However, I read somewhere that humans are not good sources of entropy.... so maybe that is not a good idea. We problably keep moving the mouse in some crazy pattern.

I have seen that long ago, even Openbsd does it at first (ssh init?) boot (if you don't move the mouse it simply takes longer). Also noticeably Keepass and other password managers, before generating a random password.

I don't think they use only the mouse, but a combination of sources, just to make random more random