cryptbe

POODLE worked not only against SSLv3, but also against any TLS implementations that check padding in SSLv3's style (e.g., just checking the last byte, and ignoring the rest of the padding). SSL accelerators from F5 and A10 were vulnerable. Thus, many of the world's largest sites were vulnerable.

Speed. Key generation (and most other operations) in ECC is order of magnitude faster than in RSA, DSA or ElGamal. Last time I checked it took End-To-End's Javascript library seconds to generate a key pair in RSA, but only milliseconds in ECC.

Great question. The core crypto library in End-To-End has already supported ECDH on Curve25519 and Ed25519 since day one [1]. We're discussing with GnuPG team on extending RFC 6637 to include these algorithms in the OpenPGP standard.

[1] https://code.google.com/p/end-to-end/source/browse/javascrip....

Congratulations Werner and GnuPG team!

> GnuPG now support Elliptic Curve keys for public key encryption. This is defined in RFC-6637. Because there is no other mainstream OpenPGP implementation yet available which supports ECC, the use of such keys is still very limited. [1]

Google End-To-End [2] supports ECC by default. We are working on supporting Ed25519, but encrypting and signing with NIST curves should work and be compatible with GnuPG. That said, we've had a lot of compat issues, so it'll be great if Hacker News readers and GnuPG users can help test our implementation against GnuPG. You can generate keys in GnuPG and import them to End-To-End and vice versa, or you can encrypt/sign messages on one software and decrypt/verify them on the other. If you found a bug or anything that doesn't work as expected, you can report it at https://code.google.com/p/end-to-end/wiki/Issues?tm=3. If it's a security bug you're eligible for a monetary reward under our bug bounty program :-).

[1] https://gnupg.org/faq/whats-new-in-2.1.html#ecc [2] https://code.google.com/p/end-to-end/

> Sure you have control over the first N bytes. Look at the request-line: "GET /hello/world/this/is/my/url HTTP/1.1". Sure, you don't control the spaces, but you can assume any practical implementation uses a single space character. Combine that with control over the method (with XHR or statically through <form> or <img>) and the path, you're in business.

tptacek is right. To make BEAST work we had to control _all_ the bytes of the very first block. We tried very hard to make it work with Javascript, but we couldn't. Java applet (and maybe Flash) was the only tool that gave us that kind of control.

When Pornin disclosed CRIME I was telling myself: "Wait a minute, I saw this name somewhere." Then I remembered that it was Pornin's article [1] that helped me understand how zlib flush modes work.

I thought that was pretty funny.

[1] http://www.bolet.org/~pornin/deflate-flush-en.html

If you want to learn the math, check out http://www.amazon.com/Introduction-Mathematical-Cryptography....

What might happen if r = s = -n? I think it's pure luck that this doesn't lead to a signature forgery.

I took a quick look at your implementation of ECDSA and I think it has a bug at line 311 [1]. It looks like I could bypass the check if r or s is negative.

One thing that I don't understand is why big integer libraries developed exclusively for crypto need negative numbers. The library [2] that I contribute to doesn't need them, and it works just fine. Actually I could argue that having only non-negative numbers make it simpler and faster.

[1] https://github.com/cryptocoinjs/ecdsa/blob/master/lib/ecdsa.... [2] https://code.google.com/p/end-to-end/source/browse/javascrip...

Oh yeah, it was restricted to my team. I'll make it public, and notify you via email. BTW IDEA is not enabled/registered.

Thanks for the report. I'll take a look and get back to you. Where can I contact you?

Edit: I've just filed https://code.google.com/p/end-to-end/issues/detail?id=82. We can discuss the problems of IDEA there. Thanks!

> None of this bickering changes a simple truth: when a web mail provider claims to provide "NSA-proof" end-to-end encryption, hosted in Switzerland just to be safe, using software that you don't have to install on your computers at all, then you need to assume that web mail provider can read your email, and so can anyone who can coerce that provider into doing something. If you believe that --- and you should --- then I don't care what you think about the rest of the Matasano article.

This. The whole article could be replaced with this paragraph, and it couldn't be clearer.

> So, it isn't actually a bit more challenging then?

More challenging, yes. Riskier, no.

I don't like that Javascript doesn't have native support for big integers (like Python does), or that it stores numbers as floating points in a 52-bit mantissa, but I fail to see why this makes developing crypto code riskier.

> Also, it seems to me like you are at least forgetting timing and possibly other side channels.

Well, I ain't. When you don't control the instructions being executed by the CPU you may have the risks of security-sensitive information leaks. This applies not only to Javascript, but also to all scripting languages. I could say that it also applies to Java, if the methods in its BigInteger class aren't fixed-timing.

In other words using Javascript doesn't make the problem any worse. If you disagree, you're invited to take a look at End-To-End, find a side-channel leak and write an exploit for it. You could earn serious cold cash with that finding.

> I just can't see any actual scenario where that helps, mostly because it seems to me that the cipher text usually would be a plain-text equivalent, so it doesn't really matter to the attacker whether they have the plain text or the cipher text.

I described where it helps in my article.

Re your last point: if doing SSH in a browser isn't crypto I don't know what could be. Is the only thing you consider Javascript crypto encrypted webmail? That's your problem then. You know one wrong use case, and you refuse to admit that there are other legitimate ones.

Edit: remove a few unnecessary sentences.

Edit: some people don't like Javascript crypto so much that they downvote me without saying anything.

> Seriously? It makes it more difficult to get things right, but the risk of getting it wrong is not increased? And that after you just described how the challenges of JS have already directly led to vulnerabilities?

