Closed swenson closed 9 years ago
Honestly, I’m not a fan of algorithm agility. If AES-GCM turns out to be broken, it’s going to require more than a version bump to fix. I’m also wary of algorithm downgrade problems.
GCM doesn’t have padding, BTW. It’s essentially just CTR mode with a GHASH of the ciphertext appended.
Sorry, I mean a random nonce.
And a fair point, re: algorithm agility. AES-256 is going to be fine moving forward, though I always worry about block cipher modes, even GCM. But maybe not enough to worry about.
Feel free to close.
I hear you about the cipher modes, but if GCM bites the dust it’ll warrant a special sneaker run-away-from-the-bees
migration command or something.
+1 on adding a sneaker run-away-from-the-bees
/ sneaker thermite
/ sneaker BURN-IT-DOWN
command that just launches a bunch of goroutines and issues all of the delete requests as fast as possible. :)
One suggestion that might make things easier moving forward is to add some element of versioning.
As it is, when you pull down some ciphertext and decrypt your key, you just assume it was encrypted with the current algorithm. That's fine for now, but in time, the algorithm may change, and it would be difficult to tell what a given ciphertext was encrypted with.
The easiest way is to probably just to do something like prepend a byte to the ciphertext, like a
0
, to indicate that we are using AES-256-GCM-with-random-padding. In the future, you can just increment that byte for more options, and add any additional structure you might need then.