>> > On 19/04/2015 01:22, Trevor Perrin wrote: >> [...] >> >> A read-cap contains a symmetric encryption key for an >> >> encrypted file and a secure hash of its ciphertext, so it has all the >> >> data needed to retrieve and decrypt an authentic copy of the file.
The idea of storing a key of trees is not particularly novel. A somewhat better way of doing it is to store a tree with a branching factor of (storage_page_size / (key_size + sizeof(uintptr_t))). Does anyone have a decent citation? (RR, perhaps?) On Mon, Apr 20, 2015 at 6:07 PM, Gary Belvin <[email protected]> wrote: > It seems to me that the challenge with this approach is authenticating the > requests before releasing a set of symmetric keys to your data. I very much agree. In particular, I think that passphrase-based-authentication is a dreadful idea for this. (So: Use a decent multi-device model instead.) And, to reiterate a point which I have made previously: It is extremely important to ensure that stored messages cannot be correlated with the messages sent on the wire between sender and recipient. This requires that messages be re-encrypted for storage. > It's another attack surface. It also change the semantics of "only the person > with the private key can read the message". Thoughts? "Only the person with the private key can read the message" implies transferring (relatively) long-term private encryption keys between devices. This is far, far worse than transferring even PFS ephemeral keys. > On Sun, Apr 19, 2015 at 10:37 AM, Trevor Perrin <[email protected]> wrote: >> Example: Alice sends you a message, you later share the >> message-decryption key to a new device. But spyware on Alice's >> machine was stealing her keys! Your service provider could use the >> stolen message key to rewrite Alice's message. This is prevented if >> you give the new device a secure hash of the message alongside the >> key. This threat model would make sense if a provider (1) allowed users to rewrite stored messages at arbitrary times, (2) but did not allow them to rewrite the hashes. Is there some reason that this would be a useful service to provide? The only particularly good reason to rewrite stored messages is to re-encrypt them under a new key. But if you can't change the "secure hash", you still need the old "secure hash" key. -- (Or, you could just do an (N?)IZKP that the message is a re-encryption of the same plaintext under a different encryption key, and that the "secure hash" is a MAC of the same plaintext under a different MAC key...) _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
