5 ms·

I'm on the engineering team at Blockstack, and wrote the client-side encryption functions used by applications. I totally agree with the idea that if software

I'm on the engineering team at Blockstack, and wrote the client-side encryption functions used by applications. 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/encryption.js#L63 https://github.com/blockstack/blockstack.js/blob/master/src/... [2] https://github.com/blockstack/blockstack.js/blob/feature/auth-doc-improvements/src/auth/README.md#app-private-key https://github.com/blockstack/blockstack.js/blob/feature/aut...

peterwwillis 9y ago
Nobody who's serious about security is going to use an app that does crypto in javascript. Why not make browser plugins to avoid this complication? 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.
- rkangel 9y ago
  Is there a fundamental issue with crypto in JS (side-channel attacks?) or is it just that available crypto libraries in JS are immature?
  - cjg 9y ago
    The normal complaint about crypto in JS is that, as a user, I cannot tell what JS is going to be delivered to me this time. Perhaps a security letter forced an update to broken crypto.
    - twiss 9y ago
      In Airborn.io, I've solved this by installing some code in a Service Worker, which verifies all updates: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap... 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 https://github.com/airbornio/signed-web-apps It would be cool if other web apps (including Graphite?) could implement it too.
    - tasn 9y ago
      Shameless plug: I created a browser extension to solve just that: https://github.com/tasn/webext-signed-pages/ 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 https://www.EteSync.com) web client.
    - saas_co_de 9y ago
      This is solved: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... 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.
      - peterwwillis 9y ago
        From https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... "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.

peterwwillis 9y ago

Nobody who's serious about security is going to use an app that does crypto in javascript. Why not make browser plugins to avoid this complication? 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.

rkangel 9y ago
Is there a fundamental issue with crypto in JS (side-channel attacks?) or is it just that available crypto libraries in JS are immature?
- cjg 9y ago
  The normal complaint about crypto in JS is that, as a user, I cannot tell what JS is going to be delivered to me this time. Perhaps a security letter forced an update to broken crypto.
  - twiss 9y ago
    In Airborn.io, I've solved this by installing some code in a Service Worker, which verifies all updates: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap... 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 https://github.com/airbornio/signed-web-apps It would be cool if other web apps (including Graphite?) could implement it too.
  - tasn 9y ago
    Shameless plug: I created a browser extension to solve just that: https://github.com/tasn/webext-signed-pages/ 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 https://www.EteSync.com) web client.
  - saas_co_de 9y ago
    This is solved: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... 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.
    - peterwwillis 9y ago
      From https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... "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.