Author Topic: STEALTH Status Update  (Read 36232 times)

0 Members and 1 Guest are viewing this topic.

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

The above attack happened to me on a NXT blockchain when I decided to ignore the security recommendation while testing something. It is quite epic to see your account hacked within seconds. Literally. Thinking about it, it seems like perhaps that was bad programming on their part. (I'm not suggesting NXT still has this issue. I have no clue.)

I was aware of salting, but didn't realize it could be stored publicly along with the hash.  +5% for teaching me stuff.
I speak for myself and only myself.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.

It is worse than #1. They can store the hashes and then clear out any account that goes forward and uses that hash. With 5 TB drives costing so cheap, you can create really really big hash stores .  So as soon as any transaction hits the network, this actor looks up their list of hashes and sees if it is crackable.

Not really. That "rainbow table" attack is simple enough to defeat using a random plain-text 256-bit salt attached to the wallet backup submitted to the blockchain. That specific attack is only an issue for private keys derived solely from a passphrase.

Nevertheless, an attacker can still focus their computational power on a particular user and bruteforce their password in a reasonable amount of time if they used a weak password. Therefore, I don't agree with allowing a publicly available backup to be encrypted by a user-defined passphrase (except perhaps if they really know what they are doing and have to use the CLI to generate it). The computer should generate the 256 bits of entropy used to encrypt the backups that are submitted online (or used to deterministically derived the private keys), and the user should be forced to write down the "brain key" and keep it somewhere safe. They only have to do that once so it isn't much of a burden. It's not like they would have to write down a new brain key each time they need to backup their wallet.

Offline roadscape

You are correct on both counts tbone. @Erlich Bachman - allowing short or insecure keys isn't an option for anyone. The last thing BitShares needs is someone loosing their life savings b/c they failed to provide a good brain key.

I got a lot out of BM's discussion on last Friday's mumble. Two important points:

1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.

2) It's not sufficient to only save private keys. That could work if you're saving a BitShares wallet with only standard accounts, but not if the wallet contains stealth addresses. And, unless a limit is put on how many accounts and stealth accounts a wallet may contain the size of the backup could get prohibitively large to store on the blockchain, even without transaction history.

Regarding the use of blinded transfers as a replacement, I'm not a big fan of that approach. I would want to see more details about the viability of that, focused on the time required to implement it, what the exposure it has on existing code to new bugs, both front end and backend, not to mention who will implement it with this no-dilution cloud hanging overhead.

It is worse than #1. They can store the hashes and then clear out any account that goes forward and uses that hash. With 5 TB drives costing so cheap, you can create really really big hash stores .  So as soon as any transaction hits the network, this actor looks up their list of hashes and sees if it is crackable.

If there's a server containing a bunch of crypto wallets the only safe assumption to make is that it will be hacked. So they better be very resistant to brute forcing either way imo. If you're describing rainbow tables, salting helps prevent those types of lookups.
http://cryptofresh.com  |  witness: roadscape

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
You are correct on both counts tbone. @Erlich Bachman - allowing short or insecure keys isn't an option for anyone. The last thing BitShares needs is someone loosing their life savings b/c they failed to provide a good brain key.

I got a lot out of BM's discussion on last Friday's mumble. Two important points:

1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.

2) It's not sufficient to only save private keys. That could work if you're saving a BitShares wallet with only standard accounts, but not if the wallet contains stealth addresses. And, unless a limit is put on how many accounts and stealth accounts a wallet may contain the size of the backup could get prohibitively large to store on the blockchain, even without transaction history.

Regarding the use of blinded transfers as a replacement, I'm not a big fan of that approach. I would want to see more details about the viability of that, focused on the time required to implement it, what the exposure it has on existing code to new bugs, both front end and backend, not to mention who will implement it with this no-dilution cloud hanging overhead.

It is worse than #1. They can store the hashes and then clear out any account that goes forward and uses that hash. With 5 TB drives costing so cheap, you can create really really big hash stores .  So as soon as any transaction hits the network, this actor looks up their list of hashes and sees if it is crackable.
I speak for myself and only myself.

Offline Thom

You are correct on both counts tbone. @Erlich Bachman - allowing short or insecure keys isn't an option for anyone. The last thing BitShares needs is someone loosing their life savings b/c they failed to provide a good brain key.

I got a lot out of BM's discussion on last Friday's mumble. Two important points:

1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.

2) It's not sufficient to only save private keys. That could work if you're saving a BitShares wallet with only standard accounts, but not if the wallet contains stealth addresses. And, unless a limit is put on how many accounts and stealth accounts a wallet may contain the size of the backup could get prohibitively large to store on the blockchain, even without transaction history.

Regarding the use of blinded transfers as a replacement, I'm not a big fan of that approach. I would want to see more details about the viability of that, focused on the time required to implement it, what the exposure it has on existing code to new bugs, both front end and backend, not to mention who will implement it with this no-dilution cloud hanging overhead.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets.  We don't want to be responsible for the loss of funds.

Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.

 +5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
 
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
 
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
We would have to use very secure passwords.. maybe encrypt the wallet using its own brain key. That would make it easy to recover and hard to hack.. isn't this effectively a brain wallet?

Right, the backups of your stealth can go to the blockchain (the noisy json file compressed, encrypted and base58 encoded as a simple text string into the memo field).
Reference that transaction when needed via its transaction id.
Use a brainkey to access those individual stealth transaction backups, and another brainkey to access the wallet itself.
Almost all of this is existing code, we just need to tie it together and display the backup brainkey to the user upon/via a transaction confirmation modal.
I know my architecture here is missing some specifics, but this can be the general gist of it, and keep it so the user never even has to think about it. Sending and receiving via stealth will become as easy to use as sending an email IMO..

As per BM's statements (https://soundcloud.com/beyond-bitcoin-hangouts/e147#t=10:45) storing the stealth backups in a memo field as per our discussion above will require the user to have a very strong password. Ok, that may be true, but storing my backups on someone's server seems like an even bigger risk (and expense).
 
At this time we are at an impasse, so.. Go back to the old risky expensive centralized server model, OR require users to have a really strong passphrase and stick the backup into a cost-effective secure block transaction?
 
Is it time for a poll? Stealth is pretty much on hold until we resolve this.

If I'm not mistaken, the conversation about needing a strong passphrase had to do with storing keys on the blockchain period (i.e. regardless of stealth).  I thought the stealth-specific issue was that, if you're planning to store keys on the blockchain, the data storage requirements with stealth would be a challenge.  Can someone please correct me if I'm wrong?

The other question about stealth, as I recall it, is whether we want to go with a solution that is more user friendly than the current version implemented for @onceuponatime but isn't as private (i.e. you can see who is transferring but not the transaction amounts or account balances)?  Again, someone please correct me if I'm wrong.

Offline Erlich Bachman

  • Sr. Member
  • ****
  • Posts: 287
  • I'm a pro
    • View Profile
we need both options. one for the pro (us) and the other for the novice (our market)
You own the network, but who pays for development?

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets.  We don't want to be responsible for the loss of funds.

Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.

 +5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
 
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
 
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
We would have to use very secure passwords.. maybe encrypt the wallet using its own brain key. That would make it easy to recover and hard to hack.. isn't this effectively a brain wallet?

Right, the backups of your stealth can go to the blockchain (the noisy json file compressed, encrypted and base58 encoded as a simple text string into the memo field).
Reference that transaction when needed via its transaction id.
Use a brainkey to access those individual stealth transaction backups, and another brainkey to access the wallet itself.
Almost all of this is existing code, we just need to tie it together and display the backup brainkey to the user upon/via a transaction confirmation modal.
I know my architecture here is missing some specifics, but this can be the general gist of it, and keep it so the user never even has to think about it. Sending and receiving via stealth will become as easy to use as sending an email IMO..

As per BM's statements (https://soundcloud.com/beyond-bitcoin-hangouts/e147#t=10:45) storing the stealth backups in a memo field as per our discussion above will require the user to have a very strong password. Ok, that may be true, but storing my backups on someone's server seems like an even bigger risk (and expense).
 
At this time we are at an impasse, so.. Go back to the old risky expensive centralized server model, OR require users to have a really strong passphrase and stick the backup into a cost-effective secure block transaction?
 
Is it time for a poll? Stealth is pretty much on hold until we resolve this.
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline kenCode

  • Hero Member
  • *****
  • Posts: 2283
    • View Profile
    • Agorise
The server-side wallet storage was not part of the proposal, but something we felt was necessary to backup/secure user funds. We do not yet have confidence in the reliability of server-side storage to enable this feature. There is a significant about of liability associated in offering to host/backup user wallets.  We don't want to be responsible for the loss of funds.

