getting Bech32 address on paper wallet

[ranochigo]

Well, yes, but there are ways to avoid any critical mistakes. If you put a dice in a black box, wiggled the box and opened it after a certain period, you'd have accomplished true randomness. You could do that with many dices inside the box to reduce time. Generally, you have to find a way in which the person doesn't know what he's doing. If you go with the rubik's cube mixing or the deck's shuffling, or even the mouse movement used by bitaddress.org, the user knows very well what he's doing; he just tries to do it with the smallest probability.

Also introducing various theoretical factors which can reduce the entropy, Bitaddress still collects entropy from multiple sources (including urandom indirectly) to form the final entropy, so does iancoleman, AFAIK to try to harden the entropy. None of those are meant to replace the CSPRNG that is used primarily. Personally, recommending the user to use an alternative (and single) unproven source of entropy isn't very ideal. I'd rather have myself include a known CSPRNG in calculation of the entropy. Addition of various variables and/or making the user decide the sequence of the dice number has potentially undesirable consequences. This subject has been discussed quite a few times in the forum and quite thoroughly, so nothing much for me to add on here.

[o_e_l_e_o]

If the computer is offline, then the attacker would have to compromise your system's RNG. There is no other method to steal your money, if we assume that it'll remain offline forever.

They could compromise whatever wallet software you are using. It might generate perfectly good entropy, and then spit out a seed phrase the attacker already knows. Or it might let you generate a real seed phrase, but then display receiving addresses the attacker already has the private keys to. I would suggest that attacks such as these are far more likely and far easier than compromising your system's RNG.

Well, yes, but there are ways to avoid any critical mistakes. If you put a dice in a black box, wiggled the box and opened it after a certain period, you'd have accomplished true randomness.

Are you sure? What if the dice was imbalanced so always had a bias towards rolling a 6, regardless of how you shook it?

[BlackHatCoiner]

I would suggest that attacks such as these are far more likely and far easier than compromising your system's RNG.

But, the ways you mentioned can be somehow confirmed. I could install the wallet software on another computer, verify its signature and confirm that if you import that specific seed phrase you do or don't get the same result. How can you confirm the randomness of your kernel? Is there any way that I miss?

Are you sure? What if the dice was imbalanced so always had a bias towards rolling a 6, regardless of how you shook it?

You could shake it x times. If on average you got six x/6 times, then it's not imbalanced.

[ranochigo]

But, the ways you mentioned can be somehow confirmed. I could install the wallet software on another computer, verify its signature and confirm that if you import that specific seed phrase you do or don't get the same result. How can you confirm the randomness of your kernel? Is there any way that I miss?

Is there anything insecure about the implementation (together with the hardening)? Compromising the CSPRNG isn't very common or at least I've never heard of it before.

The problem with generating entropy by yourself is not that it is outright insecure. If done right, there is nothing wrong. But the problem is that people seems to always assume that there is some problem with a certain implementation that has been peer reviewed over and over throughout the years and implemented in various systems. If you want to save the hassle of making your own entropy, generating your own keys and having no knowledge of how to do it securely, then there is absolutely nothing wrong with current implementation. In fact, I believe iancoleman had a slight issue with modulo bias previously in one of their revision, not security critical but just shows that it isn't as easy to do something like this perfectly.

After all, what stops your own wallet/OS from making your signatures use a predictable nonce? Again, entirely theoretical and possibly a fantasy threat but that is about the same level as breaking through the CSPRNG and the implemented safeguards.

You could shake it x times. If on average you got six x/6 times, then it's not imbalanced.

You're probably going to have to roll quite a few times to ensure that you're eliminating the possible bias to ensure sufficient entropy. I would say 50 for minimum of 128 bits and 100 for 256 bits assuming base 6. At least 100 rolls should be okay, if you're not specifically trying to introduce bias. Just roll more and try to even it out.

