Comment by mjevans
1 year ago
Offhand, this sounds like a terribly insecure workflow but...
Client creates a Public Private key pair used for E2EE.
Client uses the 'account password (raw)' as part of the creation of a symmetric encryption key, and uses that to encrypt and store the SECRET key on the service's cloud.
NewClient signs in, downloads the encrypted SECRETKeyBlob and decodes using the reconstructed symmetric key based on the sign in password. Old messages can then be decoded.
-- The part that's insecure. -- If the password ever changes the SAME SECRET then needs to be stored to the cloud again, encrypted by the new key. Some padding with random data might help with this but this still sounds like a huge security loophole.
-- Worse Insecurity -- A customer's device could be shipped a compromised client which uploads the SECRET keys to requesting third parties upon sign-in. Those third parties could be large corporations or governments.
I do not see how anyone expects to use a mobile device for any serious security domain. At best average consumers can have a reasonable hope that it's safe from crooks who care about the average citizen.
> When you regain consciousness you'll be perfectly fine, but won't for the life of you be able to recall your device passwords or keys
You can't use your password as input to the mud puddle test.
How would an end user even know they're running that test for a closed box system? The idea is what's possible in the real world.