[Standards] Disappearing timers for OMEMO proposal

Alexander Krotov ilabdsf at gmail.com
Sat May 12 08:14:12 UTC 2018


On Fri, May 11, 2018 at 10:24:35AM +0200, W. Martin Borgert wrote:
> Quoting Alexander Krotov <ilabdsf at gmail.com>:
> > Disappearing messages without end-to-end encryption and forward
> > secrecy are useless at best. They give the user false sense of
> > security. That is why Telegram implements timers for "secret" chats
> > only I believe, as I said in the first message.
> 
> I respectfully disagree.
> 
> Timers (or "ephemeral messages") are not a security feature, but only
> a means of data hygiene.

What I propose is a security feature that complements forward secrecy.
Just like OMEMO clients make sure not to store ephemeral keys,
OMEMO+Timers clients should make sure not to store ephemeral contents.

> Therefore it is orthogonal to any encryption and it does also not
> matter, whether your peer or one of your peers devices or resources
> does implement the feature or not. No need to check. As sender, just
> use the timers and let the problem of deleting messages to the
> recipient.

I want to be able to advertise to my contacts which of my devices
support timers, so devices that don't support them are not able to
decrypt the message. Otherwise I will have to remove messages
manually, and it is not always possible, for example if messages
are stored in the cloud or locally in the SQLite database without
SQLITE_SECURE_DELETE pragma.

Implementing this in a way orthogonal to OMEMO encryption is
impossible, because mechanism I propose must be aware of "devices"
and "keys".

I agree that unencrypted disappearing messages may be useful to
someone, so the <timer> element itself can be specified independently,
but for my proposal it is only a small part of the whole solution.

What you suggest (send disappearing messages to all devices, whether
supporting the feature or not) is called opportunistic security.
It is similar to sending email messages encrypted to those contacts
for which you have their public key and plaintext to those clients
for which you don't. That is how "autocrypt" (https://autocrypt.org/)
works, but it offers lower security guarantees. For example, it
can't help against active attacker, because it is automatically
disabled if unencrypted message is received. Opportunistic security in
email world is a compromise required due to problems with OpenPGP
web-of-trust model proliferation. OMEMO has much smaller problems,
especially since "blind trust before verification" was enabled.

I definitely want a strong non-opportunistic mode, in which it is
guaranteed that messages are only sent to those devices that support
encryption. Adding opportunistic mode may be possible, but I am
afraid it will overcomplicate both the protocol and the UI.

For example, support for timers in clients that don't support encryption
will make it impossible to move <timer> element inside the encrypted
part in the future: it will break timer setting synchronization.


More information about the Standards mailing list