Hacker News Reader

Comment by derefr | Hacker News Reader

I think the point of this technique is to be able to leave the machine locked on cold boot, but to be able to e.g. unlock it, put it to sleep, and go on vacation; and then, if you need to remotely reboot it, you can reboot it in such a way that it stays unlocked on next boot, rather than reverting to locked.

View on HN

Generally I have used fdesetup to do remote OS upgrades: do this just before an OS upgrade so that on reboot I can still log in.

It's still a little bit like putting your jewelry in a safe, and leaving the key on top of the safe.

I mean, I assume you'd set the unlock-on-reboot flag, and then immediately reboot — at which point the unlock-on-reboot flag gets automatically unset.

So, sure, it's a bit like leaving the key on top of the safe... while you have the safe open. Which isn't all that odd.

No, the scenario was power outage at an unknown time in the future, not immediate reboot.

When it comes to disk encryption, at least in the home, the threat model isn't somebody sitting around in your home finding a way to exfiltrate the currently-unlocked filesystem; It's someone taking the computer or the drive with them and leaving.

In your analogy, the key atop the vault vanishes as soon as the vault is moved from its location (loses power).

If that was the case (maybe it is, I don’t know), then how does the proposed solution help against power outages, which was asked for?

That wasn’t what was asked for. The original reason given was to require a password on cold boot, but not require a password when rebooting e.g. for an OS update

Well, you've asked me to quote in another subthread, I did. Since I don't fully get what you're referring to now, can you please quote?

It makes sense temporarily. You can always move the key to your pocket later if nobody steals it.

Oh yeah, I get it. Just pointing out what this is doing, and why you should probably not always do this, for example.

Reply on news.ycombinator.com