Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - arhag

Pages: 1 2 [3] 4 5 6 7 8 9 10 ... 81
31
General Discussion / Re: Bug in Web Wallet's implementation of memo encryption/decryption! Please read!
« on: May 18, 2016, 03:54:18 am »
Quote from: dannotestein on May 18, 2016, 03:28:14 am
Quote from: arhag on May 18, 2016, 03:12:35 am
Why not include the flawed version of the algorithm as a backup in the web wallet (and maybe even the cli wallet) in case the correct version is unable to decrypt the memo? I know keeping this legacy cruft in the code would be annoying, but isn't it better than users being unable to view their old memos in a convenient manner?
We can do it if there's a significant interest, but I think this will effectively double the computational cost of decoding memos since the wallet tries to decode the memo in every transfer it sees and most of them won't be decodable. This still might not be that significant a cost, I really don't know, but also bear in mind only a very few old memos wouldn't be decryptable without this code.

I'm not sure why the wallet should attempt to decode the memo of every transfer it sees. It just needs to do so for transfers either to or from the accounts that are "My account". But even if that additional cost is too much, there could be an option in settings to only enable it for transfers dated prior to some specified date.

32
General Discussion / Re: Bug in Web Wallet's implementation of memo encryption/decryption! Please read!
« on: May 18, 2016, 03:12:35 am »
Why not include the flawed version of the algorithm as a backup in the web wallet (and maybe even the cli wallet) in case the correct version is unable to decrypt the memo? I know keeping this legacy cruft in the code would be annoying, but isn't it better than users being unable to view their old memos in a convenient manner?

33
Peerplays / Re: [ANN-Updated 5/5] Peerplays Prelaunch - Millions are Waiting For You!
« on: May 08, 2016, 01:43:34 am »
Do you guys have someone on the team who is well-equipped to handle the cryptography integration challenges? I'm looking at the math behind mental poker, and it isn't trivial. The shuffling version of the mental poker protocol seems pretty straightforward but apparently it is too slow for the kind of real-time play online poker players expect. There is a non-shuffling version suitable for poker, but the math gets a little more hairy (luckily there is readily available code implementing the ElGamal cryptosystem). I would imagine that this might just be the beginning of the kinds of cryptography challenges that will be faced when implementing various provably fair on-chain games (then again maybe card shuffling is the only primitive that will be needed).

Edit: Then there is this paper (warning PDF), which may or may not (I honestly couldn't tell because it was over my head) solve the blockchain bloat issue of using the above (ElGamal) to implement decentralized poker.

34
General Discussion / Re: STEALTH Status Update
« on: April 20, 2016, 05:01:13 am »
Quote from: Thom on April 20, 2016, 03:53:21 am
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.

Quote from: Thom on April 20, 2016, 03:53:21 am
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).

Quote from: kenCode on April 20, 2016, 05:01:02 am
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.

35
General Discussion / Re: STEALTH Status Update
« on: April 20, 2016, 04:34:37 am »
Quote from: Brekyrself on April 20, 2016, 03:52:32 am
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.

36
General Discussion / Re: STEALTH Status Update
« on: April 20, 2016, 03:22:06 am »
Quote from: Thom on April 20, 2016, 02:47:13 am
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.

Quote from: Thom on April 20, 2016, 02:47:13 am
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.

37
General Discussion / Re: STEALTH Status Update
« on: April 19, 2016, 10:59:37 pm »
Quote from: Thom on April 19, 2016, 02:50:53 pm
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.

38
General Discussion / Re: Steam 7 days to sweat equity (sorry both with an 'e')
« on: April 16, 2016, 06:36:43 pm »
Quote from: btswildpig on April 16, 2016, 05:09:26 pm
The reason I use "" on "fund" is because they just allocated bunch of virtual coins to themselves , but the market may not want to give these virtual coin value due to the way that it was allocated .

It is essentially the same funding model as an ICO [1], and there doesn't seem to be a shortage of people willing to throw money at ICOs of various crypto projects in this space.

My only issue with ICOs (let's ignore the legal implications for now) is that it requires huge upfront payment (even if it's vested) to a single team that you hope will follow through on their promise. I prefer the gradual pay with dilution method like BitShares workers, assuming the holders are decentralized enough so that a single team cannot just unilaterally vote the worker to pay them. But as we have seen from the anti-dilution camp in BitShares, apparently the myopic stakeholders cannot be trusted to do what is best for the long-term benefit of the DAC [2]. So perhaps a benevolent dictator model (at least initially) will gain more success.


