Topic: [WARNING] Wallets created with Libbitcoin Explorer (bx) are insecure! (Read 817 times)

For most PRNGs it is not too hard to determine the seed just from seeing the output and often the seed is big enough to avoid finding it by guessing.  For a CSPRNG you cannot find the seed from the output (because the derivation function is cryptographic) or by guessing (because the state space is too big).  This makes all the difference in the world.

There are but they're kinda dangerous.  The issue is that it's often easy for a hardware RNG to fail in a way that makes it still look random but in reality it is somewhat predictable to an attacker.  The best way to use one is to take a lot of output from one, feed it to an expensive cryptographic hash, and use the output as a seed to a CSPRNG.  if its done this way then the result will be secure so long as there was enough randomness anywhere in the data to get the CSPRNG securely seeded.

If you want to be paranoid, after starting up that CSPRNG, get randomness by xoring the CSPRNG and the hardware RNG.  So then the result is secure if either the initial seeding and CSPRNG is good enough or the hardware stream is good enough.

Not an expert in this field but from what I have read about PRNGs is that they are some sort of state machine which is seeded by some initial value, usually called a seed value. This seed value determines all future pseudo-random values that the PRNG generates based on some suitable algorithm. Same seed for the PRNG generates the same future pseudo-random number series. Therefore it is crucial to input good entropy as seed to a PRNG. Here Libbitcoin failed completely with known results.

The algorithm which generates the pseudo-random values of a PRNG should ideally have a very large periodicity and numbers generated should be evenly distributed without a bias. There has been a lot of research in this area for apparent reasons and this also determines the "quality" of a PRNG.

TL;DR Every PRNG is to my knowledge deterministic. If you know or can predict or guess the seed, you know all future pseudo-random numbers a PRNG will output. I believe this also applies to CSPRNG, but I would've to dig deeper what distinguishes a CSPRNG from a PRNG.

Never attribute something to malfeasance when it can be attributed to incompetence.
I don't think they are leaving holes in because they want to, a lot of security people even agree with me on that.

They are trying to put so much in so quickly, there is exactly 0 possibility to do all the QC needed.

One engineer lecturer said it the best. Between final tape out and production to do a full attack vector scan on something as complex as a modern processor is probably going to take 18 months. Meanwhile your competition did not bother doing that and are now 1 1/2 to 2 generations ahead of you.

Which brings us back to this. People are lazy and want it yesterday and make it quick and simple and make sure everything is perfect.
Should this code have been used. No. Should people have looked deeper. Yes. Did anyone? Well, we know the answer to that.

The more things change, the more they stay the same.

Something I have posted a few times over the years about bad chip design from decades and decades ago:


The last one takes the cake, you can make a programming mistake and damage your chip. Say what? Not overclocking, not over powering, just try to do a blank with using DMA and oops *poof*. Yet, that made it out the door.

-Dave

Don't worry, Sandy Bridge has it's own bugs and flaws, and if you apply all fixes they slow down processor speed a lot  

Sorry but you are wrong about this.
Do better research what TRUE RNG is and how it can be generated, I won't go offtopic with that anymore.

It's not that vague or hard at all... just roll casino dices enough time and you have it, and something similar can be done with hardware devices.
If something can easily be repeated and reproduced than it's not really random.

I know, and they are doing it on purpose (probably)  

Reminds me, wasn't there someone that stole a few thousand BTC a litttle less than a decade ago from Primedice that way? Fuzzy memory, but I thought they read-out the current output of "random" numbers and with this information were able to determine the seed that was used to generate these numbers. With the seed they could then predict the upcoming outputs from the RNG.

Also, aren't there Hardware-RNGs - Pokerstars for example claims/claimed to have one in use to "shuffle" their virtual cards. I think it uses radioactive decay to create this kind of true randomness.

Edit, did a little research, seems they use a LASER beam - my guess is it's actually a quantum effect, nothing to do with radioactive decay. (?)
Not too much real info here, but still entertaining: https://www.youtube.com/watch?v=-DkHzOUzDjc

Nah, Intel has been screwing up for decades. https://en.wikipedia.org/wiki/Pentium_FDIV_bug
Different world back then, but still the same problems. Big glaring issues with people trying to figure out how it made it past testing.



