Show HN: Home-made crypto in the browser | Hacker News Reader

Show HN: Home-made crypto in the browser

requirebin.com

37 pointsprojectant32 comments

Usual caveats for home-made crypto apply.

TL;DR - treat this as you would home-made beer from someone you don't know. You'd probably hold it at arms length, have a smell, and maybe try the taste...but you wouldn't start selling it in your hip bar without knowing anything about it!

Anyway, hope others interested in crypto can enjoy this. I am not a crypto-expert, just a moderately-talented-at-crypto-hobbyist, or somethin. Code: https://github.com/dosyago-coder-0/dosycrypt

And the usual caveats for in-browser encryption apply. Namely that the trust model is no different from temporarily handing the encryption keys to the server.

In the latter case you trust the server to discard the keys after them being used. In the former case you trust the server to not transiently serving you javascript that exfiltrates the keys. In both cases this trust has not just to be extended once (which would make things auditable) but during every single transaction.

> Namely that the trust model is no different from temporarily handing the encryption keys to the server.

True in this case, but not necessarily true. IPFS[0] allows you to ensure that the content you're receiving is correct (if you run a local gateway, which you should), because the URL is basically a content hash.

Therefore if you know the code is secure in the first place, you can always visit the same URL and know that you're getting "safe" code that doesn't exfiltrate the keys or plaintext. This then presents the same trust model as running code locally, except you don't need to install anything: you just visit the correct URL, and the code is running, with all the same trust as it would have if you downloaded it and kept it safe from modification.

[0] https://ipfs.io/

Things get a little better if you use the new Web Crypto APIs. They can act kind of like a virtual hardware security module from a web page's point of view: with the web crypto API, you can create and use an encryption key (symmetric or asymmetric) whose key material can never be exposed to javascript. The browser keeps the key material completely private from the web page, but lets the web page use the key for certain crypto operations.

This means that if a website uses this and generates a key through the Web Crypto API on the first access, the user only needs to trust the site on the first access (to serve javascript that actually uses the Web Crypto API) in order to trust that the key material stays safe. (However, if the website admin turns evil and wants one of the user's files to be decrypted, they could serve javascript to the user that silently makes them decrypt the file for the admin, so the problem isn't completely solved.)

This is far from true. Client-side crypto at least gives you the ability to inspect outgoing network traffic. This should help to keep site operators honest.

The site operator can of course nefariously and randomly serve JS that exfiltrates keys, but users at least have the _ability_ to audit every single transaction.

The Web is terrible for secure crypto, the best you can do is session secrets. However, they're working on a new standard that will finally allow you to store private keys securely. Until then, write your own native apps with webviews and browser extensions with local js that can be audited.

> However, they're working on a new standard that will finally allow you to store private keys securely.

Could you link to some more reading on this?

That I assuming that every type network request is covered by available monitoring tools and that they are user-friendly. What if web browsers allow you to trigger DNS lookups without HTTP requests? That could already be used to exfiltrate data.

> What if web browsers allow you to trigger DNS lookups without HTTP requests?

Just include hidden links in the page, most browsers have some sort of pre-fetch optimization that does exactly that. I think they make HTTP connections on hover even.

Meta DNS prefetch tags allow this.

I've been working on using Service Workers to solve that problem: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...

I'm planning on making a library to make it easy to make a web app trust-on-first-use. The main blocker is https://github.com/w3c/ServiceWorker/issues/1208 (which would fix the non-critical but less-than-ideal issue described under "Service Worker lifecycle" in the blog post).

Trying to achieve the trust you are is very interesting.

I put up a simple, installable, progressive offline app of this crypto here: https://semocracy.com/

This app doesn't yet contain the mediations you talk about of checking the sw code against a 3rd-party reference and warning when an update doesn't match the reference.

Even considering the limitation you discuss when the new worker terminates async requests of the old worker, checking a public log is useful -- do you have any code or boilerplate I could plug in to achieve that?

Also, would the following be useful? The worker stores the 3rd party log / reference at intervals in local storage, and then when updatefound occurs, it doesn't need to make a network request, it can check (not perfectly) if the new sw code matches the stored reference. Sometimes there will be false negatives because the reference updated before the sw checked, but I think there would be no false positives. As long as the new worker can't get to localstorage before the old one checks, could be okay.

> do you have any code or boilerplate I could plug in to achieve that?

My implementation is at [0]. It basically fetches a list of files and hashes from GitHub, based on the commit in the X-GitHub-Commit response header (but you could just fetch master instead). You'd have to replace that github url at the top with [1], and update the two functions near the top. (If you're gonna fetch from master, also make the caching in getGitHubResponse less aggressive.)

Also take a look at main.js and main.css in that commit, it contains code to notify the user.

> it can check (not perfectly) if the new sw code matches the stored reference

The problem is that currently, there is no way to get the new service worker code without a request. Even if the sw.js file is in cache, there is still a race condition between the cache responding and the new sw terminating the old one, and more often than not, the new sw wins. That's why I was talking in [2] about an alternative solution of adding a property somewhere that gives you the new sw code.

What you can also do, and which I'm doing, is to fetch the sw.js file in the updatefound event of the page, and not of the old service worker. However, it's not strictly guaranteed that there is a (visible) page, for example, a third-origin website could embed yours in an iframe, triggering an update. [3]

[0]: https://github.com/airbornos/airborn-server/commit/a740276b#...

[1]: https://api.github.com/repos/dosyago-coder-0/dosycrypt-progr...

[2]: https://lists.w3.org/Archives/Public/public-webapps/2017JulS..., near the bottom

[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=773307, haven't filed a spec issue for this yet because https://github.com/w3c/ServiceWorker/issues/1208 hasn't gotten any replies yet

I made up a proverb that probably was already invented elsewhere: "everyone should write their own crypto, but no one should use home made crypto"

Thanks for introducing me to RequireBin. Love the gist recognition ;)

http://requirebin.com/

Another in-browser crypto project based on TweetNaCl:

https://github.com/Spark-Innovations/SC4

SC4 has undergone a security audit.

It’s also non-free (and under a license that is distinctly not made for code.)

> It’s also non-free

Not true. And if there something you don't like about the licensing, it would be more constructive to begin by asking the author privately if they'd be willing to change the license terms rather than complain about it on a public forum.

Yes, it is non-free. I’m not sure what the question is here: it’s well established that CC BY-NC-SA is non-free. The public domain portion is just the TweetNaCl piece it subsumes.

The purpose of talking about it is to warn off someone who might otherwise integrate it into their product. I don’t see this as complaining!

It's free for non-commercial purposes. But yes, it's true that if you want to use it in a commercial product you'll have to work out some other arrangement.

CC BY-NC-SA does not permit the use of the software for commercial purposes. Thus it is not free for commercial purposes. This violates a few generally accepted principles of software freedom:

* Freedom 0 of the Free Software Definition: The freedom to run the program as you wish, for any purpose (freedom 0).

* Point 6 of the Debian Free Software Guidelines (DFSG): No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

* Point 6 of the Open Source Definition (OSD): No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

FSD: https://www.gnu.org/philosophy/free-sw.en.html

DFSG: https://www.debian.org/social_contract#guidelines

OSD: https://opensource.org/docs/osd

Fair enough. I have added the GPLv3 as an option.

Hence, non-free. Perhaps we are having a language confusion; here, I mean free as in freedom, not as in beer.

Fair enough. I have added the GPLv3 as an option.

Software that is free only for non-commercial purposes is considered to be non-free software.

Fair enough. I have added the GPLv3 as an option.

France, and many other jurisdictions, don't recognise the concept of releasing directly into the public domain, so in this case would leave you high and dry in the future theoretical of the original author changing his mind about your use of his library.

If people really want to release into the public domain, public domain with French exceptions like CC0 are the best option.

TweetNaCl-js is under such a "public domain with fallback" license, so I'm not sure what you are complaining about.

(And even if it weren't, pure use is not as critical as e.g. wanting to contribute to it)

It is unlikely in the extreme that DJB would ever try to enforce the copyright on TweetNaCl. But yes, if you want to use SC4 in France, I guess that's a risk you'll have to take. There's nothing I can do about that.

don't the major browsers have apis to built in crypto libraries - you can basically ask for many operations from JS?

They do: https://caniuse.com/#feat=cryptography

From that page: "Many browsers support the crypto.getRandomValues() method, but not actual cryptography functionality under crypto.subtle. "

Reply on news.ycombinator.com