If anyone here has requested access to App Maker and not received it yet please PM me. SADA Systems (my company) is partnered with google and have been in the early access program for App Maker kicking the tires. We offer app maker development and consulting services for companies looking to deepen their investment in g suite and build cool apps on top of it!
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.
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?
I agree. There are whole classes of problems that are not at all obvious until one has spent time learning how to break bad crypto. Matasano's challenges[0] (which I think tptacek helped create) are a good start.
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 :)
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.
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.
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.
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.
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.
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)
I ended up doing this for a project that I wanted to have use RSA for large chunks of data, for sending it was:
1. Generate random AES cipher key (I used a 16 byte key) using any available secure rng (it all depends on where the thing gets it's entropy, I think node's crypto.getRandomBytes is supposed to be strong)
2. Pad & Encrypt data with AES
3. Encrypt randomly-generated key with RSA
4. Send the message in an envelope like: {key: <RSA encrypted AES key>, data: <AES encrypted data>}
For me, the devil was in the details -- padding took an especially long time for me to understand and solve (the thing I was working on was cross platform, so ruby->js or python->ruby, and of course not all implementations pad the same way), but once that was solved, most other things were easy. The node part was also particularly troubling because I had to deal with the way to specify encodings in node, which was kind of confusing (I spent a lot of time messing with base64/binary encoding and having my terminal start showing gibberish when I tried to print binary data)
I don't have access to that code now (I actually wrote it in order to get around the fact that internal networks at a certain company I used to work at didn't have a custom rootCA/support TLS properly), otherwise I'd just post it.
SADA Systems | Washington D.C. | Full time | On site (though you can wear shorts and have unlimited PTO)
Calling all coders interested in pursuing a ground level opportunity to start the Product Division of SADA Systems, Google’s top partner in the holistic world of ‘Google for Work.’
The ideal candidate will have technical skills commensurate with a professional software developer who has honed their craft over the last 5 to 7 years.
The ideal candidate will have a penchant to lead and mentor members of the product development team.
Your modus operandi will result in the happy byproduct of elegantly simple web applications in alignment with our core vision.
You will be challenged in a cutting-edge environment, and encouraged to refine your skills, share your ideas, and test your creative boundaries.
If you value great design not only in products and their visual presentation, but in your code and technical architecture as well, we want to talk to you.
This sounds a lot like SAML (Security Assertion Markup Language) Alpha = IdP, Beta = Service Provider, Gamme = a user or some server requesting access to Beta's data or services. Alpha would contain a set of ACL's (Access Control Lists) that prescribe what groups / users have access to what content or services on B.