Well it seems that you misunderstood which challenges I was talking about. Lack of types is a big problem, but besides that everything else doesn't make the risk bigger.

> How exactly does a malicious server not affect "crypto browser apps"?

I didn't claim that malicious servers won't be able to affect crypto browser apps. What I said is that in these apps you have to trust the server already, so it doesn't make sense to consider them untrusted.

> How does staying out of scope for PCI DSS have anything to do with security (except maybe demonstrating that PCI DSS is crap because it can so easily be circumvented)?

It's exactly the point. When people say "javavascript crypto is harmful" they don't consider use cases where it's really useful, even just to circumvent PCI DSS.

> Also, in what kind of scenario would leaking info in a referer be a problem, but leaking the same info in encrypted form would not?

I don't understand this question.

> And how do you guarantee that your verification code is loaded fresh from the server once your application has been compromised in a browser?

Because every time I refresh my browser I get a chance to get some trusted code from the server.

Thanks for posting this article. I wrote it was a response to the Matasano's article that I saw on Hacker News a few days ago.

I want to introduce many useful applications of Javascript crypto that I've seen, and I want to explain that developing crypto in Javascript is difficult because of the lack of types. What I found surprisingly is that most people that complain about Javascript crypto don't even mention this problem. I guess they think the language is too bad to even give it a try.

Interesting coincidence. I just wrote http://vnhacker.blogspot.com/2014/06/why-javascript-crypto-i..., in which I explain the threat model implied in the Matasano's article doesn't apply to most applications.

Yes. This is something we or at least I would do in a few months.

> Thanks for for reply. I'm wondering if you know if it's possible to use the AES-CFB mode from the Web Crypto Apis, since the OpenPGP CFB (resync) mode seems to have special requirements?

I haven't looked into it.

> Thanks! Is there a guide somewhere that explains how to build the standalone lib?

No, there isn't. But can you file a bug with us? I'll make sure we have something for you.

PS: how can I contact you?

DSA: https://code.google.com/p/end-to-end/source/browse/javascrip....

> I do expect users to hash the message before passing it to ECDSA, this way you could use any hashing library with it. Though, elliptic.js does actually depends on hash.js to seed it's PRNG.

I think this isn't a good design because most people won't know that they must hash the message before passing it to the ECDSA. People will misuse it, and open themselves to attacks.

What you can do instead is to pick the right hash based on the curve, like what we did in End-To-End: https://code.google.com/p/end-to-end/source/browse/javascrip....

Thanks for the update on OpenPGP.js.

> What are your plans in regards to web crypto?

The plan is to use WebCrypto if it's available. We've moved RSA to WebCrypto, and the next targets are ECDH and ECDSA.

> Also what is the predicted timeline for getting End-to-End into a production ready state? We would be quite interested in using it as a standalone library in our Chrome Packaged App: https://whiteout.io

I can't tell you about our timeline for the extension. But if you just want to use the crypto library, you may want to wait for a couple of weeks, just to make sure none discovers any serious vulnerabilities.

I like WhiteOut. It's a great product in the right direction. We really want and will support the usage of the library in products like yours.

> his infamous's Crypto I class

s/infamous/famous.

Oh we haven't. Looks like it's a nice library. One question: it seems that you use the message directly, instead of its hash, in ECDSA? [1].

[1] https://github.com/indutny/elliptic/blob/master/lib/elliptic...

PS: were you the guy that won the CloudFlare's HeartBleed challenge? great work :-).

Not a stupid question at all. We actually considered this option, but OpenPGP.js looked pretty bad back then.

Security-wise the library wasn't in good shape. One of our cryptographers would "classify [OpenPGP.js] as trash". It has been audited recently, but the result doesn't look very good either [1]. I don't know the current status though.

OpenPGP.js didn't actually implement most of the ciphers - it just imported them from various sources. This made the library inconsistent, i.e., some functions expect string, while others expect byte array, which in turn made it harder to use correctly in a language like Javascript. If we chose OpenPGP.js, we needed to change these ciphers anyway, so we thought it's just better to write them from scratch.

[1] https://cure53.de/pentest-report_openpgpjs.pdf.

It supports Curve25519 and Ed25519: https://code.google.com/p/end-to-end/source/browse/javascrip... and https://code.google.com/p/end-to-end/source/browse/javascrip...

Disclaimer: I contribute to the core crypto library in Google End-To-End.

I was also a student of Prof. Boneh. I took his CS255, and became a TA for his infamous's Crypto I class on Coursera. So I guess at the end of the day it's still Boneh's teaching that has helped my colleagues and me create this library ;-).

SJCL is a great library, but it didn't quite work for us because:

* It isn't a Closure library. We want to use Closure because it supports types, which in turn make it easier and less error-prone to develop crypto code.

* It doesn't support typed arrays. We don't have typed arrays in End-To-End yet, but we're working on that.

* It doesn't support all the curves we want, and it seems that the main developer isn't interested in adding new curves, e.g., Curve25519.

* It doesn't have ciphers or signature schemes that we need such as RSA, Ed25519, deterministic ECDSA, etc.

> We know the NSA has found weaknesses in certain implementations of elliptic-curve based cryptography in the past

No, we don't.

Even djb wants people to use ECC. Note that End-To-End supports not only NIST's curves but also djb's.

The extension encrypts and saves the drafts in localStorage.

I wrote this blog.

I found the mistakes in other people's code, so I didn't complain for myself.

Ha. This is probably something that we mountain view folks would enjoy working on :-).

I've updated my blog on how to recover the private key from the CRT parameters stored in the private key: http://vnhacker.blogspot.com/2014/04/idea-to-solve-cloudflar.... Trivial math, but still interesting to see how it actually works.