undefined | Better HN

0 pointsthinkloop7y ago0 comments

That article primarily comes down to this:

> WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE? You can. It's harder than it sounds, but you can safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography.

In our case we aren't doing crypto inception where the cryptography is meant to secure itself. The crypto is being served securely (by ssl) and then used to solve the separate unrelated crypto problem of encrypting random files.

0 comments

aij7y ago

That question seems closely tied to

> WHAT'S THE "CHICKEN-EGG PROBLEM" WITH DELIVERING JAVASCRIPT CRYPTOGRAPHY? If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code.

I haven't looked at the details of how Firefox Send works, but if you can download and decrypt the file with nothing more than an https:// URL, it seems like you'd have to trust the server, either to handle the cleartext or to provide trustworthy code to handle the cleartext.

I suppose an alternative would be to generate a data: URL, but if it has to include all the crypto code, I wouldn't expect it to be nice and compact.

hcs7y ago

> I suppose an alternative would be to generate a data: URL, but if it has to include all the crypto code, I wouldn't expect it to be nice and compact.

Sounds like a challenge for the code golfers.

j / k navigate · click thread line to collapse