[1] To regulators reading this: it is nothing like an ICO. -thereverseflash     ;)

[2] Maybe it would have been different if only vested BTS could vote. I don't agree with the VEST model of STEEM being used in BitShares, because I don't think the voters should be completely immune from the inflation that they vote for. But some small (with a hard-coded upper bound) interest rate could be offered to vested BTS (payed for by dilution) in addition to the right to vote in order to act as an incentive to vest despite the risk due to the lack of liquidity. Theoretically, this is still possible to implement in BitShares with a hard fork if people were okay with it.

39
General Discussion / Re: STEALTH Status Update
« on: April 14, 2016, 05:01:11 am »
Quote from: Brekyrself on April 14, 2016, 03:53:05 am
BM mentioned our account balance can be hidden, how so?  If Account A has 100 bts and blind transfers to account B 100bts with the blind feature, we can still see Account A HAD 100bts and now has 0?  We can easily assume Account B now has 100bts.  Is the only way to gain true stealth still through a mixing service?  This appears to be similar to 0.93?

But the public wouldn't be able to tell that A sent B 100 BTS nor would they be able to tell that A is left with 0 BTS. Let me make it more clear with the following example. Let's say Alice originally has 500 BTS in a public balance and decides to blind that value and send 100 BTS of it to Bob. She creates a transaction that consumes the 500 BTS as input and creates two blinded balance outputs: one is 100 BTS for Bob and the other is 400 BTS change for herself. Now the public knows that the sum of her remaining balance and the amount she sent Bob needs to equal 500 BTS, but they have no idea how much each are individually.

Quote from: Brekyrself on April 14, 2016, 03:53:05 am
Once a balance is hidden, how will it effect voting?

If a balance is completely blinded it cannot be used for voting. The most we could do is allow the user to expose a minimum value for the blinded balance and only that minimum value will contribute towards voting (and contribute towards rate-limited free transactions). The remainder of the blinded balance beyond the exposed minimum value would not count however. Obviously in that case the user has a trade-off to make between how much voting power (or rate-limited free transaction bandwidth) they want and how much of their privacy they wish to give up.

Quote from: Brekyrself on April 14, 2016, 03:53:05 am
Can additional features be added to hide things like who we are voting for?  Our white/black lists?  Assets?  Permissions?

Short of some fancy new amazing cryptography innovations... no.

40
General Discussion / Re: [ANN] Peermit 2-Factor-Authentication deployed in the TESTNET!
« on: April 12, 2016, 02:22:20 am »
Quote from: xeroc on April 11, 2016, 07:25:12 pm
For now, I think it doesn make sense to give people even more options
but I will certainly look into it! Thanks for the feedback!!

Sure, I agree it is best not to give users too many options. So if I had to pick one I would say avoiding the proposed transaction feature of the blockchain and instead communicating txs and signatures between 2FA provider and user directly would lead to better UX and get around some of the existing limitations of the blockchain like issue 479. Happy to hear you are considering it though.

Quote from: xeroc on April 11, 2016, 07:25:12 pm
Totally, this has been on my list for quite some time and with the
option to use this for 2FA, I might implemented it sooner than thought.
Now that I learned quite a bit about the internal mechanisms of the web
wallet, it might even not take so much time.

Thanks for your feedback, much appreciated!!

Fantastic. Thanks for all of your work!


Quote from: abit on April 12, 2016, 01:14:41 am
@arhag FYI there are several know issues in Graphene core and UI which made things a bit messy:

Thanks for those list of issues @abit.

Quote from: abit on April 12, 2016, 01:14:41 am
* https://github.com/cryptonomex/graphene/issues/479 why proposer doesn't approve the proposal by default

I see that backreference IDs were chosen to not be implemented in Graphene. So as it stands, atomically creating and approving a proposed transaction is not possible. That's too bad. Even more of a reason to use an out-of-band method for 2FA multisig rather than proposed transactions. It would make the UX for the user so much better.

Quote from: abit on April 12, 2016, 01:14:41 am
* https://github.com/cryptonomex/graphene-ui/issues/721 Current GUI always require owner authorities while voting