I do (did) have funds in cake. Finally moved them out last night. It was a non trivial amount but not enough to loose sleep over if they vanished.
But I do know several other people using it and they had no issues either. Wonder how vulnerable it really was.

I only had 2 alts in there and only only because it was the easiest one to deal with when someone wanted to pay me with an alt and it was the 1st one that looked decent. And then when someone else wanted to pay with an alt it wound up in there too.

Makes you wonder if cake is legit vulnerable how many people have some funds sitting in it for years like I did, and were planning to move them out soon. And just never did.

-Dave

you can recover the MT state from the output even if the seed is big and random.  But it takes a lot of output and bx seed only outputs a single thing then quits.

So MT with secure seeding would probably be okay in bx seed (though fishy smelling), but wouldn't be okay in some other contexts.

Personally I'd never use MT for anything these days. There are alternatives that are much faster and have better properties, even where security isn't an issue.  It's a buzzword PRNG because it came into existence a time when people were using a lot of stuff that sucked a lot worse (and maybe because it has a cool name).

Thanks for clarifying. My understanding is indeed that MT is a not CSPRNG, as it will always deterministically produce fixed numbers, but that with enough bits in the seed it is practically impossible to detect the pattern. The problem with Libbit pin is exactely the low entropy in the seed.

That might create an unhelpful equivalence.

There are CSPRNG  -- cryptographically secure pseudorandom number generators.  Once you feed in enough (say 256 bits) of genuine randomness they run deterministically and spout out as much random numbers as you want, which are generally just as good as new random values-- arguably better in that you're not exposed to a hardware trng flaking out or being slow.  Their main downside is that their state is a secret you have to protect.

Then there are non-CS PRNGs, like mersenne twister.   The output from those shouldn't be used for security relevant purposes because attackers can predict them from seeing some earlier output (or sometimes without seeing any output at all, for really bad ones).

Since bx seed just outputs a random value and quits the fact that it used MT itself wasn't really a problem, if it were seeded with enough cryptographically strong randomness the MT wouldn't have caused a practical harm in the context of bx seed.  It's the use of a 32-bits of seeding and that it came from the time rather than a source which had any chance of being secure.

Not really on modern computers-- they're equipped with a hardware TRNG.  And even without them computers with a user sitting at them have pretty good sources of timing randomness-- from keypress timings and mouse movements which the operating system records--  older hardware with no TRNG and computers with no local user are a more difficult matter.

There is nothing random in Marsenne Twister. If you feed it the same seed, you will always get the same output.
True randomness for a computer is extremely difficult and a really vague concept.

Looks like it only affects intel core 6th to 11th gen, so at least my Sandy Bridge server is not affected


A true RNG uses numbers that are created from noise entropy like from your mouse, keyboard, disk. The kernel collects the inputs and turns them into bits of entropy, which can then be read out by a true RNG function call. But if your algorithm is just generating numbers from a seed and state machine which is updated by previous numbers, then that is not secure at all.

It's really obvious in the code to anyone who reads it:

https://github.com/libbitcoin/libbitcoin-system/pull/559/commits/6d5a06e283d81260165e0eab95175069bf03b408#diff-e212c578b1951f97c871396a74c4224de9182ed922c8a95db56f995951743d17R42


        return static_cast(now.time_since_epoch().count());
        ...
        // Seed with high resolution clock.
        twister.reset(new std::mt19937(get_clock_seed()));


It says directly that it's seeded with 32 bits of a high resolution clock.

Your comment conflates two concepts:

A deterministic wallet is one that can be backed up. Without determinism your backup is invalid as soon as you send funds or generate a new address, and that is obviously pretty unsafe and impractical.  A wallet using determinism works the same as one that doesn't except backups actually work.  It's possible to footgun yourself due to backups working, but I think backups not working is a much bigger footgun as it is highly surprising.  And one should be careful to not emphasize protection against theft over protection against loss:  at the end of the day if your coins are gone they're gone and it doesn't matter if they were stolen or if you just lost them another way.  Prior to determinism wallets would contain a small buffer of pre-generated keys, which didn't make backups actually safe but made their failure modes rather weird and inexplicable.

