Correct.

The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend?

edit: I see now that the prompt was being given and the keys still resided in memory.

Because debian users with luks-suspend have to re-enter their boot password after sleep.

The reason this bug is unexpected is that the user is expecting to have to enter their password (because they expect the key to be wiped on suspend), and then _they are_ asked for their password. But there was a copy of the key elsewhere in kernel memory that was never cleared.

Ah, my bad. Yes, if the user was being presented with the prompt on wake, I see the problem.

I have never had that setup so I was confused.

> The point being made is: If one isn't re-entering their passphrase after suspend, how are they surprised that the encryption keys are somewhere in memory during suspend?

If that was the case for the people using the debian extra secure extension that should have wiped the memory clean then someone would have found this bug much earlier than two years. Their password was required to be re-entered even though the key was still in memory somewhere.

Well, potentially a key might be stored in TPM. But I don't think that's better

I would hope that it is harder to get into the TPM than into the RAM.