No; the encryption is still for real, even if the key is weak. The disk contents will be unreadable until mounted with correct crypto options and key.
1 Like
@attah I believe the “minor inconvenience” does not refer to the encryption but to the locking code as protection of the Recovery mode. The attack needs recovery mode (to exfiltrate a copy of the first megabytes of /home), which asks for the locking code; but the locking code can be bypassed by booting another image.
That would make sense. Reply-to here is apparently hard to get right (i often get it wrong too, since for whatever reason you can’t see your on reply-to after you post).
Regarding the possibility to have separate encryption and lock code as proposed by @rinigus and @fingus , I did not find the instructions (on git) to be easy to follow by simple users like me. Since the code and merge request are 2 years old, it would be great if someone could check that it still works for a fresh install with current SFOS, and ideally capture the command session. (I know I have no right to ask anything from anyone.)
In general, if you mean community encryption solution, it was developed for ported devices. During those two years, nobody has ported it to the official device. I would consider that to be something which should be done by the users of the official device if they are interested. I don’t have any official device myself and don’t plan to start such port.