Consider Implementing Versioning

[ircmaxell]

Currently, the produced encrypted output includes only the IV, MAC and Ciphertext.

Consider adding a leading byte (packed) which indicates an algorithm version indicator. This will allow upgrades to the algorithm to be detected.

Example: currently, you are using aes-256-ctr-hmac-sha256. But if you want to upgrade to SHA3 at some point, or switch ciphers (due to a flaw, or what have you), you're SOL.

Additionally, fixing crypto weaknesses will be a significant challenge.

So, I would suggest adding a single leading byte to the output, which indicates which of your algorithms you're using.

That way, decrypt needs to handle all of the algorithms (which it can detect since it has the leading byte), but encrypt only needs to support the most recent one.

[narfbg]

... and I probably wouldn't need the inputType constants, which would be great. I'll think about this.

[ircmaxell]

Actually, you would still need them. Because you can't distinguish input that looks like an encrypted value, but wants to be encrypted (say they want to double encrypt for some reason, or the input only looks like an encrypted value.

This is why I raised #2, as it makes things explicit (magic detection is dangerous)...

[narfbg]

Well, at least they could stay the same and I wouldn't need to worry about how to call them when the algorithm changes in the future.