On 04/05/2020 22:59, Eric Biggers wrote: [...] > But your proposed design doesn't do this completely, since some times of offline > modifications are still possible. > > So that's why I'm asking *exactly* what security properties it will provide. [...] > Does this mean that a parent node's checksum doesn't cover the checksum of its > child nodes, but rather only their locations? Doesn't that allow subtrees to be > swapped around without being detected? I was about to say "no you can't swap the subtrees as the header also stores the address of the block", but please give me some more time to think about it. I don't want to give a wrong answer. [...] > Actually, nothing in the current design prevents the whole filesystem from being > rolled back to an earlier state. So, an attacker can actually both "change the > structure of the filesystem" and "roll back to an earlier state". Can you give an example how an attacker could do a rollback of the whole filesystem without the key? What am I missing? > It very well might not be practical to provide rollback protection, and this > feature would still be useful without it. But I'm concerned that you're > claiming that this feature provides rollback protection when it doesn't. OK. [...] > The data on disk isn't trusted. Isn't that the whole point? The filesystem > doesn't trust it until it is MAC'ed, and to do that it needs the MAC algorithm. OK, will add this in the next round. Thanks, Johannes
