Root Labs Rdist

Sending code to a desktop is easy to detect. Sending code to a non-web-based mobile app is easy to detect. Sending code to a browser isn't even detectable. In practice, no one audits JavaScript. If browsers offered the means to detect changes to cached content, security experts[1][2][3] would be less grim about webpage security.

Encryption done in untrusted JavaScript is security theater. If these websites offered privacy policies claiming to never read your data, like Riseup does, the end-result would be the same. Safer, actually, because deploying unnecessary crypto increases the vulnerability risks.

Recommending these websites is actively dangerous. Journalists and whistleblowers who take these claims of fraudulent security seriously, are going to be killed. Getting them to understand that email cannot be secured in-browser, is the entire point. That if you have important information to protect, you should be moving onto different approaches.

WhatsApp is literally safer than this, and it's more accessible.

[1] https://www.schneier.com/blog/archives/2012/08/cryptocat.html

[2] https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

[3] https://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

I'm conflicted on Axolotl. For every layer of security you add, you increase the odds of someone doing something careless (this[1] is way more common than you'd think).

Key-leak healing is an interesting function out-of-the-box, but if your priv key gets uploaded accidentally, odds are so did your DH Identity/Ratchet/Chain keys as well, effectively rendering you "fully compromised". It only offers protection in an instance where you keep your keys compartmentalized.

Is there a general consensus within the crypto community as to whether a) this is conceptually sound, and b) if there's an audited implementation? It's so so easy to mess up and have that error be overlooked (i.e. the OpenSSL debacle), which makes me want to just stick with the tried and true GPG DH/ELG setup with PKI and revocation. Definitely a real interesting project to watch and a real interesting take on perfect-forward secrecy though! Thanks for your feedback. If you see this, read my other post in this thread and e-mail me, I'd love your feedback.

[1]http://rdist.root.org/2008/02/05/tlsssl-predictable-iv-flaw/

Some quick impressions:

* There's no serious set of test cases. Many Bcrypt implementations were bitten recently when it turned out that they didn't properly handle characters with the high bit set.

* It only ever uses a work factor exponent of 8 which is probably too small for most modern use.

* Even if the password hash specifies a different work factor it will still use 8, and then fail.

* It's not going to interoperate with other implementations for these two reasons.

* The timing of regex's excecution probably leaks information about the salt.

* It uses perl's 'eq' for comparing the strings. The time that this function takes to run is probably dependent on the length of the matching prefix of the two strings. So there's possibly a timing attack enabling an unauthenticated remote attacker to read some of the password hash string. He may need to know the salt, but the salt is not considered a strongly-kept secret. Nate Lawson's blog is a great source on this topic http://rdist.root.org/2010/01/

I'm not sure I have it, but I believe that with DSA, given the message, signature and message specific private value, you can derive the private key. Wright is calling that message specific value a nonce, but for DSA, it has to be secret and unpredictable ( https://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/ ).

In the Playstation hack, a single private value was mistakenly used in multiple messages (so it could be recovered from just a couple signatures https://www.imperialviolet.org/2013/06/15/suddendeathentropy.html ), but it's also true that if you have information about how the private value was created and it was poorly done, you can just check all the remaining possibilities. So that's what the cryptographer is talking about, given information about sufficiently poor generation of the message specific secret, you can pull private keys out of a single signature.

I'm completely overwhelmed by security topics, so please pardon this stupid question. But could you expound on this part:

But ultimately, the conditions necessary for this type attack are not generally realistic, and I don't believe it should be characterized as a real risk.

Shouldn't it be possible to factor out the network jitters? I'm reminded of this post by Nate Lawson about Keyczar.

http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/

Is this attack unrealistic because taking enough samples to factor out the jitters would be very obvious to an administrator? Or is it exceedingly unlikely that a public network will ever have low enough latency to perform this sort of timing attack on this particular vector? Or am I misunderstanding your point entirely?

I really appreciate your taking the time to explain this stuff to people like me! Its fascinating.

First of all, the video you're talking about wasn't a timing attack.

Microseconds over the Internet. Nanoseconds on private networks. Here are some grandstanding security researchers demonstrating this at this year's Black Hat:

http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/

Note: I don't think they were even using signal processing techniques, which is what the academic results used.

Since you don't even know what's being timed here, and the evidence you're collecting to support your argument is two back-to-back reloads of Hacker News, I'm not sure where you get off writing "classic white room scenario". But then, the last thread you commented on, you said "This exploit has remarkably little applicability to the vast majority of ASP.NET applications". Then Bruce told you they used it to get SYSTEM on a remote Sharepoint install.