Author Topic: STEALTH Status Update  (Read 36240 times)

0 Members and 1 Guest are viewing this topic.

Offline karnal

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

Offline Thom

I have doubts about the amount of time @svk or @abit (and even you arhag) are willing to invest for work on BitShares, when steem is attracting all the attention of the devs. Arhag, you say "Devs are paid for this..." but Kens approach to funding development would probably exclude those people due to their higher pay rate to get them interested, especially considering the opportunity costs associated with not working on steem.

Is it feasible to split true stealth implementation into 2 parts:

part 1: hiding the balance of transactions (i.e. blinded transactions)

part 2: hiding the metadata

If true stealth is the combo of parts 1 & 2, then working on part 1 first is working toward true stealth. Part 1 could be free / paid for by rate limited xanctions, part 2 for those that want / require it is optional and requires additional fees, perhaps to pay for backup storage.

Just thinking out loud here...
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
So why is generating such a key, i.e. an algorithm produced brain key, seen as either inadequate or prohibitively inconvenient?

I don't think it is. I'm not sure anyone really thinks it is either. I think people are mostly just confused about the actual issue.

Apparently I just don't get BM's primary concern about using the blockchain as a storage vault for wallet backups. I know he's now of the belief fees are bad, but stealth has never been a feature designed with "no fees" as a requirement. If backups are essential for making stealth usable safely, then a charging a backup fee proportional to the amount of storage required for it is not unreasonable, just like charging a fee to use stealth was not seen as a bad thing.

I'm not sure what bytemaster's primary concern about using the blockchain for backups is. I'm concerned about poor user experience if keeping your funds secure required backing up a lot of data to the blockchain that you had to pay fees for. There are ways to get around this. First, we distinguish between blinded transfers (hide balances but not metadata) and stealth transfers (hide balances and also to some extent hide metadata). As I outlined in the above post, it is possible to design the client and user experience in such a way that blinded transfers do not require any wallet backups to the blockchain explicitly requested by the user nor does it require unexpected costs. The cost of updating your account private keys may be a tiny bit larger than now in order to upload the encrypted payloads with custom operations as I described in the post above. Even this small cost could be totally transparent to the user with rate-limited free transactions.

Stealth transfers on the other hand may (depending on how they were done) require far more data to be backed up to the blockchain. If we require the user to explicitly back up data to the blockchain and pay a fee to do so after every new stealth transfer receipt, this will lead to very poor user experience. The UX will be much better if the cost of the blockchain upload backup can be accommodated using rate-limited free transactions, but there is a concern of blockchain bloat in that case. That issue can likely be mitigated to a large degree by only uploading necessary deltas to the blockchain and being smart about encoding to reduce the size of the transactions. There would still be concerns that the user may not have enough BTS funds to afford the bandwidth to backup frequently enough to keep up with the stealth transfer receipts, and there are other issues regarding compromising stealth privacy if the client makes backup delta uploads immediately after each time it receives a stealth transfer. These issues all hurt UX and/or privacy and/or risk of losing funds, which makes me think it is best to not spend effort on stealth transfer as they exist now and instead focus on just blinded transfer. If we come up with a metadata privacy protecting stealth transfer mechanism that doesn't have these UX problems and privacy or fund loss risks (that is what I am currently spending some time thinking about), then we could discuss spending money to implement that in the future in addition to blinded transfers (which would likely still remain the default).

If @abit and @svk would be willing to implement this, I will get the funding. I need a realistic timeframe, bid, and at least 3 milestones so that we can monitor the progress, but other than that, I think we all agree that those guys (maybe @arhag could help consult too) are definitely among the best candidates out there for this.
 
Worker proposals are not even an option right now, but if you guys are up for it, I would like to get this rolling asap and get true Stealth finished for Bitshares.
 
Please advise, thank you! :)

