Thanks for the added detail of 3DES, I’ve found a couple of citations now. https://news.ycombinator.com/item?id=25302558 https://news.ycombinator.com/item?id=25

Thanks for the added detail of 3DES, I’ve found a couple of citations now. https://news.ycombinator.com/item?id=25302558 https://news.ycombinator.com/item?id=25302558 claims direct personal knowledge, and is corroborated by a user zellyn who claims on his own site and elsewhere to have worked at YouTube from 2010–2015. Also https://news.ycombinator.com/item?id=27036740 https://news.ycombinator.com/item?id=27036740 with no bona fides. Very good, it seems they did indeed formerly encrypt 64-bit keys, storing the key in the source code (!!), and now instead generate randomly. It sounds to me like they didn’t have any reason to believe the key was compromised (… though with they key in the repository, it’s trivial for a developer to steal, which is why the approach surprises me so—I’d expect it to be a production environment secret), but decided they didn’t like the risk any more. And apparently it took them until 2016 to actually decide to change their approach, a surprisingly long time given that the key must have been so easily available internally. I expect they checked their logs, because the access patterns of anyone attempting even sneaky (distributed and sparse) traversal would stand out like a sore thumb. I’m putting this information and example in the documentation for my scheme, as food for thought. Thanks!