search

omemo / gajim-omemo

Gajim plugin for OMEMO Multi-End Message and Object Encryption
87 stars 7 forks source link

opportunistic encryption (OMEMO with untrusted keys) #131

Closed azrdev closed 7 years ago

azrdev commented 8 years ago

General information

lovetox commented 8 years ago

thats trusting on first contact.

how would you think the behaviour should be if you have already trusted the one device of your contact, but he publishes a second one, should we also send messages to this new device without trusting, or not?

some people will find that this is less secure and defeats the purpose of trusting fingerprints

klemens commented 8 years ago

I don't think we should trust on first contact, as this allows the server (or an attacker on the local net, etc.) to read of fake your messages. The OMEMO-XEP even explicitly says in section 7: "Clients MUST NOT use a newly built session to transmit data without user intervention. [...] A client MAY use such "not (yet) trusted" sessions for decryption of received messages [...]".

The same reasoning applies to newly added devices, however I could imagine a way in the future, where a trusted device signs a newly added device, which could then be automatically trusted. However I have not seen any discussion about this yet.

YoukaiCat commented 8 years ago

OTR for example separate encryption and authentication.

There may be situations in which you explicitly do not trust the contact, but want to achieve privacy.

Otherwise there is a risk to "trust" an untrusted contact for just to talk to him without make a real authentication through an outside channel. This will lead to that the contact will be marked as "trusted", and you forget that there had been no real authentication.

I think "encrypted but not authenticated" mode will be usefull.

lovetox commented 8 years ago

yeah though OTR doesnt allow for multiple devices.

the problem doesnt exist if only one device is there anyway, the problem is that the server or someone bad can always introduce an additional device to you.

this should be taken seriously from the start, it could indicate that the account of your chat partner was overtaken for example.

azrdev commented 8 years ago

separate encryption and authentication

I think that's the way we should go to allow for opportunistic encryption. If we already have trusted keys, we should not encrypt for the untrusted, though. I admit this is a pitfall for bad UX.

A "this user is not authenticated" warning counts to me as the "user intervention" demanded by the XEP.

side note:

yeah though OTR doesnt allow for multiple devices.

this is not true, you can have different keys on different devices, and your chat partner can have OTR sessions with each of them. Since protocol version 3, so-called instance tags even allow to distinguish these sessions. (still OMEMO is probably a better solution for the problem, but with OTR it's possible, too)

kaindl commented 8 years ago

@YoukaiCat

There may be situations in which you explicitly do not trust the contact, but want to achieve privacy.

How could you achieve privacy without verifying the key? That is the most common misunderstanding with encrypted messaging.. As long, as you don't verify the key, you could as well communicate unencrypted.. In my eyes thats one of the real good design principles in OMEMO over OTR.. Most of my contacts used OTR without proper verification and thought, their communication was secured...

kaiyou commented 7 years ago

Allowing encryption without authentication not only partially (even completely according to some) defeats the purpose of encryption, it is also counterproductive by providing a false sense of security.

Also, two bad behaviours are competing here: users who think they need privacy quickly and do not go through the process of carefully verifying the fingerprint (in the case authentication is mandatory) or users who will forget about authentication all the same and never bother about warnings (in the case authentication is optional).

lovetox commented 7 years ago

we will probably implement Conversations new concept see https://github.com/omemo/gajim-omemo/issues/147 please add your thoughts to the new ticket