Re: client side encryption

On Fri, Jun 7, 2013 at 2:50 PM, Melvin Carvalho <melvincarvalho@gmail.com>wrote:

> But that's a secondary use case for us, due to the security risks of pure
> JS crypto <http://www.matasano.com/articles/javascript-cryptography/>.
>

That article is garbage. "Any attacker who could swipe an unencrypted
secret can, with almost total certainty, intercept and alter a web
request." is simply incorrect: Eavesdropping is trivial. MiTM is difficult.

Diffie-Helman key exchange protects from eavesdropping, and will protect
regardless of what layer it happens at. Doing crypto in Javascript rather
than relying on standard-issue protection of the "s" in https makes a lot
of sense to me. The possible ciphers are not restricted to any standard
set, variety and idiosyncrasies of particular implementations -- that only
have to interoperate with their origin server, using a language with a
strong standard -- might even mitigate MiTM attacks that rely on adherence
to standards.

A communication channel encrypted in javascript can change its encryption
method or other aspects randomly and transparently and instantly;
standards-based crypto simply cannot.


-- 
You've got to wiggle before you can crawl