Re: propagating vmgenid outward and upward

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Michael,

On Wed, Mar 2, 2022 at 3:46 PM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
> I just don't see how "value changed while it was read" is so different
> from "value changed one clock after it was read".  Since we don't detect
> the latter I don't see why we should worry about the former.

The "barrier" is at the point where the plaintext has been chosen AND
the nonce for a given keypair has been selected. So, if you have
plaintext in a buffer, and a key in a buffer, and the nonce for that
encryption in a buffer, and then after those are all selected, you
check to see if the vmgenid has changed since the birth of that key,
then you're all set. If it changes _after_ that point of check (your
"one clock after"), it doesn't matter: you'll just be
double-transmitting the same ciphertext, which is something that flaky
wifi sometimes does _anyway_ (and attackers can do intentionally), so
network protocols already are resilient to replay. This is the same
case you asked about earlier, and then answered yourself, when you
were wondering about reaching down into qdiscs.

Jason



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux