You should consider with RSA keys have a limited size message that can be encrypted (e.g. for 2048 bit keys you are limited to 256 bytes in your message). My solution was to use the SSH key to encrypt the secret I used to encrypt the message with.
Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
31–40 of 47 posts
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#32Earlier quoted context omitted.
There are a whole bunch of things you're likely to get wrong trying to design your own "hybrid" encryption system. It's not easy. Why not spend some time learning how to break crypto before you start building it?
Do you have any specific resources that you can recommend for learning to break crypto?
- https://www.crypto101.io/ both the presentation and the book.
I think those are good to begin with.
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#33Earlier quoted context omitted.
I love this comment. Thank you for putting the time in to proposing a more thorough solution. I will take this (and other) comments into consideration, and make some much needed improvements :)
There are a whole bunch of things you're likely to get wrong trying to design your own "hybrid" encryption system. It's not easy. Why not spend some time learning how to break crypto before you start building it?
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#34I have also built something similar, I knew of the existence of cipherhub, but my goal was to focus on the ease of use, with the browser ( https://mailbeam.io and https://github.com/bobbywilson0/gh-message ). I do admit that my solution is not as easy as it should be yet. You should consider with RSA keys have a limited size message that can be encrypted (e.g. for 2048 bit keys you are limited to 256 bytes in your me…
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#35Earlier quoted context omitted.
Can you take this as a learning experience? 1. Tools to encrypt messages using Github SSH keys are probably not a good idea. They're no more usable than real message encryption solutions, but have far more constraints. 2. You cannot safely use RSA like a normal cipher. RSA is a tool for building crypto protocols. The way you've deployed it here has a serious vulnerability. If you want to build things that use cryptog…
Agree on higher level libraries being necessary - but Nacl or libsodium? Those are some enormous dependencies you're talking about here. I'd say we need more effort on small, focus built libraries for tasks such as these. You can talk about how people need to add in Nacl into their project, but actually doing that is simply not possible for many developers. eg, more libraries like this one: https://github.com/tozny/j…
If you're worried about size, use Tweetnacl:
TweetNaCl is the world's first auditable high-security cryptographic library. TweetNaCl fits into just 100 tweets while supporting all 25 of the C NaCl functions used by applications. TweetNaCl is a self-contained public-domain C library, so it can easily be integrated into applications.
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#36To function, both the reader and writer have to download special software. If you're going to do that, why not just have both sides download PGP?
With ssh keys, at least we can assume that if someone has a github account they have a private ssh key, and it is accessible through the github api. With pgp there isn't a guarantee that they even have a pgp key, and accessibility is on the users themselves to publish it in some way. I think that keybase.io has tried to become the go-to spot for pgp keys, but the adoption is nowhere near what github has, and again, someone has to be interested in privacy/security to want to do this as well.
I mean with all do respect that you are correct in terms of a better protocol, and that there are tools that exist that already do this. The concern that I think OP and myself are interested in solving is creating something that is quick, easy, and piggie-backs on top of the huge github userbase and provides a base level of encryption.
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#37Earlier quoted context omitted.
Can you take this as a learning experience? 1. Tools to encrypt messages using Github SSH keys are probably not a good idea. They're no more usable than real message encryption solutions, but have far more constraints. 2. You cannot safely use RSA like a normal cipher. RSA is a tool for building crypto protocols. The way you've deployed it here has a serious vulnerability. If you want to build things that use cryptog…
Agree on higher level libraries being necessary - but Nacl or libsodium? Those are some enormous dependencies you're talking about here. I'd say we need more effort on small, focus built libraries for tasks such as these. You can talk about how people need to add in Nacl into their project, but actually doing that is simply not possible for many developers. eg, more libraries like this one: https://github.com/tozny/j…
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#38I have also built something similar, I knew of the existence of cipherhub, but my goal was to focus on the ease of use, with the browser ( https://mailbeam.io and https://github.com/bobbywilson0/gh-message ). I do admit that my solution is not as easy as it should be yet. You should consider with RSA keys have a limited size message that can be encrypted (e.g. for 2048 bit keys you are limited to 256 bytes in your me…
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#39Earlier quoted context omitted.
It doesn't appear to be a new implementation. It looks like it uses Node's crypto lib: https://nodejs.org/api/crypto.html#crypto_crypto_publicencry... Not sure why it says DSA is supported, the crypto library only supports RSA. It uses this library that stitches together a PEM from an ssh public key: https://github.com/dominictarr/ssh-key-to-pem/blob/master/in...
It appears to be using Node's crypto library to apply the RSA transform directly to the plaintext in modulus-size chunks. The problem isn't the quality of the RSA implementation.
Re: Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys
#40Earlier quoted context omitted.
Can you take this as a learning experience? 1. Tools to encrypt messages using Github SSH keys are probably not a good idea. They're no more usable than real message encryption solutions, but have far more constraints. 2. You cannot safely use RSA like a normal cipher. RSA is a tool for building crypto protocols. The way you've deployed it here has a serious vulnerability. If you want to build things that use cryptog…
Agree on higher level libraries being necessary - but Nacl or libsodium? Those are some enormous dependencies you're talking about here. I'd say we need more effort on small, focus built libraries for tasks such as these. You can talk about how people need to add in Nacl into their project, but actually doing that is simply not possible for many developers. eg, more libraries like this one: https://github.com/tozny/j…
I definitely do not think the proliferation of unvetted, anonymous crypto libraries is a good thing. How many people have the expertise to write this kind of thing? How many have the expertise to evaluate its quality?
For example, the documentation for the linked library says: "we've also added integrity checking in the form of a SHA 256 hash." This is a huge red flag: hashes provide integrity, but not authenticity, which is really what you want here. But then you go and look at the source code and find that they are actually using HMAC-SHA256, which does provide authenticity. So the documentation is not an accurate description of what's going on, and you need to go and look at the source to find out that it really is okay (in this particular aspect, though it doesn't inspire confidence for the future).
My point is not to say that this particular library is terrible or anything. Just that we have limited resources, and we're better off consolidating to a very small number of solutions designed, written, and validated by experts.