You accidentally install some malware. It scans for any wallet files on your machine and sends it off to an attacker.
0 voters
Currently on Zecwallet Lite, the second option is true. Attacker has a full view of the wallet, including view keys for ongoing monitoring of the wallet in the future.
Yeah - I never understood why the wallet file isn’t completely encrypted. Just the spending keys.
Encrypt everything or nothing?
I expect that attacker to spend all my ZEC and tweet all my past transactions, unless my spending key is stored on a separate device (e.g., hardware wallet) or protected by strong app confinement (which sort of exists on mobile, but not really on desktop).
That is my opinion too. Hopefully I will be able to change that as a part of Zephyr backports to Zecwallet Lite.
Well that would be great!
In your model, where would the spending key, and viewing keys, be stored?
ZecWallet Lite shows the seed if you click on the menu option. There is no authentication required. Don’t hand out your phone unlocked to anyone.
Tbh, I’d like that fixed first but it has been reported ages ago.
If I were to rip out everything to do with saving the wallet and start over, I would do a msgpack structure (as opposed to versioned-magic-bytes currently) which is encrypted whole using AES (not sure about the mode, will need to ask someone smarter).
And where would the AES decryption key be stored?
I’d ask the user to enter a password/passphrase. Then it is stretched with PBKDF2 or similar and used as a key with AES GCM.
Or better yet, use some premade encryption function because why reinvent this (and mess up).
We’re in the scenario where the malware takes over the machine. It sees the password as soon as the user reenters it, or just reads it from memory if it’s still cached.
This doesn’t depend on which block-cipher mode of operation you’re using.
This is why people don’t bother with wallet encryption on desktop. It’s security theater that makes users feel good because they do extra work, but doesn’t actually improve security.
I use a cold wallet for anything more than a few dollars. If your computer can be rootkit and key logged, all bets are off.
But on the other hand, I won’t do the USB dance for a 10 USD transaction either.
Btw, Zcash does not have hardware wallet support for z-addr and until lately neither did it have a cold wallet. I wrote the cold wallet for a ZOMG grant.
So, encryption may not be the best thing, but it’s all we had.
Old versions of Zecwallet Lite (the QT version) did have full wallet encryption. I came to realize that it was a horrible idea, and removed it.
Overall, in my experience, 10x people lost funds because they forgot their password than they did because of malware.
Like @tromer said, Full wallet encryption is just security theatre and in practice causes a lot of problems.
Thanks for the answer! I have been trying to get in touch with you. Can we discuss this (and some other issues) over DM?
I’m with @tromer and @adityapk00 on this; there’s very little we can do on desktops to protect spending keys from endpoint compromise, given the current and widely-inconsistent state of desktops. It’s one of the reasons we’ve not spent cycles to bring zcashd’s wallet encryption (inherited from upstream) out of experimental feature mode. I’d rather get hardware wallet integration via some mechanism (or better support offline signing, something I’ve tried to implement several times).
In mobile environments that have much better environmental controls, there’s more we can do. If I were designing a mobile wallet from scratch, I’d encrypt the mnemonic phrase with age (or rage, which I’m the author of), using an identity stored in the OS’s keystore, and derive the actual spending keys on-the-fly. That would make it possible to authorize spends via the OS’s biometric authentication mechanism, with a fallback to only allowing that specific app to access the mnemonic (if I recall keystore semantics properly).
[1] The reason we made it experimental before launch back in 2016 is that it targets the second option (only spending keys are encrypted), and for Sprout there was no way to provide full viewing capabilities without the spending key. This would have caused the wallet to report an inflated balance, which is the absolute wrong thing to do. We fixed this for Sapling, but the above points remain valid.