4 ms·
Yep have used an approach just like that, worked quite well if you have a strong pattern to easily translate from one to the other. Gives you an id with the rig
by nhoughto 3y ago
Yep have used an approach just like that, worked quite well if you have a strong pattern to easily translate from one to the other. Gives you an id with the right properties for internal use, efficient indexing etc, and in its encrypted form gives you the properties you want from an external identifier being unpredictable etc, all from one source id.
It is true that now your encryption key is now very long lived and effectively part of your public interface, but depending on your situation that could be an acceptable tradeoff, and there are quite a few pragmatic reasons why that might be true as has been described by other comments.
Edit: you can even do 64bit snowflakes internally to 128bit AES encrypted externally, doesn’t have to be 128-128 obvs
- phkahler 3y ago>> It is true that now your encryption key is now very long lived and effectively part of your public interface No need to encrypt, just store the external key in a table. Not that you're likely to change algorithms.
- phkahler 3y agoLate edit: I meant to say No need to encrypt on the fly. Do it once and save it.
- nhoughto 3y agoTrue you could rotate by persisting the old value and complicate your lookup/join process, not my idea of an acceptable solution but yep totally possible and worth it for some set of tradeoffs.
- kevincox 3y agoYou are basically describing BuildKite's previous solution.