Oh good. So the voting issue I encountered is a GUI bug and not a protocol bug. And just to add my two cents on the discussion for issue 556, I think it makes sense that the active authority can change active permissions. I don't agree with pc that it makes the distinction between owner and active useless. The way I think of it, the owner keys are just meant to be stored offline as a backup mechanism to get back control of your account even if your (hot) active keys are compromised. Actually, one other thing that I think might make sense to only allow owner keys to do is to transfer the account name. Your account name might be very valuable and you likely have no way of getting it back if it was stolen from you. If you could transfer it using only the active authority, then a compromise of your hot wallet could mean the loss of your account name. At least with asset transfer risk you can limit the potential financial loss by limiting the amount of assets you store with the account.

41
General Discussion / Re: [ANN] Peermit 2-Factor-Authentication deployed in the TESTNET!
« on: April 11, 2016, 06:45:06 pm »
I just came across another annoyance (bug? feature?) in Graphene that I never realized before. Apparently changing your votes requires owner permissions instead of active permissions? I tried setting a proxy voter for my arhag1 account using a proposed transaction. However, it did not require approval from arhag2 and secured-by-peermit as I expected it would. It required approval by the owner key of the arhag1 account. Because I changed the owner key of arhag1 to a key that the wallet did not have access to, I was unable to approve that proposal. So I had to manually import the owner private key and then approve the proposed transaction to set the proxy. I then deleted my wallet and created a new one from the brain key to go back to a state where the wallet does not have the owner private key stored locally (for security reasons). Now that arhag1 proxies to arhag2, I can change votes directly with the arhag2 account without needing to make any more account changes to arhag1. But I find it frustrating that I had to use an owner key to change my votes in the first place.

Am I correct in understanding that this is a limitation placed by the blockchain itself? If so why? Is it intentional or is it a bug? Do we need to change the protocol through a hard fork to allow vote changes to be authorized by either owner or active permissions rather than only owner permissions?

Also, what happens if I proxy to an account that proxies to another account? Will the vote weights follow to the terminal account? If not, the limitation above is even more problematic. Let's say I want to proxy my vote weight to xeroc, but I want to be able to easily choose another account to proxy to at a later date. I can set arhag2's proxy to xeroc. But if I set arhag1's proxy to arhag2, then its stake won't count in the vote if the proxying is not transitive. If I proxy arhag1 to xeroc directly and then later decide to change the proxy, I will be forced to not only change the proxy on my arhag2 account (which is no big deal) but also the more troublesome arhag1 account. That requires going through the inconvenient and insecure process of importing an owner key to a hot client (or alternatively if we had offline transaction signing then it could be done securely but still inconveniently) to change the proxy on the arhag1 account. So if proxy voting is not transitive, I would consider the above limitation a bug. And even if it is transitive, I still think it makes sense to make the change anyway because if active permissions can steal all the funds of the account then it makes no sense for changing votes to require any more restrictive/secure permissions.

42
General Discussion / Re: [ANN] Peermit 2-Factor-Authentication deployed in the TESTNET!
« on: April 11, 2016, 05:21:40 pm »
Nice job xeroc! But I do have some criticism.

The way I see it there are two ways to do multisig on Graphene.

The first is to use proposed transactions the way you have done here. You have a secured account whose funds are protected by multisig, and you have a reference account that can create transactions using only the private key stored locally in the user's wallet. The secured account's active authority requires signatures from both the reference account and the 2FA provider. The reference account is needed to create and submit the proposed transaction to the blockchain.

This method has some advantages:
  • The signaling to the 2FA provider is done through the blockchain which (maybe?) simplifies the interaction between user and 2FA provider.
  • The user can hold funds securely in the secured account but can also hold some funds in the reference account that can be spent without the extra overhead of 2FA. The funds in the reference account are at risk of being stolen if the user's wallet is compromised, but if the user only keeps small amounts in the reference account for temporary convenience, this may not be a big issue.

But it also has disadvantages:
  • There is additional blockchain bloat required for each transaction. And though these would likely be rate-limited free transactions, there is still some cost to the overhead for example through the opportunity cost of using the bandwidth allocation for other free transactions. And the 2FA provider needs to broadcast a proposal approval transaction to the blockchain. How will they pay for this overhead (say through the opportunity cost of holding enough BTS so they have sufficient bandwidth available to serve their customers)? They might have a policy of only approving transactions that  pay them a small fee. Or they might just slightly increase their monthly subscription fee that they expect users to pay them for their service. Either way, a profitable business acting as the 2FA provider will somehow pass on this overhead cost to the user.
  • It requires the user to setup two different accounts. Perhaps users don't care about the flexibility of having an account that they can spend some funds without 2FA required. In that case, dealing with two accounts just adds extra cognitive burden to the user.
  • If the reference account runs out of funds to pay fees, it is no longer possible to even propose a transaction to move funds from the secured account to the reference account despite the fact that the user has plenty of funds in the secured account to pay the fees. I ran into this problem myself when using the testnet. Check out the transaction history for arhag1 and arhag2 to get a sense of the problem I ran into. I needed to create a new account i-messed-up to just get free money from the faucet to transfer to arhag2 so that arhag2 could pay the fee for a proposed transaction.

