Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Just for curiosity, how would YT deal with ID collision ?

Edit: Before the scheme change I mean


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


Not sure about technical details for that but perhaps something like 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.


Probably they just roll again. You can even implement that in a stored procedure.


Try again? Just a guess.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: