librelist archives

« back to archive

On a JS Crypto Frontend (Was: Getting enough users)

On a JS Crypto Frontend (Was: Getting enough users)

Tom Ritter
2011-06-28 @ 16:16
Hash: SHA1

> > Not two weeks I argued against javascript crypto.  But I think it can be
> > 'good enough'.

> What were your arguments against and what made you change your mind?

> I usually argue against JS crypto, because one needs a secure way to
> deploy the code to the client. In most cases this way is a
> SSL/TLS-connection.

*This* is the correct argument against JS Crypto.  There's soooo many
browser quirks, insecure content issues, SSL & CA mistrust that
results in JS Crypto being a poor solution.  I've never changed my
mind about that.  But I do think if you accept and try to mitigate
those risks, you can come up with a solution that is 'good enough' for
_most_ users.  And for users where the government co-opting CAs,
middling traffic, and blowing SSL 0-days is a real concern, they
should *definetly* use client-side solutions whereever possible.   In
the event they can't (need for deniability, can't get the software,
etc) they can take steps to manually verify the JS Crypto solution
before using it.

> But then the connection is encrypted and to me it
> doesn't make sense to send encrypted data over a encrypted line. (very
> short version of the argument). But maybe there other/better arguments
> in favor of use of JS crypto.

This is a poor argument.  And in fact I sparked *just this debate* on
a crypto list the other week: Check the thread Repeated Encryptions
Considered.... ? at

The summary is, as long as repeated encrypted (like PGP over SSL or
JS-Crypto over SSL) are *entirely unrelated* so no related-key attacks
could be mounted - it's totally fine.  It *may not* strengthen the
data against attacks, it may very well only be as strong as the weaker
of the two cryptosystems used - but the double-encryption doesn't
weaken it.  As Marsh said: If encrypting something again weakened it,
an attacker would just do that.

JS-Crypto gives client-side encryption, for confidentiality, never
sending the data out to the network unencrypted.  SSL for Integrity -
ensure the crypto code hasn't been tampered with in transit.  And
either SSL or manual verification for authentication - make sure the
perso sending you the crypto code is legit.

Of course, this also assumes you have a very coode developer and
cryptographer writing the code in the first place.

- -tom
Version: GnuPG v1.4.9 (Cygwin)