Hacker News Reader

Comment by itake | Hacker News Reader

Why not use ints and encrypt them when returning them?

That'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.

Maybe 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.

In this scheme, how do you look up a row in the DB by the resulting encrypted ID?

You 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

I would recommend a computed index (given that scheme, if you liked it; I don't, but it doesn't matter).

One 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

Youtube and their python code :) keystore would have helped solve this.

I'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).

I 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.

> 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.

>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.

Reply on news.ycombinator.com