Why not backup wallets directly on the blockchain? Along with a hash of the owner's email for easy lookups later. And maybe some random noise.

 +5% +5% +5% +5% +5% +5% +5% +5%
Forget servers, we have a blockchain!
 
How about this...
Throw a bunch of different random numbers and other noise (maybe even the brainkey too?) into a json file, then compress it, encrypt it, base58 encode it, and throw that single text string into a memo. then, there is your backup. just call it up via wif, throw your key at it, and voila'... would that work? It would only cost a few BTS to store it as a transaction in a block too (for LTM's of course). For extra security, make a second backup. Yes? No? Horrible idea?
 
Hiring (and having to constantly trust) a backup server company is a huge expense and risk that Bitshares' name does not need. I think we should leverage the tools that we already have as much as possible. We have the most scalable chain on earth, let's really show it off!
this would be awsome!
how likely is it, that someone could entcode my password?
We would have to use very secure passwords.. maybe encrypt the wallet using its own brain key. That would make it easy to recover and hard to hack.. isn't this effectively a brain wallet?

Right, the backups of your stealth can go to the blockchain (the noisy json file compressed, encrypted and base58 encoded as a simple text string into the memo field).
Reference that transaction when needed via its transaction id.
Use a brainkey to access those individual stealth transaction backups, and another brainkey to access the wallet itself.
Almost all of this is existing code, we just need to tie it together and display the backup brainkey to the user upon/via a transaction confirmation modal.
I know my architecture here is missing some specifics, but this can be the general gist of it, and keep it so the user never even has to think about it. Sending and receiving via stealth will become as easy to use as sending an email IMO..
kenCode - Decentraliser @ Agorise
Matrix/Keybase/Hive/Commun/Github: @Agorise
www.PalmPay.chat

Offline Thom

I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution.

It is not enough to just backup owner keys to the blockchain when it comes to stealth.

Doh! You're absolutely right, how silly of me. That's what I get for posting without pausing to think.

To backup a standard wallet the owner keys would suffice to recover balances, but definitely not for stealth addresses, as you point out.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile
Can someone please point me in the direction of the best description of how this works?

I speak for myself and only myself.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution.

It is not enough to just backup owner keys to the blockchain when it comes to stealth. Stealth transfers (unlike simply blinded transfers) don't publicly signal to the receiver that the transaction is meant for them. This is why with TITAN in pre-1.0 BitShares you needed to scan the entire blockchain with your private keys. In BitShares 2.0, forcing users to scan the entire blockchain is not expected. So a stealth transfer sender needs to communicate some information out-of-band. If I am not mistaken, the minimal amount of information that needs to be communicated out-of-band is a (block number, transaction number) tuple, i.e. a pointer to the transaction in the blockchain that contains the stealth transfer. With this information, I believe the receiver could easily request the transaction in question from the server (which should be small in size), and using their stealth-related private key quickly verify if in fact it contains a stealth transfer to them (and also decrypt the blinded amounts). But without this information, the receiver would not even be made aware of the transfer and thus would not have access to the funds to spend.

I believe that it should in theory be possible to follow the chain of stealth transfers (as in inputs to one stealth transfer consuming outputs of a previous one in the chain) to minimize the number of "transaction pointers" a client needs to keep to be able to fully restore all stealth transfers and thus all of their balances from scratch (assuming they also have their private keys). I think it would only be necessary to keep "transaction pointers" to transactions with the property of containing stealth transfer operation(s) that have output balances accessible by the user (with the exception of ones that would be redundant because the transaction they point to can already be accessed by going backwards along the stealth transfer transaction chain from a newer transaction with the aforementioned property). It could then be possible to take the set of all necessary "transaction pointers" grouped by each account in the wallet to be backed up, subtract that set by the corresponding set computed as of the last backup operation to the blockchain (empty set if this is the first time), encode the contents of the resulting set into a compact string, encrypt it using a private memo key of one of the accounts (the one designated as the account to do backups on), and then publish that string as a custom transaction under the backup account. A client starting from nothing more than a brain key (from which all the other relevant private keys can be deterministically derived), could then follow a procedure to use the data published to the blockchain to quickly (and with reasonable network bandwidth) recover all balances and all relevant transactions (including stealth ones).

Despite the above optimizations, there might still be a moderate amount of data to publish in the custom transaction to backup all the balances and stealth transfers. And each time a backup would be published, it would cost the user some transaction fee. Furthermore, for privacy reasons it would make sense to not publish a custom transaction backup immediately after each time the user receives a stealth transfer as that could potentially link the receiver of the stealth transfer to the backup account (though the link wouldn't necessarily be obvious). So, I would imagine backups like these would be used with less frequency. Instead, backing up the encrypted wallet to the host that provides the client software would be a more convenient solution. However, having a blockchain based backup as I described above would still be a nice addition as a further backup in the unusual case where the host disappears (and the user also makes a mistake and loses the wallet data stored locally with the client at the same time). Even if the blockchain backup isn't very recent, it might still help recover some partial funds in this worst case scenario. And best of all, assuming my understanding of the existing blockchain protocol is correct, the procedure I described above can be implemented by the client alone and doesn't require any changes to the blockchain protocol or the witness_nodes.


Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.

Sell STEALTHS openly on OL  and give the opportunity to our community to participate !

sell them in parallel with 5 different prices and give as 2 weeks....   (like a crowd-sale)

1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH

I am sure it will be successful! 

PS just throwing ideas
Selling to public is different from selling back to the DAC (all stake holders). Arhag posted a solution in last page.

What? Unless arhag changed his username there is no post by him in this thread.

I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution. I don't know what the size limitation is on the memo field but surely the storage details for such a small quantity of data isn't beyond our capabilities to easily implement. Require a 10 or 20 word brainkey of the users choosing to encrypt the owner keys of the accounts held in the wallet. People who use stealth are surely going to be more careful, and having a backup of your wallet stored in the immutable blockchain is about as safe as it gets. Give the user options concerning the brain key. They provide or wallet generates it. Validate strength of any the user provides and give them feedback on the quality.

Of course the had part is how to make it easy to use. I like the "Backup Required" prompt in the bottom right corner, perhaps it needs to be more obnoxious, like blinking to catch the users attention and give them an incentive to make a backup and stop that damned blinking! Maybe lightbox the whole app until it's done before the wallet can even be used again after operations involving stealth are performed. However it's done it's GOT TO BE INTUITIVE AND SIMPLE.

I disagree with @roadscape on blinded transactions. I think that is riskier than polishing the stealth feature, especially if it's only a matter of implementing a solid backup approach, and I fully agree with Ken that any server side approach has risks.

@Thom, I think you may be losing it.  @arhag most certainly did post on this thread.  Scroll up!  Also, storing the account keys on the blockchain was actually @roadscape's idea.  @kenCode gave him major kudos for that....and I do too because yes, it would be awesome! 

By the way, if the keys are stored on the blockchain, why would the user need a reminder to back up their keys?  Wouldn't it just be done automatically?


unreadPostsSinceLastVisit

  • Guest
What? Unless arhag changed his username there is no post by him in this thread.


There sure is: https://bitsharestalk.org/index.php/topic,22138.msg288637.html#msg288637

It's a quality suggestion too imo.

Offline Thom

I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.

Sell STEALTHS openly on OL  and give the opportunity to our community to participate !

sell them in parallel with 5 different prices and give as 2 weeks....   (like a crowd-sale)

1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH

I am sure it will be successful! 

PS just throwing ideas
Selling to public is different from selling back to the DAC (all stake holders). Arhag posted a solution in last page.

What? Unless arhag changed his username there is no post by him in this thread.

I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution. I don't know what the size limitation is on the memo field but surely the storage details for such a small quantity of data isn't beyond our capabilities to easily implement. Require a 10 or 20 word brainkey of the users choosing to encrypt the owner keys of the accounts held in the wallet. People who use stealth are surely going to be more careful, and having a backup of your wallet stored in the immutable blockchain is about as safe as it gets. Give the user options concerning the brain key. They provide or wallet generates it. Validate strength of any the user provides and give them feedback on the quality.

Of course the had part is how to make it easy to use. I like the "Backup Required" prompt in the bottom right corner, perhaps it needs to be more obnoxious, like blinking to catch the users attention and give them an incentive to make a backup and stop that damned blinking! Maybe lightbox the whole app until it's done before the wallet can even be used again after operations involving stealth are performed. However it's done it's GOT TO BE INTUITIVE AND SIMPLE.

I disagree with @roadscape on blinded transactions. I think that is riskier than polishing the stealth feature, especially if it's only a matter of implementing a solid backup approach, and I fully agree with Ken that any server side approach has risks.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html