Users handling "seeds" (or private keying material) directly, as they're forced to if they use bx explorer, is obviously dangerous even for experts (as *every* user of bx seed must have been to some extent), and that isn't anything I proposed and I've also generally cautioned against. (In fact, BIP-39 has a warning against its use written by me on its comments page, in fact.).  Sometimes the two concepts get treated as one because if every key is randomly generated then manually handling the individual keys would be very clunky and inconvenient, so any kind of user handled seed scheme will in practice also be a deterministic wallet scheme both because of that practicality and because every wallet today is (because backups exploding is not desirable!).

While I worked on Bitcoin Core it didn't implement any user handled "seed" functionality because of how error prone it is.  (Though arguably if it did some of the people who used bx seed would have been saved: had bitcoin core had this functionality it would have been reviewed and implemented correctly...)

In this case BX's only function for generating keying material was insecure, this meant any keys generated using it (be they bare private keys or BIP39 seeds) were insecure -- so I don't think you can say that determinism OR 'seeds' were particularly relevant to the risk here.

I am wondering, what is an insecure key, what does it look like, and were these compromised keys easier than our 1000 bitcoin puzzle keys?  They had to know something, was there any hint in the code itself telling you what to look for?

I wouldn't trust any wallet, open source/ closed source, reviewed by all the experts or not, you just need to flip a coin to be safe.  In general I consider deterministic wallets/ seeds a vulnerability, gmaxwell was the first dev coming up with this idea right? It's only good and safe if you know what you are doing.   Bitcoin is only good to keep if you know what you are doing, that's the reason why masses don't rush into it, because it takes time and effort to learn how to do things.

You're confusing issues.

Libbitcoin explorer was only using 32-bit timestamps to generate keys via its 'bx seed' command.

The downfall thing is an issue on some processors where if you run malicious code on a processor it can steal parts of memory from other processes.  As you note, it's a concern for shared systems like cloud deployments.  But cloud deployments have MANY serious problems and downfall is only the latest in a long series of similar issues.   Certainly a concern but far far far less of a risk than just using 32-bits to generate keys.

I saw this news few days ago, and it's not only the problem with Libbitcoin Explorer but with all devices with Intel processors.
Everyone who is using computers and laptops with Intel processor should consider their devices as not secure anymore, and I wouldn't use them as my main cold storage.
Call me conspiracy realists, but I think this flaws were intentionally there from start and they are coming from inside Intel, but AMD is probably doing something similar.

Downfall Attacks is affecting billions of modern processors and cloud computers, and this is even more dangerous:
https://downfall.page/

Anyone keeping sensitive information in cloud at this point is playing russian roulette right now.  

I don't think this is a true random generator, but I could be wrong.
This is much bigger topic and there is a big difference between pseudo-random and random number generation.

So you're basically saying that a weak random number generator such as Mersenne Twister was used for generating seed phrase entropy in Cake Wallet and Trust wallet? (!)

These projects are totally screwed. How can you use such a basic pseudorandom number generator for generating something that will store people's life savings?

Until it reaches at least $1 million, it won't appear in the mainstream media, and maybe not even then, considering that such things have become quite common in the world of cryptocurrencies. All this that is happening is just proof that no matter how safe something seems, we should always question whether there is a loophole in the system that hackers will use sooner or later.


I even have some dust in the Trust wallet, although I don't see that this altcoin is currently in danger, and even if it is, I'm somehow too lazy to send it to another wallet. I guess I apply to myself that unwritten rule "invest (or in this case save) only as much as you are ready to lose"

CoinDesk also takes up the topic again in an article: Disappearance of $900K Puts Focus on Vintage Bitcoin Project Libbitcoin


Source: Disappearance of $900K Puts Focus on Vintage Bitcoin Project Libbitcoin

According to the security firm Distrust, at least ~$900k was stolen on multiple chains.

Similar problems were also found with the two well-known multi-coin wallets Cake Wallet and Binance's Trust Wallet. Especially Trust Wallet in particular is likely to be used by many forum members due to its aggressive marketing by Binance. Another reason to withdraw your coins from any Binance product.

As John Wick would say, "Everything has a price."

Yes.

Cannot is a little strong, but it would be slightly surprising.  OTOH, it would be less surprising than the original error in libbitcoin explorer itself.

I could imagine some web service wallet thing using it on the backend but it would be an odd choice... or managing to copy the vulnerable code into other software though there was nothing subtle about it.