Show HN: Encrypted Communication via GitHub Using Node.js and SSH Keys (opens in new tab)

That is awesome, I love substack, did not realize he had written that. Thanks for sharing!

I like that, send a PR and I'll change it :)

Since I have worked on something similar, in my opinion, it isn't the downloading software that is necessarily a hurdle (although I agree that it is a bit of one); it is around the general difficulty and pain around your local setup and finding the user you are trying to contact's pgp key. This has been discussed at length, but I think it comes down to pgp being enough of a hassle that people who aren't focused on privacy/security don't bother using it.

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.

Maybe GitHub is being treated as a trusted key exchange intermediary?

... but I guess if people want to do that, they can already accomplish it with Keybase. And PGP.

    function encrypt(public_key, file) {
     var pem_pub_key = sshKeyToPEM(public_key); // convert rsa to pem
    
     var chunks = [];
     var buffer = new Buffer(fs.readFileSync(file, 'utf8'));
    
     // work around for 214 character limit for encrypting
     // text with small openssh rsa pub key
     for (var i = 0; i <= (buffer.length / 214); i++) {
      chunks.push(buffer.slice(i * 214, (i * 214) + 214));
     }
    
     chunks.forEach(function(chunk) {
       var encrypted = crypto.publicEncrypt(pem_pub_key, new Buffer(chunk));
       console.log(encrypted.toString('base64'));
     });
    }

According to the docs, crypto.publicEncrypt uses OAEP by default, so the bulk of the terribleness should mainly be how horribly slow this is. It does clearly indicate that the author has no idea what they're doing, though.

Edit: For some reason I thought OAEP included randomness. It does not, which should mean you can guess-and-check the plaintext.

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...

This is unfortunately sort of common. Java's crypto package exposes a similar interface.

What is an ECB-mode RSA? Is it using RSA as a block cipher of blocksize order-1 ? And padding each block and concatenate them?

This is great. Thanks for sharing! I could definitely see building out something similar on top of private-message once I firm up the scripts with a more secure block mode.

Yup! Last time I've tried to use the 2048bit Github SSH key to encrypt some message, gpg would complain if the message is larger than 226 characters.

I ran into this issue, I couldn't encrypt really large strings so I chunked the plain text. Not sure why that is the case. I would consider doing something like what you suggest, though I'm not sure exactly how I'd implement it. If you're interested in showing me how, I'd love to collaborate on some code with you (start an issue! https://github.com/sadasystems/private-message/issues)