Author Topic: STEALTH Status Update  (Read 36241 times)

0 Members and 1 Guest are viewing this topic.

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
@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
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline karnal

  • Hero Member
  • *****
  • Posts: 1068
    • View Profile
If someone is in contact with @kenCode through other channels, I believe his input to the points I raised a couple of weeks ago would be very relevant.

Offline oxarbitrage

@diablo4 as far as i know the blockpay repos were and are private so i don't think you will be able to see them in ken public github. as far as i know ken is/was a project manager so the number of commits he did or do are actually of no interest. in regards to @bilthon he haves an account here, i have his skype, he is probably dedicating to other projects after bitshares munich issues but i don't think he is an unidentifiable bogus or scammer.

scammers or not this is a thread to discuss STEALTH, not blockpay so i will be definitely more interested on @karnal concerns to some technical and planning issues than on this.

Offline lexamckenzie

  • Newbie
  • *
  • Posts: 13
    • View Profile
I don't get it...
Can you please elaborate it?

Offline diablo4

  • Newbie
  • *
  • Posts: 3
    • View Profile
total scam:

https://github.com/kenCode-de?tab=repositories

Most repositories have nothing to do with Blockpay, and no contribution from Blockpay "devs". At some time they were talking about c-ipfs being developed and needed (Christoph in the podcast).

https://github.com/Agorise/c-ipfs/graphs/contributors

c-ipfs is from developers totally unrelated to Blockpay...

Ken's only commit for the smartcoin-wallet:

https://github.com/kenCode-de/smartcoins-wallet/commit/5c6976d3c20a34879820b3ebffff9f7d0960d64e

...it is as well from real devs unrelated to Blockpay.

Blockpay "s" is more or less the same as the smartcoin-wallet, and only one commit from Ken

https://github.com/kenCode-de/blockpay-s/graphs/contributors

there appears an unidentifiable bogus dev from Peru:

https://github.com/bilthon

...Christoph was presenting all this crap

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav

Offline diablo4

  • Newbie
  • *
  • Posts: 3
    • View Profile

I'll show you what the scammers manipulate.

   
   id 1.11.70875024   
kencode sent 304,129 BTS to indominon
2 days ago

   id 1.11.70926108   
indominon sent 103,000 BTS to disperse
yesterday

       id 1.11.71352574   
indominon sent 104,490 BTS to disperse
16 minutes ago

   id 1.11.71352992   
disperse bought 89.82 STEALTH at 250.00 BTS/STEALTH
12 minutes ago

onceuponatime bought 22,500 BTS at 250.00 BTS/STEALTH
12 minutes ago


indominon = onceuponatime = disperse

Get out of the world in Bitshares !!!

Offline karnal

  • Hero Member
  • *****
  • Posts: 1068
    • View Profile
@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.

It appears to me that having considered libsnark at all, given it's need for a trusted setup a la zcash (endless source of rumors, contention and distrust, wasn't the idea trusting less parties, not more?) was a grave mistake. Unless something has changed in the last few months, libsnark is horribly slow too.

But perhaps even more concerning is that so late in the game your team is still, if I got the gist right, wondering which cryptographic fundamentals to use for the system.

Cryptography isn't "just math", it's some of the most complex maths around, very hard to get right, and few who attempt to "do their own math" ever get it right.

This uncertainty about at least 3 cryptographic options leads me to believe that the architecture of this feature has not been very well thought at all. Contrast with Monero for instance, where there has always been a clear roadmap, an understanding of the limitations of the present evolution of the system, and a precise and targeted plan to address them.

So that's one aspect of it where I would like your clarifications if possible.

Something else I'd like to bring us, is clarification on the following points:

Quote from: kenCode
We're also doing our own coin tumbling and extra layer of coin/address mixing and if all goes as planned (...)

1. Why is any extra tumbling necessary?
2. How would it work?

Quote from: kenCode
(...) we should be able to keep almost all of it on-chain.

Who is "we", what is "it", and why and how some of "it" would have to go off-chain ?

Quote from: kenCode
C-IPFS is mostly ready now for the automated backups too:

1. Can C-IPFS be made to work with a tor transparent proxy?
2. Why is there a necessity to backup extra information? No other coin that I know of has this requirement (most notably, Monero).
3. Cryptographically, how is the backup protected?
4. Does a compromise of the backup result in compromise of funds without the wallet password?


As usual, forgive my bluntness, I don't mean to devalue the ongoing work that you & your team put into bitshares, nor do I question your dedication. Perhaps I should have said something earlier (months ago) when I first read about libsnark and c-ipfs, but as they say, better late than never.

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
Testnet is running, UI is mostly done (for Normal/Blinded/Stealth options), so I will open the testnet up to the public in a week or two. The accounts and contacts screen is coming along this week. The UI that facilitates the backups will come in a few weeks, for now I want to get the public to our testnet asap so the testing/auditing/hacking/wiresharking can begin. I dumped the slow, unscalable zcash/libsnark stuff in favor of Blockstream's slightly faster CA code, but we might even be able to dump that and do our own math. Looking into that some more right now.
 
Thom brought up some really important legal points about using their CA code, you never know what that company may do in the future, so it's best if we can avoid use of their CA code if possible. Hiding the asset that was sent is not really that big of a deal, it's just math. ;) Same thing goes for the balances and metadata. We're also doing our own coin tumbling and extra layer of coin/address mixing and if all goes as planned, we should be able to keep almost all of it on-chain.
 
C-IPFS is mostly ready now for the automated backups too:
https://github.com/Agorise?tab=repositories
 
I don't use this forum much anymore, so to follow the Stealth status, and the additional products I'm launching, it's best to hook up with us in the telegram group:
http://t.me/Agorise
or steemit:
http://steemit.com/@kenCode
 
Hope to see you guys there! :)
Peace, Love, and Agorism.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline moinyoin

can follow on https://steemit.com/@kenCode

I think also now working on Agorise

Offline oco101

  • Hero Member
  • *****
  • Posts: 586
    • View Profile
Thanks. Is this forum losing to steem? Do most BTS users post there now?
[/quote

Not to steeam but most of the discussions happen on Bitshare Telegram now.

Offline Bitshiz

  • Jr. Member
  • **
  • Posts: 37
    • View Profile
Thanks. Is this forum losing to steem? Do most BTS users post there now?

Offline Brekyrself

  • Hero Member
  • *****
  • Posts: 512
    • View Profile
BitShares Munich has been working on it.  Keep an eye here for updates: https://steemit.com/@kenCode

Offline Bitshiz

  • Jr. Member
  • **
  • Posts: 37
    • View Profile
What is the present status of this, and is there an ETA for completion?

Did the stealth feature ever get finished?
I guess not.

Offline Bitshiz

  • Jr. Member
  • **
  • Posts: 37
    • View Profile
What is the present status of this, and is there an ETA for completion?

Did the stealth feature ever get finished?