I’m not sure I understand. Are you saying that disk encryption cannot be turned off? While Android provides no clear way to turn off disk encryption, I can assure you it can be done.
If you mean something else, please explain.
I’m saying that once it’s enabled you can’t disable it.
Full disk encryption can be removed. You do have to reformat the disk though so all files must be backed up somewhere else. It isn’t easy but it can be done.
Sorry I thought I saw you say that you enabled and then disabled full disk sorry
I guess I made it sound easy. On Android it used to simply require a factory reset. Now it requires deleting the LUKS header on the filesystem by reformatting from the recovery.
Hi all,
Sorry to revive this old conversation, there was no official statement on fde yet.
As we know from
there will be no TPM in the librem 5.
Have you (puri.sm) or someone with a dev kit already tested a fde and the resulting performance (if it’s already testable)? Will a full disk encryption be some kind of standard on the phone? Even without a TPM it would be possible for me to enter the very long decryption password on boot up - assuming that with the battery time and loading the battery before 0 % I won’t have to boot up many times.
In case there is no fde planned, having everything e2e encrypted but all your “junk” or even log in data with the decryption keys lie unencrypted on your phones unencrypted disk? :-/ I am feeling a bit odd that a robber could see photos (my junk ;-)) made on a librem 5 if they were not encrypted.
Maybe @dcz or @nicole.faerber could give some insight if fde as standard is planned 
Thank you
Interested as well, FDE is crucial. (or something similar of course)
Hm the fde ticket was deleted and when searching for encryption only the doku ticket is found on which is no action.
I guess that now they have more important tasks to resolve like the overheating and I hope full disk encryption can be set up by us later on with the openpgp card.
I hope this gets sorted out soon, I’m very interested in the FDE capabilities. I’ve required FDE on all my mobile devices since for about 15 years and I’m not going to make an exception, though I can tolerate a performance penalty of about 10-15%, which is what I saw on before the CPU extensions were introduced. If data on the device can’t be protected from loss or theft, I can’t take it very far from my desk.
We should be able to manually shrink the main partition and create our own encrypted partition for user data (/home) regardless of what Purism ships. That would protect from loss and theft. The reason why we want full disk encryption is to protect against an evil maid attack. Someone inserting code into the operating system while we are not looking, and letting that code copy our data after we unlock the encryption.
In another topic, I argued for partial disk encryption so that other people can make emergency calls on our phone without requiring us to unlock it. To make this happen, part of the operating system and network configuration has to be not encrypted. To protect against an evil maid attack, the not encrypted data has to be signed and that signature validated before being used. That way, no unauthorized code can spy on the encrypted data. Since everything is still protected by cryptography through either encryption or signatures, it could be called full disk cryptography.
4 Likes
I’d rather have a fully encrypted home phoning NSA phone, than any unencrypted security nightmare.
The amount of data on such a phone nowadays is humongous and a real treasure chest for identity thieves.
Access to mails/sms with password reset capabilities.
Saved passwords from browsers.
Valid login sessions of the browser.
Images showing all kind of information.
Work documents sent to you.
Phone book for social hacking.
Calendar for planing the next heist on your vacation.
I don’t understand why anyone thinks it is a good idea to not encrypt their phone…
PS: we live in an age where it is now officially safer to stick your password on a piece of paper to your monitor than have an unencrypted phone.
2 Likes
That, sir, is hard to argue with.
Because typing in a password on boot, or worse, unlocking, is inconvenient. Also, you are being a bit generous in assuming what people are aware of. If they were, fewer people would be on social media, getting their dopamine levels / emotions exploited so that they stay around to look at advertisements and give up their intimate personal data to them. I protect my phone with encryption and a password, but I expect most people would not. A remote wipe feature fixes some of this, but I would hate to use that if it turned out that the phone got lost in the couch cushion instead of left at the restaurant. Also, remote wipe requires action, whereas encryption does not.
As PureOS is just a Linux distribution, I have no doubt that the stock encryption tools will work. But I would understand if there is some difficultly in getting it to work in a user friendly way, given that the OS is likely going to come preinstalled. If we installed PureOS ourselves, setting up full disk encryption might be easy. Installing from scratch from a known good source is not a bad security practice anyway. Purism has experience with preinstalled OSs and encryption on their laptops, but they might not have time to implement it before shipping. I expect that the phone’s initial setup might be a little different than the laptops.
1 Like
How often do you boot? My android asks a full fledged password on boot. And only pin on unlock.
Where do I assume anything like that?
I think Apple and Android have both fully encrypted phones by default. Weak encryption (only pin protected or worse with fingerprints that are all over the device) but it holds of a lot of thieves already I believe.
For a remote wipe to work the phone still has to have service. An attacker can easily prevent this in a multitude of ways.
I have a lot of doubts. My main doubt is the missing keyboard during boot. From my previous chats on riot I got the feeling there will be none. So I do not see default full disk encryption working on this device for some time. 
1 Like
I boot about once every 2 weeks on average. Mostly due to battery issues. I use a password to unlock. Annoying, but secure. It would probably be better to decrypt with one password and unlock with another due to surveillance concerns. I started doing this before Andriod had default encryption and using it was a pain. For example, you had to enter the password twice on boot.
You said “I don’t understand why anyone thinks it is a good idea to not encrypt their phone” and gave a list of reasons that, while some would guess a few, many would not be able to list all. People do not encrypt their phone because they do not think of those things, so if you do not understand why they do not encrypt, then I would guess that you are assuming that they are aware somehow.
Ah, a missing on screen keyboard during boot. That would do it. A physical one would still unlock full disk encryption. Obviously, not practical if reboots are not limited to being near one. But you could use a Mooltipass, which would be ultra secure. Probably not something you would want to add to your pocket, unless you use it with other things (which I recommend). Keeping your credentials away from your main CPU and RAM is important if you have no tolerance for being hacked. They have a Bluetooth version in the works. If this were an issue at shipping, I would buy the smallest Arduino compatible board that I can find with USB host functionality, and emulate a keyboard to send the unlock keystrokes. Obviously, not practical for most people, but I would be willing to share code.
The missing keyboard during boot thing would not be an issue if they implemented my emergency dialing suggestion. Enough of the operating system would be unencrypted to dial emergency services, which includes displaying a keyboard. Signatures for each unencrypted file accessed would still need to be checked to protect against unauthorized file modifications.
1 Like
Ah, that was just a rhetorical device to highlight it’s importance it has IMHO.
Ofc I’m aware of the unawareness 
On the Mooltipass. I loose stuff. easily and quickly. But I never forget passwords that I use regularly. Also 4 digit password? Is this even considered save? Does it have bruteforce protection?
Emergency dialing is an interesting point as I believe at least in Germany there are regulations for that, that a phone has to follow.
1 Like
I missed the rhetorical device. Sorry about that. Being aware of other people’s unawareness can be important.
Yes, it has secure brute force protection. The smart card contains a failed attempt counter. If it exceeds 3, it bricks. That is why you want to clone your card and put the clone in a secure place. If someone bricks your card, you want another one to fall back to. One design consideration is that if the smart card returns “failed”, it should not be possible to prevent the failed attempt from being recorded by quickly cutting the power. So the failed attempt should always be recorded to non-volatile memory before returning the fail/pass status.
So technically, we cannot have “full” disk encryption (unless the unencrypted part is on a separate disk, but disk or partition should not matter). But protecting everything with cryptography in one way or another (signatures or encryption) should offer the same protection. When you enable disk encryption on Linux, it excludes /boot from the encryption. What I am suggesting is to expand that to include everything needed for emergency dialing.
How hard can it really be to implement a minimal on-screen keyboard at an early stage of boot?
For a start you have to contend with people whose passphrase includes non-ASCII characters or indeed who don’t use ASCII at all. In other words, a minimal keyboard may lock you out of the device.
Maybe a minimal keyboard is OK in the Anglosphere but even then some Anglophones might like to be tricky.
1 Like