5 ms·

IMO it should be done like this. You have a hot wallet, probably on your phone that has a half key. You keep a QR code somewhere else with the other half. Combi

by dreit1 9y ago

IMO it should be done like this. You have a hot wallet, probably on your phone that has a half key. You keep a QR code somewhere else with the other half. Combine these two and you have the cold storage private key. Additionally you could have the full private key in a safe or whatever that you never touch. In this system you can top up your hot wallet by specifying all transaction details and then scanning the QR with the half code to sign the transaction and send it off. This would roughly as secure as some sort of 2FA method. The attacker needs to have both the phone compromised, and the paper with the half key compromised.

siculars 9y ago
I appreciate everything you just said and agree that this could work well for some people. On the other hand, reading it through the eyes of the 99% of people I know who can barely check their email, everything you said may as well be written in Klingon. It is simply too difficult for most people to understand.
- chairmanwow 9y ago
  Cryptography is a necessary lesson that we need to teach in 2017. Lowest common denominator is a hard threshold to design security for.
  - deleted 9y ago
    [deleted]
- prawn 9y ago
  It's not an unsolvable problem with good apps/software though. A key as a sequence of characters is confusing, but depicting an actual key cut in half, that needs to be combined with another, would make sense to people. As was said elsewhere, a lot of this will come as the space matures.
theEXTORTCIST 9y ago
The attacker only needs to have compromised the device which spends from the wallet file
- dreit1 9y ago
  Only a half key exists in permanent storage on device. The other half paper key is loaded into memory for transaction signing, and then removed from memory the moment the transaction is sent off You would need both halves to sign a transaction
  - theEXTORTCIST 9y ago
    I agree that you need "both halves" in this scenario to sign the transaction. At some point during the spend from the wallet, the privkey that matches the wallet pubkey has to touch memory. This privkey can in theory be compromised in a number of ways with malware on the spending system (keylogger, screen caps, process memdump, etc). I think the safest way to go about this is to generate an entirely new keypair/wallet on an isolated system. Spend from your wallet then transfer the balance to the newly created wallet. This minimizes losses as a result of privkey compromise (unless of course your isolated system isn't so secure)

by dreit1 9y ago

siculars 9y ago

I appreciate everything you just said and agree that this could work well for some people. On the other hand, reading it through the eyes of the 99% of people I know who can barely check their email, everything you said may as well be written in Klingon. It is simply too difficult for most people to understand.

chairmanwow 9y ago
Cryptography is a necessary lesson that we need to teach in 2017. Lowest common denominator is a hard threshold to design security for.
- deleted 9y ago
  [deleted]
prawn 9y ago
It's not an unsolvable problem with good apps/software though. A key as a sequence of characters is confusing, but depicting an actual key cut in half, that needs to be combined with another, would make sense to people. As was said elsewhere, a lot of this will come as the space matures.

theEXTORTCIST 9y ago

The attacker only needs to have compromised the device which spends from the wallet file

dreit1 9y ago
Only a half key exists in permanent storage on device. The other half paper key is loaded into memory for transaction signing, and then removed from memory the moment the transaction is sent off You would need both halves to sign a transaction
- theEXTORTCIST 9y ago
  I agree that you need "both halves" in this scenario to sign the transaction. At some point during the spend from the wallet, the privkey that matches the wallet pubkey has to touch memory. This privkey can in theory be compromised in a number of ways with malware on the spending system (keylogger, screen caps, process memdump, etc). I think the safest way to go about this is to generate an entirely new keypair/wallet on an isolated system. Spend from your wallet then transfer the balance to the newly created wallet. This minimizes losses as a result of privkey compromise (unless of course your isolated system isn't so secure)