Now we are talking! But read what I wrote above for why I think getting true stealth finished for BitShares shouldn't be the initial goal. I think we should get it done as follows (further granularity for milestones is something to be discussed later):
  • First, we build the user interface to get blinded transfers (not stealth) to work. Devs are paid for delivering this. At this point keeping private keys backed up to not lose funds is the job of the user.
  • Second, we build the automatic key backup strategy (mostly what I discussed in the post above) in the client and likely some other offline tools to manage key derivation and account recovery in a secure manner. I can describe this in more detail later. After achieving this milestone, a regular user that uses the GUI client would not have to worry about doing manual backups (other than an initial one) to be able to fully recover all of their funds (and memos). This strategy would also not require third-party servers to manage backups nor would it be cost prohibitive. Devs are paid for delivering this milestone as well.
  • Third, we can then work out the design of a proper stealth transfer feature that doesn't suck in UX or risk user's funds. We can plan out the costs and discuss potentially funding the implementation of the feature.

Also, if you have funds to spare, I think getting rate-limited free transactions to be better integrated into BitShares is way more of a priority than step 3 above if we want good UX.
« Last Edit: April 20, 2016, 05:20:30 am by arhag »

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
If @abit and @svk would be willing to implement this, I will get the funding. I need a realistic timeframe, bid, and at least 3 milestones so that we can monitor the progress, but other than that, I think we all agree that those guys (maybe @arhag could help consult too) are definitely among the best candidates out there for this.
 
Worker proposals are not even an option right now, but if you guys are up for it, I would like to get this rolling asap and get true Stealth finished for Bitshares.
 
Please advise, thank you! :)
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
arhag

Do you have the technical coding ability to push this to a test network?  If not perhaps someone such as Abit could push this to test?  This would make a very worthwhile worker proposal.

I have ideas for how stealth (and also key management and offline signing with cold keys) should be done that I am willing to freely share. Much is what I have already talked about previously. In fact, I will just go ahead and post the beginning part of a draft that I have recently been working on of my thoughts on how to do stealth:
Quote
We need to rethink the way stealth is done so that the UX is better while remaining safe to use.

First, I think the default method of transferring should be with blinded amounts (but not stealth). You could do a public transfer with a click of checkbox if you wanted. Bytemaster has already talked about this. So you can see who is transacting with whom and at what time with which asset, but not the amount. With this method, there are no issues with signaling/communicating receipts and the backup strategy to not lose funds is much simpler. Also, as long as you expose some minimum of your blinded BTS balance, you can still use that minimum towards rate-limited free transactions authored by your account as well as to voting.

Second, stealth needs to be redone. I think the main change needed is to get around the signaling/communication and backup issues while still preserving some privacy of metadata. The idea is to allow the blockchain to know which asset is being transferred to which account, but not from which account. If the blockchain knows the recipient of the transfer of some asset, the user can be assured that they will have access to those funds (assuming the sender put the unblinded values in the encrypted memo properly of course) as long as they can still get access to their account and they have the private key of the memo key published to their account at the time of transfer. To rest user concerns on these requirements, the client could have a limited form of backup anytime the memo key was changed. In the same transaction that changes the memo key, the client would include an custom operation that includes one encrypted payload and an optional second encrypted payload.

The first payload would include the private key of the old memo key. In almost all cases, the client creating a transaction to change the memo key would also have access to the old memo private key. In rare cases where it does not have that information, it would warn the user of that fact and the risk of losing blinded funds. If the user cannot find a way to import that old memo private key and agrees to change the memo key despite the risk of lost funds, the client would instead include the private key of the most recent published memo key it does have. In that case any active balances with blinded values whose blind factor and unblinded amount are stored in a memo encrypted with the memo key that was lost would be inaccessible to the user. This should be a very rare situation. One case might be if an attacker compromised the active authority of the account, changed the memo key, and afterward someone else send a legitimate transfer to the account. Even though the rightful owner of the account could get back control of the account using the offline owner key, they would still lose access to those legitimate transfers that were sent during the time the attacker's unknown memo key was published on the user's account. This first payload would be encrypted using the new memo private key.

