zlacker

Okay, but the danger of vendor lockout is very great because gOS only supports one brand of phone. The justification for limiting support to pixels is that it has trusted computing features, but these are made unnecessary by having a long password.

You could just have some disclaimer on the grapheneOS site that says something like "Works best with pixel phones" or have some long password requirement on non-pixel phones

>>beefle+(OP)
> but these are made unnecessary by having a long password.

Yeah, that's completely how security works...

>>gf000+Cq
It is. The idea behind using a embedded trusted computing device in this fashion is that you can store a AFU encryption/decryption keys in the trusted computing device and lower-entropy password like a 4-digit pin or biometrics, with the trusted computing device preventing a brute force attack.

But this is unnecessary if your encryption password has enough entropy in the first place, because it cannot be brute forced. This is the security model of most linux distros that use full disk encryption with LUKS. And android already lets you do this, it is just less convenient.

I use grapheneOS with a high entropy BFU password and a low entropy biometric AFU fingerprint. My linux setup works in the same way. The BFU password is the only "real" password that secures you and encrypts your data. The AFU password is a just temporary screen lock that is vulnerable to side channel attacks because the decryption keys are still in memory.

>>beefle+tr2
This is one particular aspect of security.

If the hardware is not done properly, then the whole thing is broken. E.g. you are useless with your encryption keys if your modem sucks and leaks data, or if the CPU can trivially be made to run custom code (and you just entered your encryption key into a software that just looks like the prompt you were looking for)