Getting lib sodium and rbnacl to play nice with Heroku has proven to be outright impossible as of now. But I do believe I have fixed the problems you raised.
- The key is not a string, it's generated using PBKDF2_HMAC_SHA1 for 20,000 rounds, and then passed in to the cipher function - where it's SHA256'd. The reason for this is I do plan on having other clients beyond the website (iOS - which is practically finished, Android, etc) where just in case their generated Key happens to be injection-ready code, I'm manipulating it one last time before going in and encrypting/decrypting.
- I'm authenticating the messages based on a server config variable that is an authentication tag like so: SHA256(SERVER_AUTH_TAG + encrypted_data). The openssl version I'm using doesn't have self-built authentication in its AES cipher suites. Is this a good/bad avenue to go down for message authentication? I feel like if someone takes my server and gets the SERVER_AUTH_TAG then there's bigger problems anyways.
- I'm now randomly generating initialization vectors for each piece of encrypted data. So, for an Onion where there's a title and info, the title gets its own IV, and so does the info. When you edit the title, it gets a whole new IV as well.
The thing is, I'm not rolling my own here (minus message authentication, but based on cursory reading, this is how it's done anyways). I'm using standard OpenSSL libraries - things that are vetted, and I'm using like they suggest. Rolling my own was using it without an IV and without message authentication (aka getting it half right). I'm not doing that any more.
Obviously the libraries he suggested are different than the ones I'm using, but that in itself shouldn't be a case for dismissal. The ones I'm using are industry standard. His suggestion uses a different stream cipher and a different key generation scheme, the ciphers and key generation scheme I'm using are what are behind SSL/TLS - something which is not broken. The NSA didn't break this, they bought their way through the crypto, which should tell you something about its strength.
I am generally curious though, to make sure I got what I did right. I think I have - and again the only part I'm not sure about entirely is message authentication. Some places online suggest including the IV in with the authentication. However, since the code is open to the public, and if an attacker were to take my database, they'd have the IV no problem. The only thing they wouldn't have is what I'm signing each message with, the thing that really does the authentication, my server config variable only used for message auth.
- The key is not a string, it's generated using PBKDF2_HMAC_SHA1 for 20,000 rounds, and then passed in to the cipher function - where it's SHA256'd. The reason for this is I do plan on having other clients beyond the website (iOS - which is practically finished, Android, etc) where just in case their generated Key happens to be injection-ready code, I'm manipulating it one last time before going in and encrypting/decrypting.
- I'm authenticating the messages based on a server config variable that is an authentication tag like so: SHA256(SERVER_AUTH_TAG + encrypted_data). The openssl version I'm using doesn't have self-built authentication in its AES cipher suites. Is this a good/bad avenue to go down for message authentication? I feel like if someone takes my server and gets the SERVER_AUTH_TAG then there's bigger problems anyways.
- I'm now randomly generating initialization vectors for each piece of encrypted data. So, for an Onion where there's a title and info, the title gets its own IV, and so does the info. When you edit the title, it gets a whole new IV as well.