The second way to do 2FA is for the user's client to pass the partially signed transaction to the 2FA provider and have the provider sign it (after verifying authority using 2FA) and broadcast the fully signed transaction. This method avoids the overhead of proposed transactions and allows the user to use just their one account. Graphene's proposed transactions are incredibly useful when you have more than one signing parties that are regular users and not services provided by a business. But in the typical setup for 2FA, you have one regular user and one business. The signaling and communication protocol to carry out multisig in this case is simple enough that Graphene proposed transactions are not necessary.

I would love to see 2FA providers allowing both options to be available for users. But I think the second approach is the simpler one that users should be pushed towards by default.



So now for some problems I had with the current implementation of 2FA using proposed transactions. It was hard to follow your guide. I'm pretty sure I didn't end up following the exact procedure you meant for us to follow due to vagueness of the guide. It would be better if you went through an example using actual account names rather than "secured account" and "reference account". I also ended up having both accounts in one wallet for convenience. I am not sure if that is what you intended. I created a proposed transaction that was payed for by my arhag2 reference account to send 300,000 TEST from my arhag1 secure account to arhag2. After creating this proposed transaction, nothing happened. I went to my arhag1 account in the wallet and discovered that the proposed transaction had not been approved by either secured-by-peermit or arhag2. I don't see why the client doesn't automatically approve using the reference account when I create the proposed transaction using the refernce account. I was forced to create yet another transaction to approve the proposed transaction using arhag2. This entire UX needs to be streamlined so that some of these implementation details are abstracted away. Anyway, I wasn't able to actually get it to work because the proposed transaction I created is still waiting to be approved by seecured-by-peermit, but I haven't received any email at all. Nevermind, it worked. I turns out the email went to my spam folder.

The other thing I would like to see is for the 2FA authentication to be optionally done using TOTP. It is much easier for me to read a 6 digit one-time code off my smartphone and type it into the BitShares wallet than it is to deal with emailed links for every single transaction. This can be an authentication mechanism for lower stakes transactions. The 2FA provider can provide limits on how much funds can be transfered in some time window using authentication by TOTP alone. For higher stakes transactions, email links + TOTP could be used so that the user can get feedback from the provider about what transaction they are approving (in case their desktop computer is compromised for example).

Edit: BTW, I think we need the following additions/utilities. The GUI wallet should have a mechanism of creating and perhaps partially signing but not broadcasting a transaction which can be saved to a file. It should also have a mechanism to read a (perhaps partially) signed transaction from a file, presenting the transaction to the user, adding any extra signatures it can and then broadcasting it to the network. We then need a nice offline utility to: 1) generate new public key/private key pairs; 2) deterministically generate private keys from a brain key + passphrase and import them into a temporary wallet session; and, 3) read a transactions from a file, presenting it to the user, adding any signatures it can, and then saving the signed transaction to a file. This way, the offline utility can sign transactions that change the secure account's owner and active permissions without ever exposing the owner keys of the secure account to an internet connected computer.

43
General Discussion / Re: STEALTH Status Update
« on: April 11, 2016, 03:28:05 am »
Quote from: gamey on April 11, 2016, 01:57:03 am
Quote from: Thom on April 11, 2016, 01:28:31 am
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.

44
General Discussion / Re: Yunbi started voting against all workers except refund/burn workers
« on: April 08, 2016, 05:31:13 am »
Quote from: gamey on April 08, 2016, 12:06:03 am
Just think if Polo pulled a Yunbi but with their own workers.  It isn't going to happen, but I wonder whose opinions would change.

If I'm not mistaken, based on the current actively voting stake, Poloniex alone has enough stake under their control that they could replace the majority of active witnesses with their own accounts if they wanted to. Taking over the committee and workers would be even easier. Same goes for BTC38.

45
General Discussion / Re: STEALTH Status Update
« on: April 08, 2016, 04:37:28 am »
Quote from: Thom on April 08, 2016, 02:32:53 am
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.


Pages: 1 2 [3] 4 5 6 7 8 9 10 ... 81

Page created in 0.223 seconds with 23 queries.