In dm-verity, there is a root hash that is used to verify a data storage device. It is created when you run veritysetup. But in addition to the root hash, a salt is also given. Why?


A salt is combined with the hash when creating the digest which is stored on the device. Hashes will be the same (for given content), so the salt is a way to make the digest different.

When dm-verity runs, it compares against lists of hashes, so you need the salt to match the hashes against the digests which were stored.

Further reading:

| improve this answer | |
  • First off, the digest stored on which device? Second, why do they need the resulting hashes to be different? – Melab Feb 20 '16 at 4:28
  • As I read the description, there is a digest stored on the disk or the EPROM (whatever the boot storage mechanism happens to be). The digest is formed by the salt combined with a hash. To verify the digest, dm-verity wants the salt so that it can use the hashes which you provide, to match the stored digest. – Thomas Dickey Feb 20 '16 at 20:26
  • But why is a salt used at all? – Melab Mar 3 '16 at 4:06

If there was no salt, any block of data would always result in the same block hash. This means that if a hash collision can be found that for that block, it could be used. The likelihood is low given that the block size is fixed, but for a long lived partition updated with differential updates, a single block could be untouched for years. The salt makes it easy to not worry about that by enabling all the block hashes to change on every update by changing the salt on each update.

As the hash tree generated for use by dm-verity is not trusted and generated on device, all that the device needs to generate it is the salt and the data. Then the final root node should match the supplied root hash.

(Fwiw, the original version of dm-verity lacked support for salt.)

| improve this answer | |
  • If a collision can be found, then adding a salt will not make it more secure. – Melab Jan 22 '17 at 22:33
  • @Melab, it certainly does contain the breach, though, if such collisions are expensive. If it takes, say, 6 months of rented botnet time to come up with a single collision, then having that collision be only good against one release is a very different cost/benefit ratio than if it's good for all releases within a large span (or even reusable into future releases so long as they contain any identical blocks). – Charles Duffy Mar 9 '18 at 18:08
  • @Melab, ...it also prevents a single collision from being reusable across multiple targets, even if they share bootloader code or other common content. We live in the real world -- how expensive it is to exploit a breach, both monetarily and in terms of compute time, matters. – Charles Duffy Mar 9 '18 at 18:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.