Security from bruteforce

Hathaway_Noa The encro and sky hacks had nothing to do with bruteforcing the devices of the 'criminals', the most likely scenario is that the cops have social engineered the people responsible of the Sky and Encro servers, they managed to get into those servers and managed to get their hands on the signing keys of the encro and sky chats, after that they most likely prompted a push auto-update with malicious code (malware) which managed to compromise all the phones connect to

It's already known how they did it. And no it wasn't any social engineering. Encro was outdated af and vulnerable to hundreds of public known exploits. And sky they compromised the signing keys.

Hathaway_Noa

Hathaway_Noa

@strcat pls explain to him that code injection can't do what they claim

This thread unfortunately contains a lot of misinformation and bad advice. We recommend not following any of the previous advice given in this thread and there are numerous inaccurate claims made here. This thread is not a good source of information about this topic.

Please read https://grapheneos.org/faq#encryption for a high level explanation of how disk encryption is implemented. Our recommendation is to choose whether or not you want to rely on the secure element throttling (Weaver) and then proceed based on your decision. Since each user profile has separate encryption keys based on their lock method, you can make different choices for different user profiles. Random 6 digit PIN is a baseline where you depend entirely on Weaver for security. Random passphrase can have enough entropy to be secure even without the hardware features. It should have at least around 90 bit entropy to be secure against any attacker. 128 bits is the standard extreme overkill value and is the upper bound on what's reasonable to use.

Please bear in mind that the passphrase is turned into a key via scrypt key derivation and then further key derivation is done with other inputs including the random Weaver token. The final phase is hardware-bound key derivation. If an attacker can exploit the secure element (exploiting the bootloader does not help), they can bypass the Weaver throttling. If an attacker can extract the key from the SoC, they can perform the final key derivation on a server farm instead of only on the device. They still need to run the key derivation algorithms. Your passphrase is not used as a key but rather is the most important input for deriving the key encryption key used to encrypt a random disk encryption key.

7 random diceware words or 18 random lowercase letters / numbers are both slightly above 90 bit entropy. If you want to completely avoid depending on hardware, that's the baseline for what you should use. You don't need 128 bits of entropy for a random passphrase to be secure against any attacker, but you may want more than 90 bits. 128 bits is an extreme overkill value used to design encryption algorithms. Part of the reason for using an extreme overkill value is in case there are partial breaks of the algorithms reducing their security, which is not relevant to a random passphrase used as input for key derivation.

Our official advice will be added to the website and in the future people should link to that.

L8437

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

https://diceware.rempe.us/#eff

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).

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.

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.