It will be deleted. This is an important topic. Need to get this right
Security from bruteforce
It's definitely not possible what the authorities claimed
- Edited
Daniel recommends 90 bit = slinging massive kiwi penholder closable wolverine roundish
I recommended 128 bit = managing stoppable covenant silenced small harness recolor curvature friend veto
96 bit should be enough
GrapheneOS 7 random diceware words
I can't imagine typing that multiple times per day
f13a-6c3a So then use a random 6 digit PIN and depend on the secure element throttling. If you want to have data not depending on the secure element for secure encryption, make a secondary user with a diceware passphrase.
- Edited
GrapheneOS What about the other way around? A 7 word diceware password for the Owner user profile, and a PIN for secondary user profiles where the apps and data live? This way you have a strong password protecting the boot, but only need to enter it upon boot (assuming that an adversary only gets physical access to the phone when it is turned off).
circlingdante Seems like a good idea. I wonder it it would work well? Curious to see a response to your question.
- Edited
GrapheneOS So then use a random 6 digit PIN and depend on the secure element throttling.
Or use the 7 diceware and enable fingerprint unlock. Put an app like private lock on it that allows you to disable fingerprint but just acceleration. This seems more preferable.
circlingdante strong password protecting the boot, but only need to enter it upon boot
What happens after 3 days when fingerprint is auto disabled?
- Edited
contour0806 I've been doing this for a while and it works well. I just wanted to see if the approach is actually valid.
My thinking: If the assumption that an adversary gets physical access when the device is powered off is not valid, the "auto reboot" setting being enabled can help to mitigate this, by giving a limited amount of time to brute force the weaker secondary user profile. Am I correct in assuming that once a secondary user profile session is started, if the adversary got physical access while the device was on a lock screen they would still come up against the weaver token rate-limiting for accessing that secondary user profile?
A bit off topic, but putting all user data in secondary user profiles also seems to make sense in that, as far as I understand, the Owner profile stores sensitive OS information that secondary user profiles do not.
The assumption the whole thing is making is that the adversary needs to have access to the Owner profile before they can attempt to brute force secondary profiles. I make this assumption because that's where I understand the secondary profile information to be stored, but it could be wrong.
https://grapheneos.org/faq#encryption
Sensitive data is stored in user profiles. User profiles each have their own unique, randomly generated disk encryption key and their own unique key encryption key is used to encrypt it. The owner profile is special and is used to store sensitive system-wide operating system data. This is why the owner profile needs to be logged in after a reboot before other user profiles can be used. The owner profile does not have access to the data in other profiles. Filesystem-based encryption is designed so that files can be deleted without having the keys for their data and file names, which enables the owner profile to delete other profiles without them being active.
circlingdante I don't want to spread misinformation, but the last post quoting the GOS page may mean that your approach works as intended since the Owner profile is privileged as in, all other profiles depend upon the Owner being unlocked?
I think the question comes down to (which still isn't clear to me): would a brute-forcing adversary need to FIRST have cracked the Owner user profile in order to brute force attack the secondary user profiles, if the device was obtained when turned off? It seems like the answer is yes based on the documentation.
[deleted]
I would say, you are welcome to try it to see if it fits your needs. But it hasn't received any updates in a while, so I am afraid what you see is what you get and that is it.
To brute force a secondary profile, you don't need access to the first profile.
treequell Are you sure about that?
If the entire data of the device is extracted into external storage, then naturally the data belonging to each profile is gonna be encrypted with its own key. To then decrypt the data of one profile you'd theoretically not need the key for the other profiles. Why is this not the case?