Topic: getting Bech32 address on paper wallet (Read 451 times)

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.

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.

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.

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?

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.

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.

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 



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

https://iancoleman.io/bip39/

https://www.bitaddress.org

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.

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

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.

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

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?

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.

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.

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]*

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

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.

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.

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.

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.

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.

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.

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

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?

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

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.

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

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.

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.

You cannot verify how random your results are. You can only verify that you generated the results and that you are trusting that the way you've executed it is free of any critical mistakes that could influence the entropy.

Yes, as for my dice rolling is the faith that my dice is not biased (perfect CG) and that I'm not throwing them in a way that makes it biased. As I've said, most Bitcoin wallets collects data from multiple sources to try to prevent a single source from ruining the randomness of your keys. Core in particular uses urandom, rdrand, CPU cycles, OpenSSL, etc. Compromising every source of entropy constitutes a complete compromise of either your OS or wallet as well. To which, at this point you shouldn't be using them.

You can of course, XOR your own entropy in addition to those given by your OS. The way the wallets do this is by including multiple sources of data.

Yes, this is correct, but you also have to worry about these with or without the dice roll. If you chose to generate your seed using your RNG, besides with the randomness' compromisation you would also have to worry about the keys' validation etc. The physical and completely unpredictable selection of bits that can be verified skips the RNG compromisation part.

But, you aren't trusting only those, this is the problem; you have to also trust the unverifiable randomness used for the generation of a number directly from your OS. It means that you have to trust every third-party involved in the process of the computer's building.

I couldn't agree more, proper dealing with and holding of Bitcoin safely and securely comes with security etiquette, bitcoin safely wallet generation and usage also comes with security etiquette, airgapped device totally free of malware like newly installed Ubuntu which acertain no malware with no external connection irrespective of throwing dice for entropy generation or generating it or seed phrase using tools like Iancoleman. Just my opinion to total safety.

If you cannot trust the integrity of your offline system, then you actually might have more things to worry about; the signature for the transaction it generates, whether it is generating the correct keys, etc. No one AFAIK has been attacked by someone compromising their RNG so far, because it is usually hardened. If you don't trust the OS, then the best way is to try to obtain the best source of entropy (radioactive decay, etc) and calculate everything by hand.

You cannot verify entropy. The 100 rolls, or however many rolls is usually insufficient to build a model to show that it has zero bias (or with the numbers evenly distributed). Most wallets includes various other variables to try to reduce their dependency on a single source within the OS. 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.

I would probably trust the group of people that made Bitcoin Core and the Linux Kernel than myself. Might just be me though.