I've had coldcard for quite a while now and they allow for verifiable entropy generation. I don't consider myself paranoid enough to warrant that and cross validation also requires an airgapped clean computer and if that is the case, I would've foregone Coldcard and just continued with my airgap setup and save a hundred bucks. Relying on multiple computers increases your exposure surface and is just troublesome in general.

[BlackHatCoiner]

Is there anything insecure about the implementation (together with the hardening)? Compromising the CSPRNG isn't very common or at least I've never heard of it before.

It's an extra step an attacker could find the chance to steal your money. I've never heard it before neither, but can you imagine someone doing it? There wouldn't be any way to understand that you're compromised with, possibly, the worst way.

After all, what stops your own wallet/OS from making your signatures use a predictable nonce?

Theoretically, a random number generator would be useless if you submitted a randomly-known generated number during the OS' setup. Your computer could generate random numbers by hashing that special number along with a nonce. In the case of the wallet software, the signature's nonce could be picked by hashing the randomly-known entropy along with a variable that will be increased each time is used.

[ranochigo]

It's an extra step an attacker could find the chance to steal your money. I've never heard it before neither, but can you imagine someone doing it? There wouldn't be any way to understand that you're compromised with, possibly, the worst way.

I can but there are better ways around it. It is unlike the $5 wrench attack, the complexity of such an operation is fairly high, given that users should verify the integrity of their ISO files and that dev/urandom is often mixed with other unpredictable variables. There are tons of other theoretical ways to compromise airgapped setups as well, some can be far more practical.

Theoretically, a random number generator would be useless if you submitted a randomly-known generated number during the OS' setup. Your computer could generate random numbers by hashing that special number along with a nonce. In the case of the wallet software, the signature's nonce could be picked by hashing the randomly-known seed phrase along with a variable that will be increased each time is used.

But you're not trusting your kernel in the first place. What stops the kernel or the OS from using these tactic to introduce covert vulnerabilities? Most wallet uses deterministic signatures nowadays so that is actually addressed. Well, unless it somehow works in an unintended manner due to external influence.

That is not the point though. You're assuming a compromised kernel and possibly other parts of the OS. Then what stops the OS from destroying the security using other methods? There simply isn't anyway for the average person to not be reliant on certain degree of trust on their hardware and their software. If you can't trust the OS, don't bother generating your own entropy because that won't help in making your keys more secure.

Tl;dr if you cannot trust your OS's integrity, you're better off using a pen and paper.

[o_e_l_e_o]

You could shake it x times. If on average you got six x/6 times, then it's not imbalanced.

It's not that simple. You would need to use Pearson's Chi Squared test, and then look up your result on a table such as this one: https://www.itl.nist.gov/div898/handbook/eda/section3/eda3674.htm. A six sided die would have five degrees of freedom. I've not run the numbers, but I suspect you would need several hundred rolls to be able to approach any kind of reasonable confidence interval. I doubt very much anybody is doing this.

But, the ways you mentioned can be somehow confirmed.

Ok then. What about if they compromise your wallet software to reuse the same k value (or use a k value from a small range that is known to the attacker)? Few people even know what a k value is or how it is used - fewer still would be able to verify it is being generated deterministically and not using a predetermined value.

My point is simply that your initial statement that "there is no other way to steal your money" from an airgapped device other than compromising the RNG is incorrect.

[BlackHatCoiner]

It's not that simple. You would need to use Pearson's Chi Squared test, and then look up your result on a table such as this one: https://www.itl.nist.gov/div898/handbook/eda/section3/eda3674.htm.

I had no idea about that; even if I don't understand a thing from the given link, neither from wikipedia, I'll “bookmark” it as food for thought.

Ok then. What about if they compromise your wallet software to reuse the same k value (or use a k value from a small range that is known to the attacker)? Few people even know what a k value is or how it is used - fewer still would be able to verify it is being generated deterministically and not using a predetermined value.