The second optional payload would include the private key of the new memo key. If the new memo key was deterministically derived from a seed that was accessible to the hot client in which the seed itself was deterministically derived from a brain key in cold storage, then the second payload would not be included. If the previous conditional is not true, then the second payload would be required to guarantee that the user can recover their funds. If the second payload is required to guaranee fund recovery, then it is important that there exists a single owner key in the owner authority that has a weight greater than or equal to the owner authority threshold. If that is the case, then the second payload would be encrypted using a shared secret derived as follows. The shared secret would be the elliptic curve multiplication of the new memo private key and aforementioned single owner public key. This means the same shared secret could be derived through elliptic curve multiplication of the new memo public key and the private key of the aforementioned single owner key. Thus if the user can somehow generate the private key of that single owner key to take back control of the account, the user's client can also use the information in the blockchain to get the private key of the latest published memo key. And from that, it can use the public blockchain information to get the private keys of all previous memo keys published on that account. These memo keys allow the client to restore the encrypted memos of all transactions from/to that account as well as get access to all blinded balances in transfers from/to that account.

With the backup strategy for both regular blinded transfers and receipts of this new stealth transfer mechanism that I will shortly talk about taken care of, I can now discuss how the new stealth transfer mechanism could work and how it preserves privacy of metadata even though the public always knows the recipient of a stealth transfer which must be an account.

This part of the draft doesn't have much that is new. Ignoring the stealth balance stuff I hint at above which I still haven't thought through fully, the above with a sensible key generation and management solution is basically a design outline for a UX for blinded transfers that allows users to comfortably use the feature without worrying about backups. This is what we should be focused on when we talk about privacy. The extra stealth stuff (hiding metadata) is not as important and if we want to really do it right I believe we need to have services that provide coin mixing (some hard forking blockchain support may or may not be required for that). This approach requires exposing the input to output mapping of the coins you are mixing to the coin mixing host which compromises metadata privacy to the coin mixer only, but even this could be mitigated by using multiple coin mixing hosts who are unlikely to collude.  So the privacy isn't perfect there either, but hopefully it could be a good enough solution that is easier to use.

But what I wrote in the quote above should be possible to do all in the client end with no hard forking changes to the blockchain. As for implementation, it is probably better for someone more familiar with the client code and more willing to dedicate time to implement it, like svk, to do. For later innovations that may require some minor hard forking changes to the blockchain, abit would probably be a good candidate alongside svk for the client side GUI changes. In theory I could spend some time learning the codebase enough to work on it myself, but that would require a serious time investment that I don't think I can give. Unless I get a lot of free time soon (unlikely) to get more familiar with the codebase for fun, I wouldn't be willing to do it unless the cost covered my time to get intimately familiar with the codebase in addition to implementing the features as well. So it makes more economic sense for BitShares stakeholders to pay people who have already put in the effort getting familiar with the codebase like abit, svk, or of course CNX.

And that leads us to the main problem. Funding. People don't work for free. Or if they do, they won't work for free for very long. If we are having trouble keeping workers like basic blockchain and GUI maintenance and documentation in, what chance do we have to pay for a new feature or improving the UX of existing features? That is the general problem. In the specific case of stealth, since STEALTH asset holders get the fees of stealth usage, they should be the ones who try to raise additional funds to fund some of these features/improvements. Although, it isn't that simple either. The UX innovations in the quote above are for blinded transfers. My opinion is that blinded transfers (not stealth) should be the default and use rate-limited free transactions for optimal user experience just like other BitShares transactions hopefully eventually will. In that case, STEALTH holders wouldn't get revenue for blinded transaction usage. So BitShares workers should probably be used to fund the UX improvements/integration for that. It is the other more advanced stealth features (the ones that by their requirement for privacy must use fees because they cannot use rate-limited free transactions without compromising privacy) that can pay fees to the STEALTH asset. And so I think those more advanced stealth features (which would be the more costly one to implement properly) are the ones that STEALTH holders should raise funds to implement. Of course my ideal preference would be for BitShares to just buy out STEALTH so we don't have to deal with this FBA management nonsense. Then BitShares workers would fund all these improvements and BTS would get all the revenue. But again, the problem is funding. The anti-dilution camp is suffocating us.
« Last Edit: April 20, 2016, 06:18:06 am by arhag »

