@kenCode, I come out of my slumber after having filled about 30 captchas to train some google AI against my will (cloudfart still going strong here on the forum it seems) to express my concern about the latest update.
Hey karnal, sorry for my belated reply here, I don't use this forum anymore, but today I popped in because we have a security related announcement. As you know, we do constant security audits on the code that we produce, as well as code that others have produced. We have a telegram group where we keep everyone updated almost daily, here:
https://t.me/Agorise We have 7 products being released this year and next, including Stealth, so it would be wise to at least follow the pinned items in that group to stay up to date with everything that we produce. There are hundreds of knowledgeable folks in our group chat there.
=====
Update on existing Blinded Tx; Security
As mentioned a couple days ago (in telegram:
https://t.me/Agorise), we discovered somewhat of a glaring oversight in the way Range Proofs are handled in the existing Bitshares CLI WALLET.
It turns out the CLI WALLET’s choice of RP parameters results in proofs that reveal the ORDER OF MAGNITUDE of a transaction amount. In other words: give me ANY "Blinded" balance on the blockchain right now, and if it was put there by the CLI WALLET, I can tell you within a factor of 2 how much is in their balance.
NOTE: Before any panic sets in, we're 99% sure this is a result of mis-use of the ZK library, and NOT an inherent problem with the range-proof algorithm currently implemented on the blockchain.
This means that the new version of the Bitshares-UI that Agorise has produced can fix this, and produce Blinded Transactions that are
really Blinded. (or at minimum, produce uncertainty of amount far greater than a factor of two).
The problem: One of the header fields in the range proof is a count of bits used to represent the mantissa, or the precision part of the blinded value. The cli_wallet uses a "default" value for the "min_bits" parameter, which, instead of specifying how many bits of data we wish to hide, allows the RP code to select the value automatically. The "automatic" value selected is the minimum number of bits needed to represent the value, which gives us immediately the order of magnitude of the value.
We will need to add some logic to choose this parameter a bit more carefully. We’ll need to understand the trade-offs and implications of the parameter choices a bit more thoroughly. The current ZK library is a very flexible one that does allow you to shoot yourself in the foot, apparently.
So, we need to use max bits because the range proof format uses a sort of custom floating-point. But we don't have to necessarily choose the number of bits as a *minimum* needed. We can add a random amount MORE bits, so that the uncertainty becomes a factor of 2^n where n is the max number of bits the client might add to the minimum needed.
We think it's still possible to use a sliding scale, but need to look at what happens to the low-order precision bits when we start using them to create uncertainty in the upper range.
There presumably exist people who have used the CLI wallet to create and transact in Blinded balances. They may be under the impression that their balances are MUCH more private than they actually are. Those people deserve to be made aware of this, hence my post here, and in our telegram group (
https://t.me/Agorise).
BTW, I don't know that this shortcoming isn't already publicly known. It's just the first I've seen it, having not spent infinite hours delving into the forums. In searching the forums, github issue tracker, and google at large, I could find no mention of the range-parameter privacy reveal. To my knowledge, it is not discussed anywhere, and perhaps not known to be a problem.
So, on the bright side, we @ Agorise have discovered another way to make Bitshares an even more secure platform, allowing us to deliver even higher quality products.
We have submitted the technical details to the Bitshares Core Developers, and will hopefully get our fix merged in asap:
https://github.com/bitshares/bitshares-core/issues/480 There is a potential flaw with this algorithm. At the moment that the user stores their balance on the blockchain...
Also, we found a forum post from
@arhag describing a potential vulnerability in which a transaction, should it be rejected by the network for missing an expiration window and need to be re-signed and rebroadcast, could enable determination of the signing keys by a method similar to what was used to break the encryption keys on the PlayStation 3. We're not sure if this has been remedied or not, so we'll try to get to this as well this coming week. It's a very real potential attack vector if it's not addressed.
Ok, back to work now. Feel free to chat with us in our telegram group:
https://t.me/Agorise