even just accessing the device yourself is slow as you have to wait for the whole system to decrypt and start up.
that’s not true. the system does not decrypt itself in one go. it’ll just wait with part of the bottup process until you unlock your device, and then keeps the encryption keys in memory so that it can encrypt and decrypt anything when needed.
and the purpose of the reboot is just to make sure that both the encryption key, and any data crumbs left in the memory get lost from there
While in this locked down state, nothing can run.
that’s not true either. for instance the system definetly runs with a couple of its components. but apps too can request to be able to work before unlock, like your alarm clock. but of course, apps that store data in the compartment accessible before unlock is not secure, however they can selectively store there only the most essential things needed to work (alarm time database and maybe used ringtones)
lol@discuss.tchncs.de 1 month ago
Darkassassin07@lemmy.ca 1 month ago
It’s exactly what the reboot process is designed to do; return you to that fully encrypted pre-boot state. There would be no purpose to implementing a second method that does the exact same thing.
WhyJiffie@sh.itjust.works 1 month ago
its done that way because at a reboot all memory is lost, and it can’t happen that something slips through because there is a bug or some miscalculation