Offline Thom

Quote
If you do not allow the user to set the password but force them to use a key with 256 bits of computer generated entropy that they keep safe locally, then there is no brute force issue.

So why is generating such a key, i.e. an algorithm produced brain key, seen as either inadequate or prohibitively inconvenient?

Seems like a small price to insure the security of one's assets, and why incur the extra cost and ANY extra steps to use stealth if unwilling to accept a safe, secure brain key instead of their own? If using the wallet generated brain key sequence is the ONLY way provided to use stealth, the user has no choice in picking a password. If that insures security what's wrong with that? If the user then ignores the warnings and admonitions about keeping that brain key safe how is that any more a liability than poor practices with the wallet password?

Apparently I just don't get BM's primary concern about using the blockchain as a storage vault for wallet backups. I know he's now of the belief fees are bad, but stealth has never been a feature designed with "no fees" as a requirement. If backups are essential for making stealth usable safely, then a charging a backup fee proportional to the amount of storage required for it is not unreasonable, just like charging a fee to use stealth was not seen as a bad thing.

Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Brekyrself

  • Hero Member
  • *****
  • Posts: 512
    • View Profile
Thanks for taking the time to comment arhag. I'm no expert on cryptography, but it sounds like you and @bytemaster disagree about the viability and security of using the blockchain as the wallet backup medium. My perspective was similar to what you said in your first few sentences above, until BM came along the other week and said the encryption wasn't that safe against brute force methods.

When bytemaster says encryption isn't safe against brute force methods, he is talking about encrypting using a user-chosen password and publishing the (poorly encrypted) data to the public. If you do not allow the user to set the password but force them to use a key with 256 bits of computer generated entropy that they keep safe locally, then there is no brute force issue. It just means recovery is slightly more annoying than typing in your password in a new client. You are forced to get out your paper backup and type in a longer sequence of random dictionary words into the new client.

He explained an important difference was the delays imposed between each guess attempt by front door time outs and other measures which wouldn't exist in a blockchain backup scenario. It makes sense on the surface, but if such measures are so important in the security of the encryption which is the core security mechanism of the entire blockchain, it's far weaker than I thought. Frankly that seems highly unlikely.

So that is in the context where you trust a third-party server with your (poorly encrypted) backups. The server can then enforce rate limits on guessing passwords so that your weak password is good enough to prevent attackers from getting your (poorly encrypted) backup under their local control in the first place to then brute force. The problem with relying on third parties is that the third party may then be liable (at least morally if not legally) if their security is not good enough to prevent others from getting access to your (poorly encrypted) backups. And that isn't the only problem with third-party server backups. You need to trust that the third party won't brute force your poorly encrypted backup themselves. And what is even more of an issue is that if you are solely relying on the third-party server backups to not lose stealth funds (for example), what happens if the third-party company goes under (or loses all their data somehow) and does not or cannot offer you to download your backup even one last time? Unless you had other recent manual backups you might lose some of your funds in that scenario.

arhag

Do you have the technical coding ability to push this to a test network?  If not perhaps someone such as Abit could push this to test?  This would make a very worthwhile worker proposal.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Thanks for taking the time to comment arhag. I'm no expert on cryptography, but it sounds like you and @bytemaster disagree about the viability and security of using the blockchain as the wallet backup medium. My perspective was similar to what you said in your first few sentences above, until BM came along the other week and said the encryption wasn't that safe against brute force methods.

