upvote

points

by CodesInChaos3 hours ago |
comments
upvoteby wrs3 hours ago|
[-]
Obviously your distro isn’t using cryptsetup-luksSuspend.
reply
upvoteby unethical_ban2 hours ago|
parent|
[-]
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.

reply
upvoteby ksbd-pls-finish2 hours ago|
parent|
next
[-]
Because debian users with luks-suspend have to re-enter their boot password after sleep.
reply
upvoteby akerl_2 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby unethical_ban1 hours ago|
parent|
[-]
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.

reply
upvoteby weaksauce2 hours ago|
parent|
prev|
next
[-]
> 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.

reply
upvoteby killerstorm2 hours ago|
parent|
prev|
[-]
Well, potentially a key might be stored in TPM. But I don't think that's better
reply
upvoteby joshuaissac1 hours ago|
parent|
[-]
I would hope that it is harder to get into the TPM than into the RAM.
reply