On Tue, May 05, 2020 at 04:31:10PM -0700, Eric Biggers wrote: > On Wed, May 06, 2020 at 12:46:11AM +0200, David Sterba wrote: > > On Tue, May 05, 2020 at 03:31:20PM -0700, Eric Biggers wrote: > Example: you add support for keyed hash algorithm X, and it later turns out that > X is totally broken (or was never meant to be a cryptographic hash in the first > place, but was mistakenly allowed for authentication). You deprecate it and > tell people not to use it. But it doesn't matter because you screwed up the > design and the attacker can still choose algorithm X anyway. > > This is a basic cryptographic principle, I'm surprised this isn't obvious. I want to avoid confusion raising from too much assuming and obvious calling, from the filesystem side and from the crypto side. I can say that it's clear that the existing data structures provide enough guarantees for authentication, and that it's obvious. But I don't do that and maybe it looks dumb and uninformed but I don't care as long as the end result is ack from a crypto-knowleagable people that it all plays well together and there are no further doubts. Back to the example. The problem with deprecation hasn't been brought up so far but I probably lack imagination _how_ can an attacker choose the algorithm in the context of the filesystem. That this is easy in scenarios with some kind of handshake is obvious, eg. the SSL/TLS downgrade attacks. But I see a big difference in the persistence nature of network connections and filesystems/storage, so the number of opportunities to force bad algorithm is quite different. Mkfs time for sure, and at mount it's in the example I provided in my previous email. If some algorithm is found to be broken and unsuitable for authentication it will be a big thing. Users will be sure told to stop using it but the existing deployments can't be saved. The support from mkfs can be removed, kernel will warn or refuse to mount the filesystems, etc. but what else can be done from the design point of view?