As I said above it can be checked and resolved using hashes of the randomly-known number for signature's nonce; same thing could happen for k. Of course and it can't be verified by the average user. Since when do we, the community, assume what the average user is capable of doing in these extremely paranoid scenarios? These stuff are for those who have a deeper understanding of how this currency works and who want to maximize their security acknowledging that there is no third party to assist them if they make a mistake.

[reason to respond in the “Global adoption” thread]*

My point is simply that your initial statement that "there is no other way to steal your money" from an airgapped device other than compromising the RNG is incorrect.

There is, excuse me; I should change it to “There is no other verifiable way to steal your money”.

[NotATether]

Ok then. What about if they compromise your wallet software to reuse the same k value (or use a k value from a small range that is known to the attacker)? Few people even know what a k value is or how it is used - fewer still would be able to verify it is being generated deterministically and not using a predetermined value.

As I said above it can be checked and resolved using hashes of the randomly-known number for signature's nonce; same thing could happen for k. Of course and it can't be verified by the average user. Since when do we, the community, assume what the average user is capable of doing in these extremely paranoid scenarios? These stuff are for those who have a deeper understanding of how this currency works and who want to maximize their security acknowledging that there is no third party to assist them if they make a mistake.

And how many people can calculate r and s signature values from K and the private key, by notepad+Windows Calculator? And that's an easier process to do than getting k value from R and S and pubkey.

This stuff is incredibly complex to calculate, even seasoned users sometimes make a mistake and get the wrong result, which leads me to conclude that until we see a dedicated tool specifically for crunching these equations, the only attacks we'll see from finding reused K values are from single groups trying to defraud someone else or another group of people. At least one incident of someone looking for flawed signatures made by a certain wallet to derive their privkeys has already happened.

[Saint-loup]

There is a very good reason why most known wallets don't allow their users to provide their own entropy out of the box. It usually doesn't end very well.

It usually doesn't end very well? Really? Could you share some links of testimonies about that? Because it would be the first time I 'd see someone having lost his funds because he used a physical source of entropy.

On the other hand, we know real cases of entropy generator bugs having led to real losses of funds.

In rare circumstances, certain versions of Android operating system could fail to provide sufficient entropy, and when backup provisions also failed, multiple users could end up generating duplicate addresses.To our knowledge, this bug resulted in one specific address being generated multiple times, leading to a loss of funds for a handful of users.

https://blog.blockchain.com/2015/05/28/android-wallet-security-update/

Applying this test to the output of various pseudorandom sequence generators is interesting. The low-order 8 bits returned by the standard Unix rand() function, for example, yields:
Chi square distribution for 500000 samples is 0.01, and randomly would exceed this value more than 99.99 percent of the times.
While an improved generator [Park & Miller] reports:
Chi square distribution for 500000 samples is 212.53, and randomly would exceed this value 97.53 percent of the times.
Thus, the standard Unix generator (or at least the low-order bytes it returns) is unacceptably non-random, while the improved generator is much better but still sufficiently non-random to cause concern for demanding applications.

https://www.fourmilab.ch/random/

Moreover how could you be sure there is no bug in the current version of the software you are using to generate your seed?

[ranochigo]

It usually doesn't end very well? Really? Could you share some links of testimonies about that? Because it would be the first time I 'd see someone having lost his funds because he used a physical source of entropy.

On the other hand, we know real cases of entropy generator bugs having led to real losses of funds.

Brainwallets are a good example of why user specified entropy is not a good idea. Note that I did state afterwards that it is sufficiently secure if the user knows exactly what he is doing. Rolling 100 dices at once and having the user choose the sequence of numbers also reduces the entropy (think you can find a thread in the hardware wallet section which I discussed this). The fact that there are so many things that can go wrong, and that most users probably doesn't know how to generate it properly can be quite concerning.

If you can be sure to generate the entropy correctly, and also ensure that you're converting the entropy in a secure manner without any sources of entropy leakage, then go ahead.

