3 ms·
The encryption implementation suggested seems overkill and problematic as it increases the size of the ID. UUID is 128 bit which is the same block size as AES.
by tgma 1y ago
The encryption implementation suggested seems overkill and problematic as it increases the size of the ID. UUID is 128 bit which is the same block size as AES. You can simply apply AES to transform the input block with a secret key to and directly expose the result. No need for CBC mode or IVs etc as it is desirable for the same input to map to the same output all the time.
- londons_explore 1y agoNow you have a secret key that must live in every web server yet can never be rotated. That's a different kind of maintenance nightmare.
- ianburrell 1y agoThe solution is to use hash function. It is fine to cut down hash output so 128-bit from SHA-1 would be fine.
- tgma 1y agoHow would you look up the key if it is passed it back to you from another API? It won't be reversible. If you want to persist two keys, you might as well generate a random second key and persist that. No crypto shenanigans needed.
- tgma 1y agoThat limitation is present in the CBC mode solution presented as well. A random IV will not help you avoid "key rotation" if that's a design requirement. By design, you won't want to rotate the key as the encrypted UUID will likely be stored in external places to refer to the specific user and it cannot change unless you basically persist the encrypted ID somewhere, in which case you might as well have two IDs, one completely random.