When bytemaster says encryption isn't safe against brute force methods, he is talking about encrypting using a user-chosen password and publishing the (poorly encrypted) data to the public. If you do not allow the user to set the password but force them to use a key with 256 bits of computer generated entropy that they keep safe locally, then there is no brute force issue. It just means recovery is slightly more annoying than typing in your password in a new client. You are forced to get out your paper backup and type in a longer sequence of random dictionary words into the new client.

He explained an important difference was the delays imposed between each guess attempt by front door time outs and other measures which wouldn't exist in a blockchain backup scenario. It makes sense on the surface, but if such measures are so important in the security of the encryption which is the core security mechanism of the entire blockchain, it's far weaker than I thought. Frankly that seems highly unlikely.

So that is in the context where you trust a third-party server with your (poorly encrypted) backups. The server can then enforce rate limits on guessing passwords so that your weak password is good enough to prevent attackers from getting your (poorly encrypted) backup under their local control in the first place to then brute force. The problem with relying on third parties is that the third party may then be liable (at least morally if not legally) if their security is not good enough to prevent others from getting access to your (poorly encrypted) backups. And that isn't the only problem with third-party server backups. You need to trust that the third party won't brute force your poorly encrypted backup themselves. And what is even more of an issue is that if you are solely relying on the third-party server backups to not lose stealth funds (for example), what happens if the third-party company goes under (or loses all their data somehow) and does not or cannot offer you to download your backup even one last time? Unless you had other recent manual backups you might lose some of your funds in that scenario.
« Last Edit: April 20, 2016, 03:33:54 am by arhag »

Offline Thom

Thoughts anyone?

I think you over-complicating it for little benefit. You can backup whatever you want to the blockchain (if it is cost effective that is) with encryption that cannot be brute forced (anymore than they can brute force the private key of your public keys). The client just needs to make sure that the key used for the encryption is derived from a 256-bit randomly generated seed. I would have an IDENTITY_SEED which is a randomly generated 256-bit number represented in the form of a sequence of dictionary words that you backup and keep somewhere safe (paper backup and flash drive stored in multiple safe locations). The IDENTITY_SEED plus an optional passphrase (that you must be able to remember if you choose to use it) is used to ultimately derive all the relevant keys (owner keys, active keys, blockchain backup keys, etc.). Most keys would ideally be deterministically derived using simple incrementing indices so that recovery is trivial and doesn't bloat the blockchain with many backups of new keys. For those keys that are non-deterministic, the client would back it up to the blockchain after encrypting the payload using locally stored private keys that have full 256 bits of entropy (and are deterministically derived from IDENTITY_SEED). Then restoring from scratch becomes possible as long as the user can retrieve their IDENTITY_SEED.

Thanks for taking the time to comment arhag. I'm no expert on cryptography, but it sounds like you and @bytemaster disagree about the viability and security of using the blockchain as the wallet backup medium. My perspective was similar to what you said in your first few sentences above, until BM came along the other week and said the encryption wasn't that safe against brute force methods. That was very surprising to hear actually. He explained an important difference was the delays imposed between each guess attempt by front door time outs and other measures which wouldn't exist in a blockchain backup scenario. It makes sense on the surface, but if such measures are so important in the security of the encryption which is the core security mechanism of the entire blockchain, it's far weaker than I thought. Frankly that seems highly unlikely.

Perhaps I misunderstood the weakness BM was concerned with. Perhaps it primarily rests on the identity_seed. No encryption is worth its LSBit if the encryption key used to generate the pub / priv pairs is weak. That is ALWAYS an issue, that can never be avoided. It's a fundamental concern, however decentralized wallets on computers everywhere are not readily accessible and thus are not subject to direct, repeated trials of potential key guesses to unlock the wallet. That changes when the wallet is on a public blockchain, thus my "elaborate" scheme to A) obfuscate the account owner of the wallet with the backup and B) to decentralize the backup data to prevent direct access to it.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Thoughts anyone?

