maxtaco

It's likely the password you come up with will be better than the the unbroken 10 BTC WarpWallet challenge, so you have that assurance. Also, we implemented the protocol twice, using two different software stacks, and checked we came up with the same answer. You can probably convince yourself that WarpWallet works as advertised with about 10 lines of Python. We did something like that when building it.

Because we encourage running this thing on an airgapped machine, you mainly need to convince yourself that we're generating keys as advertised (and not from a small known pool). The airgap would prevent this page from sending data back to a server, even if there was logic to do so (which there isn't).

You still need to remember a good password, but now you have to worry about keeping track of the file. If you lose either, you lose your coin. Plus 7Zip uses a PBKDF2-like key stretcher, but you're probably better off with scrypt, and you're certainly better off with a composition of PBKDF2 and scrypt.

That's not a totally fair analogy. The adversary in this case shouldn't even know you have bitcoin or a WarpWallet; so why would they bother to torture it out of you in the first place?

Edit: but I guess I agree, it would be a nice feature to have that we didn't think much about. I wonder what a solution would even look like.

I wrote a little blog article on how to store the majority of your bitcoin using a security-enhanced brainwallet. Part of the argument is that exchanges and online wallets are and will continue to be magnets for good XSS/CSRF attacks. Mt.Gox/Coinbase Engineers are fighting a difficult fight against well-incentivized enemies.

http://maxtaco.github.io/bitcoin/2014/01/16/how-jason-bourne...

MSR attracts some of the best researchers and makes it easy to get research done. No teaching requirements, grant applications or scrambling for funding. Just research. I sincerely hope tomorrow's Microsoft keeps MSR well-funded, it's a benefit to the whole community.

This is a great analysis, but I'd hesitate to call anything the "root cause" of WWI. Of course the Ottoman Empire's decay was a factor, but hard to say that it was more important than the many others listed here and elsewhere.

I think Jakub P. was implying that the CSRF-token defense could also guard against this attack.

I recently read a fabulous history of WWI (G.J. Meyer's _The World Undone_). What struck me is that if you modeled Europe in 1914 as a distributed system, you'd see incredible latencies between decisions being made and decisions being carried out. Kaiser Wilhelm and King George (first cousins!) were negotiating to stave off the war long after Germany's decision to mobilize, and might very well have succeeded were it possible to reverse the mobilization decision. The German generals insisted it wasn't. And even before then, Germany's decision to mobilize was based on reports of Russia's decision to mobilize, which also took weeks to carry out. If communication and military latencies were shorter, maybe the war could have been avoided. It was like the world's worst race condition.

Thank you for your construction. Cleaner than the one I dreamed up.

Another alternative is https://OneShallPass.com. Free, auditable and open-source.

How does SRP help? With SRP, you still have a server-side brute-forceable table of password hashes. The server stores v = g^x, x = H(s, p), for each user, where s is the salt and p is the password. g is known to the server (and hence the attacker), so if the attacker downloads the database, he can go through the dictionary and brute force. If you're rolling out SRP, you ought to use scrypt for H.

Edit: and BTW, Cupid.com has nothing to do with OkCupid. They were the cause of much confusion throughout our history. We'd tell people to sign up for OkCupid, and they'd go to Cupid.com. Eventually, Cupid.com had to say, in their radio ads, "Not OKCupid.com, go to Cupid.com!"

Thanks for pointing that out, it's bug in the pseudocode, but it's right here in the params file (https://github.com/keybase/warpwallet/blob/master/src/json/p...). I'll fix it now.

Congrats!

Sorry, it's been fixed on the posted URL too.

Was out to dinner. Fixed it, sorry for the 403.

With a bounty -- the first to guess a 2-character password gets $50.

Agwa, thanks for coming to DJB's and my defense. Unfortunately, anyone who disagrees with tptacek gets an automatic downvote.

Well, I am done here. I imagine if we ever met each other in person we'd find each other reasonable people, but over these channels it's not coming across. Until then, good luck.

And I can't resist: you'd be hard pressed to find a better cryptographer than Dan Boneh, one of the authors of SJCL.

Thank you for your reply and expanded comments.

The adversary we are most worried about is a government agency in 2023 demanding a large Website turnover of all live data, backup data, and backup tapes. If a weakness in AES is found sometime before then, the agency can decipher secret data offline and in parallel, regardless of when it was uploaded to the server. In other words, the attack window for encrypted data stored on a server is infinite. If we're encouraging the upload of encrypted data to the server, the encryption has to be future proof, since server-side data is in practice never thrown away.

In the attack you mentioned, the secrecy of TLS via AES isn't at issue since there is nothing secret about our open-source libraries. If the integrity of TLS is broken (due to a real-time exploitable weakness of SHA1-HMAC or of the public key system used in session negotiation), then only those who upload data in the attack window are vulnerable. Those who downloaded and used TripleSec code before the discovery of the attack are not at risk, and of course those who use it after TLS is fixed are also OK.

Finally, I see no problems with older (i.e., 90s era) crypto constructions that haven't been broken. RSA from the 70s is still useful. The cipher cascade here is essentially a one-time pad, so predates Schneier and is better attributed to Shannon 1949: http://netlab.cs.ucla.edu/wiki/files/shannon1949.pdf

Agreed. I am open to valid criticisms on the crypto and/or implementation shortfalls, but unjustified comments don't help.

Is there any justification to your comments? Your criticisms on the crypto have all been debunked by those who know the crypto. See here for an example: http://d3j5vwomefv46c.cloudfront.net/photos/large/810438785....

Again, I am open to valid criticisms. Those of the form "this is stupid because XSS isn't solved" aren't valid in my book because they are orthogonal problems, and progress along either axis is good.

Passwords are bound to be weak, you are right. Running PBKDF2 only gives some protection against password-cracking, but a well-funded adversary can overcome that protection if the original password doesn't have enough entropy.

For passwords, I recommend using a sequence of 4-5 random words chosen from a ~20k word dictionary. This gives you about 58 to 72 bits of entropy.

I also recommend https://oneshallpass.com for giving random PWs to different Web sites, but that's a slightly different problem.

That's a good point. You can feel free to strip them off. After byte 8, the rest of the outputs will appear almost entirely random. It depends on your usage. I'm imagining a database table on a server with a column of TripleSec-encrypted values. In that case, the adversary knows what he/she is getting by looking at the DB schema or reading the code.

It wasn't trivial to write TripleSec, which I why we did it and open-sourced it.

Any encrypted data you put onto a remote-server will live there forever, so your encryption has to be future-proof. I think it pays to hedge your bets here.

All of our implementations are tested against known test vectors. Side-channel attacks could be a problem though.

Yes, it's in Section 15.8 of the 2nd edition of Applied Cryptography. This is basically that scheme, but we're not inflating ciphertexts as he suggests (which is a good thing).

There is no way this construction is weaker than the weakest of the three. To convince yourself of this, assume one of the ciphers is 100% broken and spits out all 0s. Then you're XOR'ing your ciphertext with all 0s (or some other known pad). So it's just a noop. As the FAQ says, because one cipher is not used as the input to another, there's no way a weakness can spread up or down the chain.

There was a discussion on twitter among cryptographers/security practitioners (search for @agl___), and in spite of some unnecessary flaming, we are almost certain now that the cipher cascade and the MAC scheme are both as strong as their strongest components.

See this publication for more information about the cipher cascade: http://rd.springer.com/article/10.1007%2FBF02620231

See this publication for more information about the HMAC construction: http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pd...

For PBKDF2, we use SHA-512 XOR SHA3 as the inner PRF. But you're right, it would be interesting to stack bcrypt and scrypt too. That's a good idea in the name of maximum paranoia. My slight reservation here is that I haven't seen any published results on combinations of key stretchers (there are several for the other primitives).

As for public key stacking, it depends on the application. The fear with putting encrypted data on a server is that it might sit there for all time and therefore needs to be present- and future-proof. If using public key for signatures, you can plan ahead for your key's expiration. For public key encryption, maybe stacking is the right idea.

Version 3, compatible with the latest test vectors published here: http://keccak.noekeon.org/KeccakKAT-3.zip . Our hope is that the algorithm won't change, but if it does, we'll bump version numbers and support decryptions with the old.

It's all on GitHub. Please let me know of any bugs you find, and thanks. I did test the implementation against whatever test vectors I could find, but obviously carry code is tricky and error-prone. Link here: https://github.com/keybase/triplesec/blob/master/src/ctr.ice...

In my experience, speed isn't an issue. The only slow part of any of this is PBKDF2, unless you're dealing with huge files (not the case in chat).