4 ms·

So the reasoning makes it sound like there was potentially an exploit that made it easy to find unlisted videos? Were the video IDs deterministic perhaps?

by judge2020 5y ago

carl_dr 5y ago
Maybe their old scheme, when divided by the number of videos, was getting to the point where it was feasible you could brute force finding unlisted videos. The old scheme had 7.3 x 10^19 ids (11 chars, base 64, thanks Tom Scott!). Suspiciously close to the max value of a 64-bit int, hmmm … Assume a billion videos and you’re down to 10^10 - a one in a 10 billion chance isn’t much chance, but it’s far from secure. (I’m ignoring the fact that only a small %age of videos are unlisted I guess, but I think the point still stands.)
quantumofalpha 5y ago
Yes, exactly. Video ID is just a base64'ed DES-encrypted primary int64 video key from MySQL. It used to be sequentially incremented until at some point they switched to randomly generated primary keys. Any (ex-) engineer who snapped a copy of the encryption key (it used to sit right in the code for anyone to see) can enumerate all videos from YT until that moment, including unlisted - which are only protected by secrecy of that one key. If the key leaks, then also anyone in the world can. That's what they are afraid of here. Source: worked for YT.
- ktm8 5y ago
  Just for curiosity, how would YT deal with ID collision ? Edit: Before the scheme change I mean
  - root_axis 5y ago
    Try again? Just a guess.
  - remram 5y ago
    Probably they just roll again. You can even implement that in a stored procedure.
  - quantumofalpha 5y ago
    Not sure about technical details for that but perhaps something like https://vitess.io/docs/reference/features/vitess-sequences/ https://vitess.io/docs/reference/features/vitess-sequences/. Vitess itself is a project that grew out of YouTube's needs to scale and shard their MySQL DB.
  - Thorrez 5y ago
    >base64'ed DES-encrypted primary int64 Block ciphers (such as DES) don't collide. If they did there would be no way to decrypt them because a block could be decrypted into multiple valid plaintexts.

So the reasoning makes it sound like there was potentially an exploit that made it easy to find unlisted videos? Were the video IDs deterministic perhaps?

carl_dr 5y ago

Maybe their old scheme, when divided by the number of videos, was getting to the point where it was feasible you could brute force finding unlisted videos. The old scheme had 7.3 x 10^19 ids (11 chars, base 64, thanks Tom Scott!). Suspiciously close to the max value of a 64-bit int, hmmm … Assume a billion videos and you’re down to 10^10 - a one in a 10 billion chance isn’t much chance, but it’s far from secure. (I’m ignoring the fact that only a small %age of videos are unlisted I guess, but I think the point still stands.)

quantumofalpha 5y ago

Yes, exactly. Video ID is just a base64'ed DES-encrypted primary int64 video key from MySQL. It used to be sequentially incremented until at some point they switched to randomly generated primary keys. Any (ex-) engineer who snapped a copy of the encryption key (it used to sit right in the code for anyone to see) can enumerate all videos from YT until that moment, including unlisted - which are only protected by secrecy of that one key. If the key leaks, then also anyone in the world can. That's what they are afraid of here. Source: worked for YT.

ktm8 5y ago
Just for curiosity, how would YT deal with ID collision ? Edit: Before the scheme change I mean
- root_axis 5y ago
  Try again? Just a guess.
- remram 5y ago
  Probably they just roll again. You can even implement that in a stored procedure.
- quantumofalpha 5y ago
  Not sure about technical details for that but perhaps something like https://vitess.io/docs/reference/features/vitess-sequences/ https://vitess.io/docs/reference/features/vitess-sequences/. Vitess itself is a project that grew out of YouTube's needs to scale and shard their MySQL DB.
- Thorrez 5y ago
  >base64'ed DES-encrypted primary int64 Block ciphers (such as DES) don't collide. If they did there would be no way to decrypt them because a block could be decrypted into multiple valid plaintexts.