Messages in this thread | | | Date | Wed, 25 Feb 2004 22:36:48 +0100 | From | Christophe Saout <> | Subject | Re: cryptoapi highmem bug |
| |
On Wed, Feb 25, 2004 at 03:46:51PM -0500, Jean-Luc Cooke wrote:
> > > Can we do this? > > > > It's very non-trivial. Think about journalling filesystems, write > > ordering and atomicity. If the system crashes between two write > > operations we must be able to still correctly read the data. And > > write to these "crypto info blocks" should be done in a ways that > > doesn't kill performance. Do you have a proposal? > > I see. From a security point of view, no. OMACs need to be updated after > the data is updated to keep integrity checks passing.
Yes. But if the machine doesn't get to update the OMAC but the data has already been written you must be able to still read the data somehow.
> IVs need to be updated before the data is updated or plaintext is leaked.
Hmm? What could be done: The IV "sequence number" is incremented by one every time a sector gets written. The IV sequence numbers get written to the info block later (after a timeout, memory pressure and we to free some space in the cache or if the sequence has gone too far). When we read and the OMAC doesn't match we can try to increase the IV several times until it matches. Still the problem with the OMAC atomicity...
> (IV + data + OMAC can be written to device at once).
You can't guarantee that anything gets written at once. You can only make sure that something has been written. Or that something gets written before something else (using barriers, but I don't know if that is stable, it has never been used on bio level yet).
> I assume then that IVs and OMACs will not be stored in the same read-chunk as > the data then? Bummer if this is the case.
Well, we can't store it in the same sector because all 512 bytes are already used data.
We could store less than 512 bytes in a sector but that would mean splitting up data on a sub-sector level. That means we have to read some sectors with untouched data (the first and the last), update the data and write several sectors. But then we can't even guarantee that sectors are atomicically written as seen by the filesystem. This is... yuck. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |