Re:Motorola Signature 27 with GrapheneOS support
by yaro330 on Thursday November 05, 2026 @05:55PM
(#50385715)
> GrapheneOS provides users with the ability to set a duress PIN/Password that will irreversibly wipe the device (along with any installed eSIMs) once entered anywhere where the device credentials are requested (on the lockscreen, along with any such prompt in the OS).
From your feature overview. Wiping the device means zeroing everything where userdata may exist, not wiping the keystore. I'm sure wiping the keys is technically okay but how many more inconsistencies like that do you have?
Re:Motorola Signature 27 with GrapheneOS support
by grapheneos on Thursday November 05, 2026 @06:22PM
(#50385989)
That's not an inconsistency but rather the only way to reliably wipe user data. It would be completely broken to attempt wiping data by zeroing the userdata partition. That wouldn't get rid of all the data from the SSD even with secure erase commands for overwriting it.
A modern SSD has both static and dynamic wear leveling. An SSD redirects writes to the free blocks with the least wear and also moves around used blocks to free up the least heavily written parts of the storage. An SSD with a proper whole drive secure erase implements it by securely wiping keys.
Re:Motorola Signature 27 with GrapheneOS support
by yaro330 on Thursday November 05, 2026 @06:25PM
(#50386030)
I understand all of this. But wiping means what it does, and "removing the keys of an encrypted partition" is not the same. Please be more forthcoming in the documentation.
Sure Daniel
Re:Motorola Signature 27 with GrapheneOS support
by winterguy on Thursday November 05, 2026 @07:04PM
(#50386374)
This is just pedantic and dishonest. 'Wiping data' as a concept very much so includes cryptographically scrambling it and losing the key.
Disk encryption headers, hardware keystore keys and secure element data are each securely erased. Each of those mechanisms prevents deriving the key encryption keys which prevents ever recovering the data. Secure element data isn't stored on the SSD and prevents recovering data via an earlier image of the SSD. We implemented doing all 3 of those before reboot to recovery for device admin wipe and we used the same code for duress PIN/password wipe. We filed an Android security bug for device admin wipe and convinced them to add the hardware keystore wipe before reboot to recovery, but we still add the other 2 forms of wiping there ourselves.
Your claim is a completely baseless fabrication and a very poor excuse to start engaging in the usual inaccurate personal attacks towards our founder.