[ryan-c]

    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.

[tptacek]

OAEP doesn't allow you to encrypt variable-length data. They may very well be using OAEP, but that's not my point.

[ryan-c]

It's awful crypto and it made me throw up in my mouth a little bit. They should be using RSA to encrypt a random key then encrypting the rest of the message with some sort of authenticated encryption.

[jlank]

Sorry I made you barf ryan-c. If you have any interest in making this better I'd be willing to convert your constructive criticism into code. Issues are open on GH :)

[tptacek]

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 cryptography, I think you really need to work with a high-level library. Nacl (or libsodium) is a great example of a package that goes out of its way to bulletproof itself.

[RyanZAG]

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/java-aes-crypto

[sdevlin]

I don't know if I would characterize NaCl as "enormous". TweetNaCl is literally two files. Libsodium has a bigger footprint, but it also seems to have bindings for pretty much every language. I would think it's pretty easy to integrate.

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.

[tptacek]

Please don't use this library. Nacl is much safer, and in fact smaller.

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.

[sarciszewski]

What do you mean enormous dependencies? NaCl is fast, lightweight, and standalone. Libsodium has more features, but is portable and easier to use.

[jlank]

Absolutely a learning experience, this is why I posted it to HN. Really appreciate your feedback and everyone else's - it has been tremendous. Also thanks for the note on Nacl and libsodium, I will look into those.

[ryan-c]

It should probably have a big fat "I wrote this to learn, it's probably not secure" banner at the top of the readme.

[sarciszewski]

You won't be disappointed.