Skip to content

Node-crypto for the browser #432

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
martinheidegger opened this issue Jan 5, 2017 · 3 comments
Closed

Node-crypto for the browser #432

martinheidegger opened this issue Jan 5, 2017 · 3 comments

Comments

@martinheidegger
Copy link

I am trying to get a client-side encryption 🔐 library up and running that works both when Node is a client as well as when the browser is a client.

Unfortunately if I use browserify it will use crypto-browserify which quickly bloats my tiny library to render it cumbersome to load 🚂 (like 250k or so minified for the crypto require statement). I would like this to be faster 🚄 .

I can imagine one of three solutions for this:

  1. Extend the Node.js's crypto API (send a PR) to be more modular in order to be able to decouple all the ciphers:
    var createCipher = require('crypto/createCipher')(require('crypto/cipher/aes256'), ...)
    this way I would only need to bundle the ciphers that I need.
  2. Have an "abstraction"-layer library that works pretty much like the API above except that its not in Node.js and that it falls back on the Node.js implementation. (Does this exist? 🤔 )
  3. Use a crypto-subset library with a browser implementation. (Have they been tested? 💥 )

How do you approach crypto through npm on the browser?
What are good libraries?
Have there been approaches to make this better in the Node API?

@karlpokus
Copy link

What's the use case? If you don't mind me asking.

@martinheidegger
Copy link
Author

@karlpokus My client would like to have a symmetrically encrypted (where the key is not shared over the net; offline handshake) connection on top of https. It is for service accounts where they want to avoid man-in-the-middle attacks.

@karlpokus
Copy link

karlpokus commented Jan 9, 2017

Makes sense. I'd go for solution 1 if that's an option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants