As unMessage is based on the Double Ratchet Algorithm, we should try
to take advantage of its properties to make unMessage as ephemeral as
possible. So far, these are the ideas we had:
Include ephemeral info in the authentication (#84)
Include ephemeral info in the IV hash (#85)
Due to our dependency in Double Ratchet, maybe we should go full
dependent and create a parallel state for unMessage which is updated
based on Double Ratchet's, but with keys that we use for our own
features. We can use the Nr and Np numbers to check if we should
keep the keys before ratcheting and delete until skipped messages are
received (and expire if the messages are not received after a while).
Finally, whenever we think of new features, keep in mind we should try
to make it as ephemeral as possible.
As unMessage is based on the Double Ratchet Algorithm, we should try to take advantage of its properties to make unMessage as ephemeral as possible. So far, these are the ideas we had:
Include ephemeral info in the authentication (#84)
Include ephemeral info in the IV hash (#85)
Due to our dependency in Double Ratchet, maybe we should go full dependent and create a parallel state for unMessage which is updated based on Double Ratchet's, but with keys that we use for our own features. We can use the
NrandNpnumbers to check if we should keep the keys before ratcheting and delete until skipped messages are received (and expire if the messages are not received after a while).Finally, whenever we think of new features, keep in mind we should try to make it as ephemeral as possible.