3 ms·

I don't understand how wear leveling makes deniability impossible. You just have to overwrite sectors in the false partition at the same rate as ones in the tru

I don't understand how wear leveling makes deniability impossible. You just have to overwrite sectors in the false partition at the same rate as ones in the true partition. Since both the true and false partitions are encrypted, their contents are mathematically indistinguishable from randomness when viewed without the decryption key. I also wish that GrapheneOS link didn't say a duress PIN forces the attacker to think twice about entering a PIN, knowing it could wipe the device. It doesn't do that for anyone aware of its existence, since of course the attacker can prevent the secure element from sending a delete command to the flash chip. Obviously if you know the device could attempt to delete itself you would break that feature before sending the code to the secure element...

Cider9986 1mo ago
> I don't understand how wear leveling makes deniability impossible. You just have to overwrite sectors in the false partition at the same rate as ones in the true partition. Since both the true and false partitions are encrypted, their contents are mathematically indistinguishable from randomness when viewed without the decryption key. With deniability, isn't the idea that you would have unlocked the false partition to show that you have nothing on your phone, therefore it's not encrypted?
- Borealid 1mo ago
  There's no way to prove the second partition is real encrypted data instead of random garbage. It gets wear-leveled but that would also be the case if the true partition had been resized before. It doesn't matter if the false partition is unlocked or not - you can plausibly deny there's anything on the phone at all.
grapheneos 29d ago
Deniable encryption mixes more poorly with SSD wear leveling than you believe it does. The secure element has built-in storage protected against tampering. It doesn't rely on external storage. Having support for the duress PIN/password built into the secure element rate limiting would force an attacker to risk wiping it unless they have a secure element exploit. If they have a secure element exploit then they don't need any attempts for a typical PIN since they could quickly brute force it. That's the planned design of the feature once we have the ability to extend the secure element functionality. If they can exploit a secure element then only a decent passphrase is secure. GrapheneOS does make using a decent to strong passphrase much more convenient and memorable but it isn't what most people use in practice.

Cider9986 1mo ago

> I don't understand how wear leveling makes deniability impossible. You just have to overwrite sectors in the false partition at the same rate as ones in the true partition. Since both the true and false partitions are encrypted, their contents are mathematically indistinguishable from randomness when viewed without the decryption key. With deniability, isn't the idea that you would have unlocked the false partition to show that you have nothing on your phone, therefore it's not encrypted?

Borealid 1mo ago
There's no way to prove the second partition is real encrypted data instead of random garbage. It gets wear-leveled but that would also be the case if the true partition had been resized before. It doesn't matter if the false partition is unlocked or not - you can plausibly deny there's anything on the phone at all.

grapheneos 29d ago

Deniable encryption mixes more poorly with SSD wear leveling than you believe it does. The secure element has built-in storage protected against tampering. It doesn't rely on external storage. Having support for the duress PIN/password built into the secure element rate limiting would force an attacker to risk wiping it unless they have a secure element exploit. If they have a secure element exploit then they don't need any attempts for a typical PIN since they could quickly brute force it. That's the planned design of the feature once we have the ability to extend the secure element functionality. If they can exploit a secure element then only a decent passphrase is secure. GrapheneOS does make using a decent to strong passphrase much more convenient and memorable but it isn't what most people use in practice.