On 19/04/2015 01:22, Trevor Perrin wrote:
So here's another approach, which I'll explain by analogy to the Tahoe distributed filesystem [1]: In Tahoe clients can exchange "read capabilities" or "read-caps" which grant access to a file stored elsewhere. 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.
How does this differ from caching per-message PFS keys on the receiving device, and sharing them with the new device when migrating?
This is the current plan for Matrix, albeit allowing conversations to configure coarser PFS granularity if desired (effectively a shared key for certain sets of messages, grouped by time-range or message-type etc). This gives the option of reducing the number of keys that need to be stored on multiple devices in order to decrypt server-side message history - at the (optional) expense of pure PFS, of course.
Apologies if I'm missing the subtlety here :) M -- Matthew Hodgson matrix.org _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
