3 ms·
Why not use ints and encrypt them when returning them?
by itake 6y ago
Why not use ints and encrypt them when returning them?
- kebman 6y agoI'm not an expert, but here's some conserns I'd have: Because the returned payload isn't necessarily uniform. Because you aren't guaranteed uniqueness (or that guarantee is mathematically lower). And because the overhead for doing it that way may be too high (we want to achieve it in a way that is computationally light, and most encryption isn't).
- antoinealb 6y agoI am not sure what your concern ab ou it uniqueness is: encrypti on has to be invertible, therefore if each non encrypted integer is unique, it means that each encrypted representation is also unique. w.r.t encryption cost, I think AES is very cheap on modern hardware compared to the cost of SQL or the overhead of writing your app in an interpreted language.
- holtalanm 6y ago> Because you aren't guaranteed uniqueness If your encrypted value is not unique, then your encryption algorithm is broken. You have to be able to turn the encrypted value back into the unencrypted value. if you have two unique unencrypted values that result in the same encrypted value, then that essentially makes it impossible to unencrypt.
- layoutIfNeeded 6y ago>Because the returned payload isn't necessarily uniform Wrong. Flipping a single plaintext bit flips all ciphertext bits with 50% probability. >Because you aren't guaranteed uniqueness Wrong. Encryption is bijective. >And because the overhead for doing it that way may be too high Wrong. Symmetric ciphers are extremely fast.
- tmpyt 6y agoThat's exactly what youtube originally did - video id is just an encrypted (3DES, iirc) 64-bit sequential primary key straight from mysql database. You can convert it back and forth. Problem: if you know the encryption key (it was sitting right there in the code for all devs to see, easy to steal) you could enumerate all the YT videos, including all unlisted videos. At least until a few years ago - they've since switched to random database keys instead of autoincrement to fix this exact hole. Source: worked there.
- shawnz 6y agoMaybe you could split the ID into two parts: the first is an encrypted integer representing the DB row, the second is a "password" for the video. Then you get fast indexing but you still can't enumerate videos without the ID.
- firloop 6y agoIn this scheme, how do you look up a row in the DB by the resulting encrypted ID?
- shawnz 6y agoYou store the key in the source code as in the other poster's description of Youtube 1.0. So employees/contractors/etc could still see the number of total videos and sequential order of uploads, but at least they can't enumerate them. You could also maybe rotate the key once in a while, but only for videos created after the rotation, and indicate the "key version" with a third field in the video ID
- saurik 6y agoI would recommend a computed index (given that scheme, if you liked it; I don't, but it doesn't matter).
- zellyn 6y agoOne of my hobbies when working at YouTube was to periodically search the monorepo to find new copies of the key, and try to refactor code so there was just one implementation in each of C++, Java, Python, Go
- tehlike 6y agoYoutube and their python code :) keystore would have helped solve this.