I totally agree with the idea that if software uses encryption, it should be documented, open-source, and ideally use a standard encryption protocol. Being able to say "this is exactly how encryption works" in a system is important, and I'm glad you're asking these questions.
Encryption in Blockstack apps is performed client-side via library calls in blockstack.js (our javascript library). The encryption routines are implemented here [1], and implement ECIES, using the user's application-specific private key. That private key is passed to an application during the application authentication process [2]. All a blockstack application has to do is pass { "encrypt": true } in the storage routines, and this is invoked.
We definitely would like to provide better documentation and messaging around how applications engage and use our client libraries -- and documenting our encryption routines is part of that. However, in the meantime, you can feel free to check out or codebase (it's all open source), and we'd always welcome any kind of feedback!
[1] https://github.com/blockstack/blockstack.js/blob/master/src/...
[2] https://github.com/blockstack/blockstack.js/blob/feature/aut...
Not to mention, if browser makers take their existing browser storage functionality and make more flexible interfaces for them, your app will be kind of useless, as the browser could sync user data with arbitrary cloud providers.
The SW stays installed for when you open the web app the next time, in essence making it a trust-on-first-use scheme.
I'm working on a library: https://github.com/airbornio/signed-web-apps
It would be cool if other web apps (including Graphite?) could implement it too.
If you really care you can check the integrity hash on your scripts before using every time.
That gives you more security than the update in your OS or Browser so they are a weaker link.
"OK, THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE FROM THE SAME SERVER SO THE CODE CAN VERIFY ITSELF."
"This won't work."
Your comment that "That gives you more security than the update in your OS or Browser" is patently false, I don't know why you'd suggest that.
1) Javascript is open source and you can audit the code you are running.
2) You can save the HTML of a page and run your local copy so that you know the JS can't change or check the hash every time
Can you audit the code of your OS or Browser? In theory, if you are on Linux, but in practice it is too complex and voluminous for one person to do.
A browser based app is usually in the thousands of lines of open source code running in a sandbox that is very easy to debug.
The browser environment is the most secure and most easily user auditable environment there is.
Unless you expect all of your users to build your app from source on linux that they built from source you can't really get better security.
"Javascript Cryptography Considered Harmful" is old FUD. It was barely coherent when first published and the only legitimate arguments it had have been fixed.
You forgot to tack on "using compilers, etc., that they also built from source".
I created a browser extension to solve just that: https://github.com/tasn/webext-signed-pages/
It lets devs PGP sign their web apps and verifies those signatures. We use it for the EteSync (https://www.EteSync.com) web client.
FTA: WHAT'S HARD ABOUT DEPLOYING JAVASCRIPT OVER SSL/TLS?
You can't simply send a single Javascript file over SSL/TLS. You have to send all the page contentover SSL/TLS. Otherwise, attackers will hijack the crypto code using the least-secure connection that builds the page.
---- Seriously? Serving entire websites over https is the norm these days. It appears as though the article has been added to but not updated. Current advocates should re-read the article.
- The article reads like those arguments we have in our heads where we always win.
- The article is from 2011
- The article says "come back in 10 years when people aren't running browsers from 2008"
(we're not to 2021 yet but the majority of browsers are evergreen now)
- We have SubtleCrypto now
- We have SubResourceIntegrity
- We have CORS and CSP
It's like a Cloud OS. If my whole OS is running in the cloud, you can claim it's secure, "because crypto". But it's still actually running on a random pizza box in one of Google's datacenters. There's like 10 layers of trust and assurance needed between them and me.
If my OS is running on my laptop, I only need to trust ME, and maybe Intel's dodgy engineers, and whoever wrote the rest of what's running on my laptop. The control over the security of the system stays in my hands.
That is the basic trust problem, and on top of that are all the other technical problems that make client-side javascript crypto untrustworthy. Even if you solved all the other technical problems, I still don't trust what you are delivering to me more than I trust code that lives on my machine, designed by cryptographers to the highest standards of consumer security.
I’ve checked the following resources:
* The Blockstack whitepaper: https://blockstack.org/whitepaper.pdf
* Each of the System Design documents listed here: https://github.com/blockstack/blockstack-core/tree/master/do...
* Blockstack General FAQ: https://blockstack.org/faq
* Blockstack Technical FAQ: https://github.com/blockstack/blockstack-core/blob/master/do...
* Blockstack Repository Readme: https://github.com/blockstack/blockstack-core
* The Graphite FAQ: https://www.graphitedocs.com/faq
* The Graphite Features: https://www.graphitedocs.com/features
This is a red flag. “Encryption” is far too unspecified. I’m looking for specific primitives, constructions, algorithms and design decisions. I want to know how key exchange happens, if a library like libsodium is used, whether you’re using AES-GCM or ChaCha-Poly1305, etc. I’m looking for an architecture diagram to understand which of these questions is coherent. Is key derivation used? Under which algorithm? I’m assuming your IDs are SHA-256 hashes, but is that correct? I don’t know.
Basically, aside from saying there are “ECDSA private keys” in passing, how precisely does encryption, key exchange and digital signing work? Maybe I missed a pretty obvious explanation in here - I was reading quickly (though pointedly). However, if that’s the case then mea culpa, and it should be easy to rectify by pointing out where exactly I missed this documentation.
For reference, here are examples of documentation I’m looking for[1]:
* Restic, under “Keys, Encryption and MAC”: https://restic.readthedocs.io/en/latest/100_references.html
* Wireguard: https://www.wireguard.com/protocol
A basic overview of each primitive with a brief explanation of why it was chosen would go a long way here. I understand if Graphite is too young for this (though this should be a priority), but Blockstack should absolutely have something like this documented poignantly. If Blockstack does have this documented, Graphite should really link to it (poignantly).
________________
1. I have no affiliation with either of these, though I personally use them, and they’re not competitors anyway.