Internal API for generating semi-random salt (#11331)
Summary: ... so that a non-cryptographic whole file checksum would be highly resistant to manipulation by a user able to manipulate key-value data (e.g. a user whose data is stored in RocksDB) and able to predict SST metadata such as DB session id and file number based on read access to logs or DB files. The adversary would also need to predict the salt in order to influence the checksum result toward collision with another file's checksum. This change is just internal code to support such a future feature. I think this should be a passive feature, not option-controlled, because you probably won't think about needing it until you discover you do need it, and it should be low cost, in space (16 bytes per SST file) and CPU. Pull Request resolved: https://github.com/facebook/rocksdb/pull/11331 Test Plan: Unit tests added to verify at least pseudorandom behavior. (Actually caught a bug in first draft!) The new "stress" style tests run in ~3ms each on my system. Reviewed By: ajkr Differential Revision: D46129415 Pulled By: pdillinger fbshipit-source-id: 7972dc74487e062b29b1fd9c227425e922c98796oxigraph-main
parent
2926e0718c
commit
98c6d7fd80
Loading…
Reference in new issue