Perhaps not "usually" but there is definitely a far higher chance. I apologize for my wrong choice of words.

On the other hand, we know real cases of entropy generator bugs having led to real losses of funds.

https://blog.blockchain.com/2015/05/28/android-wallet-security-update/

I consider that poor software implementation, as with how Blockchain.info/.com has always been plagued with. Pushing out an update that includes a faulty RNG is gross incompetence, any changes done to that has to be tested and ensure that the calls are correctly received. That is not their first time with faulty RNG, their signatures were bugged as well. Oh and of course, the fundamental problem is that they were okay with just relying on random.org for entropy, when the internal system fails. For Bitcoin Core, failure to get the CSPRNG from the OS entropy will result in the function failing.

Most codes that requires a high degree of entropy is often hardened with something else, so there is a chance for your survival given a catastrophic failure of several sources, not what Blockchain.info did. Till this day, I still don't understand what is the point of trying to XOR your entropy with data fetched from another site. There is no guarantees that the site is working correctly, the data can be manipulated and you're effectively ONLY relying on securerandom again. So what is the point? If both fails, then you're doomed.

Honestly, I was quite in disbelief when I took a look at their code. Mind you, I was very new to programming (and cryptography) back then but I could identify the possible security risks of implementing something like this.

Moreover how could you be sure there is no bug in the current version of the software you are using to generate your seed?

Read the code. Does it reference the required entropy properly? Those parts that concerns the entropy is often done with loads of scrutiny by far more experienced coders than the average Joe: https://github.com/bitcoin/bitcoin/pull/14955. Several wallets uses multiple sources of data to fold into the entropy, current time, OS version, etc.

Perhaps you can do better than them, but not everyone understands what they're doing; for example:

Oh, I'll roll 50 dices and I'll get an entropy more random than those derived from /dev/random. Proceeds to roll a very biased dice which perhaps lands mostly on 3 sides out of 6 and ending up with less than 128bits of entropy. That isn't very ideal, at all.

[Saint-loup]

Well I understand a little bit more your point. But you are not the "average Joe" as you say and very few people have your skills to be able to spot weak libraries and functions related to entropy generation in software wallets. For the common user it's basically a black box you need to blindly trust. So personally I prefer sticking to known pretty reliable physical sources, even if they are not radioactive like Balthazar's stones 

It's certainly not perfectly random but it's safer than relying on so called "True Random" Number Generators that can be bugged or having design weaknesses, and are actually just trustful blackboxes.

If you wish a guaranteed and independent entropy then you can buy any uranium mineral and use Geuger counter to make as many random bytes as you want.

I tried this and it worked very well.

https://www.youtube.com/watch?v=00h0_Tq8ThA
https://www.youtube.com/watch?v=vtk1o2Qc0u4
https://www.youtube.com/watch?v=pBdqaxtJFHQ
https://www.youtube.com/watch?v=bmK_MVnli7c

My source code is here:

https://github.com/CryptoManiac/rng

It works much faster than flipping the coins and provides a real, guaranteed and unconditioned security.

At least Ian Coleman and Bitaddress conceptors seem to agree with me.

Entropy values must be sourced from a strong source of randomness. This means flipping a fair coin, rolling a fair dice, noise measurements etc.

https://iancoleman.io/bip39/

An important part of creating a Bitcoin wallet is ensuring the random numbers used to create the wallet are truly random. Physical randomness is better than computer generated pseudo-randomness. The easiest way to generate physical randomness is with dice.

https://www.bitaddress.org

[ranochigo]

Well I understand a little bit more your point. But you are not the "average Joe" as you say and very few people have your skills to be able to spot weak libraries and functions related to entropy generation in software wallets. For the common user it's basically a black box you need to blindly trust. So personally I prefer sticking to known pretty reliable physical sources, even if they are not radioactive like Balthazar's stones  

To be fair, when you're converting your entropy to a seed or an address, you're also blindly trusting the script as well. Some of them are mostly unaudited and have certain inadvertent bugs that could reduce entropy. Iancoleman had this with their manual entropy generation. Understanding entropy isn't just about trying to look at a few lines of codes.

Most users don't look at what they run and wouldn't understand the code behind it either, even if it is as simple as trying to generate a seed from a given set of entropy. Most well known wallets are very well audited nowadays and has far more stringent checks in this respect.

If you cannot trust the most simple and important function of the wallet, then there is no reason why you should be using the wallet. Even if you're generating your own entropy, there are still multiple points of failure within that.

At least Ian Coleman and Bitaddress conceptors seem to agree with me.

JavaScript used to have fairly weak CSPRNG and randomness is not guaranteed as the recommendation is just for browsers to implement the correct entropy sources. JS is generally just worse off in terms of cryptographic security.

Sure, you can generate your own entropy. Whether you're able to do it securely and without any loss of security is debatable. If you can do your own due diligence, then sure go ahead. You probably won't get a better entropy than what is used in the various wallets.

There is a reason why major wallets don't allow their users to randomly specify their own entropy.

The best scenario that I can think of is to use multiple sources of entropy and include all of them, dice and your OS random. That way, the theoretical entropy cannot fall below either of the entropy and serves as a good enough fallback. Allowing user to generate their own entropy without being sufficiently educated about it is akin just letting them shoot themselves in the foot.

[BlackHatCoiner]

I've made this discussion with ranochigo, so I won't reply to him, but to Saint-loup. (BTW ranochigo, great content.)

The reason why sites like iancoleman and bitaddress recommend you to use a dice instead of letting your computer generate the random entropy is very simple; the randomness' verification. To cut a long story short, there is no way to verify that the given number from your RNG is generated randomly; theoretically, a malware could affect it and make it return you a supposedly random number, but very known to them. For example, they could return you a hash of a number that is between a, known by them, range. It'd look random, but it wouldn't be. Would there be any way to verify it? Nope.

But, physically you can, indeed, verify that the dices you're seeing return unpredictable results. You're verifying this by yourself. You don't trust your hardware for that particular function.


But, in Bitcoin, your RNG isn't used only in the entropy generation and that's how he justified it to me, along with o_e_l_e_o (including trust for other verifiable functions). Each time you sign a transaction, there is a value in the secp256k1 called “k” which must also be randomly generated. If it's not and someone can predict it, we're falling into another “lump”. Not sure how many software wallets have implemented the RFC 6979, but that's another thing to mind if the wallet you're using hasn't.

Are there any other needs for RNGs in the Bitcoin ecosystem I've forgotten?

[pooya87]

[No need for RNGs. Just hash(message, private_key)]RFC 6979

RFC6979 is more complicated than just simple hash of message+private key though. It is basically a complex key derivation function that can deterministically derive the ephemeral key (k) needed for signing based on the curve you are using, that means the k it produces is always in range and if not it will continue computing in a loop until it is.

[o_e_l_e_o]

But, physically you can, indeed, verify that the dices you're seeing return unpredictable results. You're verifying this by yourself. You don't trust your hardware for that particular function.

You can, but no one (or at least, almost no one) does. As I said above, it's not as simple as rolling your die a few dozen times and seeing that every number comes out close to x/6 times. There are complex statistical tests which you have to run (Chi Squared being probably the most simple one you could do in this scenario), and you will need several hundred trials. Even then, you are only approaching a set confidence limit (say, >95% sure your die is fair), and not 100%. How many people do you think do this before generating physical entropy? How many people do you think are even aware that they should be doing this?

For most people in most circumstances, using a tried and tested wallet to generate their seed phrase is going to be the better option.

Each time you sign a transaction, there is a value in the secp256k1 called “k” which must also be randomly generated.

RFC 6979 generates k deterministically, not randomly. That's why if you sign the same transaction or the same message with the same private key, you will always get the same signature.