I think you over-complicating it for little benefit. You can backup whatever you want to the blockchain (if it is cost effective that is) with encryption that cannot be brute forced (anymore than they can brute force the private key of your public keys). The client just needs to make sure that the key used for the encryption is derived from a 256-bit randomly generated seed. I would have an IDENTITY_SEED which is a randomly generated 256-bit number represented in the form of a sequence of dictionary words that you backup and keep somewhere safe (paper backup and flash drive stored in multiple safe locations). The IDENTITY_SEED plus an optional passphrase (that you must be able to remember if you choose to use it) is used to ultimately derive all the relevant keys (owner keys, active keys, blockchain backup keys, etc.). Most keys would ideally be deterministically derived using simple incrementing indices so that recovery is trivial and doesn't bloat the blockchain with many backups of new keys. For those keys that are non-deterministic, the client would back it up to the blockchain after encrypting the payload using locally stored private keys that have full 256 bits of entropy (and are deterministically derived from IDENTITY_SEED). Then restoring from scratch becomes possible as long as the user can retrieve their IDENTITY_SEED.
« Last Edit: April 19, 2016, 11:02:51 pm by arhag »

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
Making transactions default blinded sounds like a great idea, IMO. Currently I think transactions are a little "too public".

Oh what, you mean how every time a whale transfers any BTS to poloniex, it gets posted about in these forums?

I didnt notice that. :P
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Thom

The primary reason BM believes backups on the blockchain are problematic is it allows direct access to a wallet for the purpose of brute force password cracking. Unless the wallet backup is disassociated from the account it is for hackers will be able to locate wallet backups of interest on the blockchain (the wallets associated with large account balances), obtain a copy of it and hammer it with concentrated, distributed CPU power to brute force hack the key / password to unlock it. That's what I took away from BM's discussion about stealth in the mumble the other day. The lessor point he raised is using Storj or IPFS will cost something, it won't be free, which will have a negative impact on the adoption of stealth. External storage also opens up a dependency outside the control of the BitShares ecosystem, and may well incur significant development costs to integrate with our stealth code, at least it's a possibility.

The association between the account and the backup is what needs to be obfuscated, and it seems like there ought to be a way to do that. The wallet backup could be split into small pieces and distributed as chunks in encrypted memo fields as Ken originally suggested, but with additional security as I'll explain. Also, as the number of these wallet backup chunks increase the harder it is to assemble all the right pieces back together for a specific wallet.

The encryption for each chunk would be separate so cracking one doesn't allow you to crack them all, and even after all the backup segments are reassembled, the wallet backup itself requires another separate key to unlock it. If each of these levels is like sha256 or sha512 encryption, each of which must be cracked to get to the next, doesn't that multiply the effort required to gain access to the wallet? Each chunk could contain the location (but not the key's to decrypt) the next chunk on the blockchain, in a kind of inner nested blockchain comprised of these encrypted memo fields. The advantage to this approach is it avoids the cost and risk of using external storage. The downside is the additional space and storage overhead it imposes on the BitShares blockchain.

The devil is in the details of a scheme like this, particularly in how the association is managed in a way that only the wallet owner can know. Ultimately it comes down to a secret the wallet owner must create strong enough, or, if created by algorithm and provided to the wallet owner they must remember and keep secure. So does that not bring us back full circle to the initial problem? If so I don't think any implementation can get around that.

Thoughts anyone?
« Last Edit: April 19, 2016, 02:54:23 pm by Thom »
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline Musewhale

  • Hero Member
  • *****
  • Posts: 2881
  • 丑,实在是太丑了 !
    • View Profile
great!
good idea!
i like this!
just do it!
 +5% +5% +5%
MUSE witness:mygoodfriend     vote for me

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
@kenCode is that regarding the light client or the mobile app?

stealth is not in the mobile apps.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline karnal

  • Hero Member
  • *****
  • Posts: 1068
    • View Profile
@kenCode is that regarding the light client or the mobile app?