I’ve always looked at GPG subkeys with a bit of fascination, thinking it’s the thing that separates GPG aristocrats from ignorant crypto-peasants like myself. Turns out that, while the idea of having master and slave keys is cryptographically sound, the GPG implementation is insecure.
As usual, #bitcoin-assets has it, and tells us exactly why.
Yes, the reason is simply that what glues the master and the sub together, is a SHA1 hash. According to Schneier it cost ~$3mn in 2012 to find an arbitrary SHA1 collision. That alone is grounds to burn the whole thing down.
Now imagine what the figure has become in 2015, when the Bitcoin-world has spent the last six years relentlessly looking for more efficient ways to bruteforce the living crap out of SHA2.
One of the reasons, among others, that re-doing GPG has been on #b-a’s TODO for a while.
The blockchain.info model is usually presented as the best available to store money easily. It’s nicely summed-up in its description:
The amazing part is the encryption is all done within your browser, before it is saved on our servers, so not even we have access to your account!
Which is a bit misleading: if the wallet code is served dynamically, it can also be dynamically and selectively changed in order to leak keys.
It goes further when one realizes that Blockchain.info uses the DDoS-mitigation service of CloudFlare. It is a trade-off, in exchange for protection, you have to give up a great deal of security.
Because it has to terminate the TLS tunnel, CloudFlare gets to see and alter all the traffic flowing both ways.
That can not only be used to alter the data on-the-fly, but more importantly to sniff signed transactions and AES-encrypted wallet blobs.
In other words, CloudFlare can, without ever being detected:
- know which wallets are fat and ripe, and apply offline brute-force key cracking techniques on their specific AES blobs,
- de-anonymize Bitcoin addresses by mapping them to the IPs from which signed transactions originate.
It’s ok though, the NSA doesn’t care.
 The way this is usually dismissed is by arguing that clients can run a client-side code verifier, which is theoretically true.
 See: The CloudFlare MITM
 Think your password is strong? Think again.