"Are End-To-End security bugs eligible for Google’s Vulnerability Rewards Program?
Yes, we have specifically expanded the scope of our Vulnerability Rewards Program to include End-To-End. This means that reports of exploitable security bugs within End-To-End are eligible for a reward."
Should be an interesting trove of JS tricks:
"JavaScript crypto has very real risk of side-channel attacks
Since JavaScript code doesn't control the instructions being executed by the CPU — the JavaScript engine can perform optimizations out of the code’s control — it creates the risk of security-sensitive information leaks.
End-To-End requires user interaction for private operations in normal use, mitigating this risk. Non-user-interaction actions are rate-limited and done in fixed time. End-To-End’s crypto operations are performed in a different process from the web apps it interacts with.
The End-To-End library is as timing-aware it can be and we’ve invested effort to mitigate any exploitable risk."
Well if you're encrypting your email on your local PC and an attacker can conduct a side-channel attack then you're boned already. Your PC must be secure to begin with otherwise no crypto is going to save you. If an attacker can side-channel this encryption then he can probably just straight-up read your keystrokes or hard drive.
I think you're both right. There are side channel attacks against remote hosts (timing-based padding oracle attacks agains TLS come to mind). But for the case of PGP, which is mostly for encryption at-rest, attacks like this don't seem as relevant. I say seem as relevant, because crypto attacks can be surprising :)
BEAST is a design bug, insecure use of CBC mode. CRIME is a side channel attack, but the side channel that leaks information (compressed cleartext size) is not related to the language used, but again to the design of the algorithm.
The basic idea is that implementation-related side-channel attacks, such as timing and power draw, are very hard to exploit remotely. I guess you could write a JavaScript implementation of AES that is so bad that key-dependent multimillisecond jitter can be measured remotely. But it's almost impossible to do it by mistake.
The real problems of JavaScript are it's highly malleable runtime that offers no guarantees, everything is writable. So you need to improve browser support before you can write JavaScript crypto, that's why this is a great project: Google has the ability to change Chrome into a secure end-to-end platform, should they want that.
Looks like they're taking it seriously:
"Are End-To-End security bugs eligible for Google’s Vulnerability Rewards Program?
Yes, we have specifically expanded the scope of our Vulnerability Rewards Program to include End-To-End. This means that reports of exploitable security bugs within End-To-End are eligible for a reward."
Should be an interesting trove of JS tricks:
"JavaScript crypto has very real risk of side-channel attacks
Since JavaScript code doesn't control the instructions being executed by the CPU — the JavaScript engine can perform optimizations out of the code’s control — it creates the risk of security-sensitive information leaks. End-To-End requires user interaction for private operations in normal use, mitigating this risk. Non-user-interaction actions are rate-limited and done in fixed time. End-To-End’s crypto operations are performed in a different process from the web apps it interacts with. The End-To-End library is as timing-aware it can be and we’ve invested effort to mitigate any exploitable risk."