Of course, as I've said. If you've got any idea of what you're dealing with and accept the possible accompanying risks, then there's no problem.

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. (or that it'll be formatted right after the generation)

Rolling a dice is randomly verifiable in contrast with an RNG. The sufficient entropy you've mentioned that is provided from my kernel isn't verifiable or at least, not same like with dice.

I believe paranoia comes with large amounts. Wouldn't you roll the dice properly instead if you had 1000 BTC?

If there is a malware infection, using your own entropy won't matter. They just wouldn't attack your entropy.

Your computer's randomness is crucial for many of its function and the kernel provides for and gathers sufficient entropy through several environmental sources. Generating your own entropy through your own methods can introduce potential weakness through inherent weaknesses that are associated with various actions or objects; imperfect dice, throwing techniques, etc. These can make for entropy that are perceived to be enough but infact would provide lesser entropy than that generated with your computer's randomness. Certain wallets also include additional entropy sources as a fallback.

I would only do this provided that the user actually understands how this works and to ensure unpredictability in the results. If not, then using a well-known and tested programs would be far better for most purposes. If you're paranoid and understand what you're doing, then yeah it is doable.

No and you can't verify it somehow. Generally, generating random numbers using javascript through a web browser isn't recommended. Once you want to keep your funds safe, you have to ensure that nothing malicious has being involved in the process of the entropy's generation. Theoretically, a malware/virus could affect your computer's RNG and return you results that may seed random, but they're not.

I'd advice you to use tangible and physical things whose randomness could be verified like a coin's or even better (for your time), a dice's.

Take a look: [Open Source] Coin Flipped Seed (coin flip, dice roll, rubik's cube mixing)

Even better than that - don't have a hard drive to begin with. Take an old computer, remove any WiFi cards or other connectivity hardware, remove any hard drives or other storage devices, and then boot from a live OS on a CD or USB drive which are write protected. Use that live session to generate your seed phrase or private keys to write down on paper and your addresses to receive to, and then just power off. Within a few minutes to an hour or so, depending on your RAM and its physical environment, all traces of your data will be gone.

If you don't want to do that and want to have some persistent storage on your airgapped device (such as for using a cold wallet), then use full disk encryption on its hard drive. It doesn't matter so much if you leave behind traces of your seed phrase or private keys on a hard drive if the entire thing is encrypted and an attacker can't decrypt the data.

Hmm, okay that I didn't know. I always thought bitaddress was using a browser CSPRNG (not math.random()) for the entropy. Mouse movement and the other variables should serve as a complement to the original entropy and shouldn't be overly-reliant on that.

Anyhow, I think this proves my point that generating addresses in browser is inherently insecure.

It isn't.

Javascript-based generation is notorious for being subpar as compared to your normal wallets. Having to rely on your browser to correctly communicate with the OS CSPRNG with no assurance isn't very good if you need to ensure that your generation involves enough entropy. JS cryptography modules aren't very well implemented or audited either, there has been cases where users have lost funds due to poor implementation by the developers or just from the limitation of javascript. I wouldn't bother running JS sites, offline or not. The fact that you'll have to trust put your trust in so many different components and have no assurance of whether it would be working perfectly is quite dangerous.

Consider just using a normal desktop wallet for generation instead.

When you delete some data from your computer, it's not that they disappear completely once they are deleted. The deleted data exists on your hard drive until some new data replace them.
By deleting a file from your computer, you actually tell your operating system that "I don't need this file anymore. Please don't display it. You are allowed to replace it with new data in future."
That's why there are some tools for recovering permanently deleted files. The deleted data can be accessed by a malware as long as they have not been replaced by new data.

Therefore, for generating a wallet, I would use a computer that has never been online and will never be online. It's not enough to delete files. Formatting the hard drive (as suggested by you) can be a good idea too.

I agree, especially if the person wants to be making use of the cold generated wallet on the airgapped device for signing, this means the airgapped wallet should remain airgapped for safety. I have even recently learned that it is best on newly installed computer OS like Ubuntu in which any online connections are disabled. But, according to OP, he only wants to generate it as a paper wallet, which means having proper backup of the seed phrase is enough, deleting the wallet after it has been created will be fine and used as a paper wallet.

But what I am concerned about now is that, is it good to format the computer again after the wallet generation and reinstall back the OS, or just deleting the wallet on the device is enough. Although, I will go for the former.

By disconnecting your computer from internet when generating addresses, you don't really make your wallet more secure.
It is recommended to generate addresses on an air-gapped computer. This means that you should use a computer that has always been offline and will never be online in future.

I have heard that bitaddress.org generated address was crackable but not anymore now.

It is open source and following the BIP39 standard for seed phrase generation and also generating the seed safely if provided you run it in a safe environment by runing it on an airgapped device and also making use of its utml source.

Yes, but if you are not convenient with that, you can make use of your own entropy by throwing a coin up 256 times, upside as 1 and downside as 0 or vice versa.

It depends on the source you used to generate the private key and address, if it is https://bitaddress.org, it is safe, but I can only guarantee safety if done offline especially using its source on an airgapped device. The fee for legacy addresses are higher than segwit, but not that you want to be using it for frequent transactions.

---

You can even still run Electrum on airgapped device which will generate you segwit wallet by default. You can use this guide for its download and signature verification.

As an alternative, if you don't need to generate many Segwit addresses then you can use this one below to generate a single (Bench32)address.

- https://coinb.in/#newSegWit

For safety to P2PKH addresses always generate them on offline PC. So, download the page of iancoleman tool or the coinb.in tool and disconnect the PC before you generate any address you want from those tools.


As of now, I never heard any issue with using iancoleman tool so I think it's safe the same goes for bitaddress.org

Thanks for your reply.

I will try to use those addresses from now

I am also wondering if ian coleman Mnemonic Code Converter is the best tool as a browser based way to generate offline word seeds and all private, public keys and address?

is it really 100% secure in terms of randomness of the word seeds?

I also have some BTC on paper wallet generated on bitaddress.org (offline). is it at risk?

thanks

If I understood right your problem, all you need is to click the BIP84 tab in Ian Coleman generator.


Yes. Nothing has change on that matter.

Hello,

I have used for 1 year the ian coleman Mnemonic Code Converter (https://iancoleman.io/bip39/) to manage my BTC

However I would like to generate  Bech32 address for efficiency with my wallet (thanks to words mnemonic).

Is there a way to do so with ian coleman Mnemonic Code Converter or other ?

Is it safe to keep BTC on P2PKH address?

thanks