New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Plugin Request] OMEMO #10

Closed
GreenLunar opened this Issue Feb 12, 2016 · 45 comments

Comments

Projects
None yet
@GreenLunar
Member

GreenLunar commented Feb 12, 2016

A plugin that adds support for OMEMO encryption.

https://conversations.im/omemo/
https://github.com/omemo

@rapgro

This comment has been minimized.

Show comment
Hide comment
@rapgro

rapgro commented Feb 12, 2016

👍

@GreenLunar

This comment has been minimized.

Show comment
Hide comment
@GreenLunar

GreenLunar Feb 12, 2016

Member

I am contemplating about GitHub having a voting system, similarly to GitLab. Thank you, @rapgro, for the the 👍 vote and, in case you didn't know, for getting me into Jabber.

Member

GreenLunar commented Feb 12, 2016

I am contemplating about GitHub having a voting system, similarly to GitLab. Thank you, @rapgro, for the the 👍 vote and, in case you didn't know, for getting me into Jabber.

@raid1

This comment has been minimized.

Show comment
Hide comment
@raid1

raid1 Jul 4, 2016

I'd like to add even multiple 👍 's
psi is really great but it does not play well with "conversations" on android.

raid1 commented Jul 4, 2016

I'd like to add even multiple 👍 's
psi is really great but it does not play well with "conversations" on android.

@Ri0n

This comment has been minimized.

Show comment
Hide comment
@Ri0n

Ri0n Jul 4, 2016

Member

You know encryption is illegal in Russia, so I'm out of business.
Any pull request?

Member

Ri0n commented Jul 4, 2016

You know encryption is illegal in Russia, so I'm out of business.
Any pull request?

@raid1

This comment has been minimized.

Show comment
Hide comment
@raid1

raid1 Jul 5, 2016

Oops, sorry to hear that.

raid1 commented Jul 5, 2016

Oops, sorry to hear that.

@sadr0b0t

This comment has been minimized.

Show comment
Hide comment
@sadr0b0t

sadr0b0t Dec 8, 2016

You know encryption is illegal in Russia

this is not true

sadr0b0t commented Dec 8, 2016

You know encryption is illegal in Russia

this is not true

@Ri0n

This comment has been minimized.

Show comment
Hide comment
@Ri0n

Ri0n Dec 8, 2016

Member

That's true.
Basically two points:

  1. Service provider MUST keep chat logs
  2. The logs MUST be either unencrypted or deciphered by request (read: unencrypted anyway)

This makes OMEMO useless in Russia

Member

Ri0n commented Dec 8, 2016

That's true.
Basically two points:

  1. Service provider MUST keep chat logs
  2. The logs MUST be either unencrypted or deciphered by request (read: unencrypted anyway)

This makes OMEMO useless in Russia

@Ri0n

This comment has been minimized.

Show comment
Hide comment
@Ri0n

Ri0n Dec 8, 2016

Member

We can you TLS encryption with same success here.

Member

Ri0n commented Dec 8, 2016

We can you TLS encryption with same success here.

@OpenA

This comment has been minimized.

Show comment
Hide comment
@OpenA

OpenA Dec 8, 2016

Так-так, что тут у нас?
Лаборатория по производству и одновременно притон по сбыту нелегальных шифровальных средств?

Гражданин, вы задержаны.
Пройдёмте.

OpenA commented Dec 8, 2016

Так-так, что тут у нас?
Лаборатория по производству и одновременно притон по сбыту нелегальных шифровальных средств?

Гражданин, вы задержаны.
Пройдёмте.

@iavael

This comment has been minimized.

Show comment
Hide comment
@iavael

iavael Dec 8, 2016

Service provider MUST keep chat logs

That's problem of service provider

The logs MUST be either unencrypted or deciphered by request (read: unencrypted anyway)

That's not responsibility of user. That's what service provider have to do.

iavael commented Dec 8, 2016

Service provider MUST keep chat logs

That's problem of service provider

The logs MUST be either unencrypted or deciphered by request (read: unencrypted anyway)

That's not responsibility of user. That's what service provider have to do.

@iavael

This comment has been minimized.

Show comment
Hide comment
@iavael

iavael Dec 8, 2016

And that's why omemo IS useful. There's no point in encrypting data, if nobody's gonna intercept it.

iavael commented Dec 8, 2016

And that's why omemo IS useful. There's no point in encrypting data, if nobody's gonna intercept it.

@genofire

This comment has been minimized.

Show comment
Hide comment
@genofire

genofire Dec 23, 2016

Why you support Off-The-Record?
(So i have still to use gajim 😄 )

genofire commented Dec 23, 2016

Why you support Off-The-Record?
(So i have still to use gajim 😄 )

@Ri0n

This comment has been minimized.

Show comment
Hide comment
@Ri0n

Ri0n Dec 23, 2016

Member

OTR was implemented before thie weird laws.
But basically I agree while instant messaging servers/operators do not ban us for encryption we can implement and use omemo.

Member

Ri0n commented Dec 23, 2016

OTR was implemented before thie weird laws.
But basically I agree while instant messaging servers/operators do not ban us for encryption we can implement and use omemo.

@nightvisi0n

This comment has been minimized.

Show comment
Hide comment
@nightvisi0n

nightvisi0n Jan 3, 2017

OMEMO would be really usefull since OTR is close to useless with multi-sessions.

nightvisi0n commented Jan 3, 2017

OMEMO would be really usefull since OTR is close to useless with multi-sessions.

@Neustradamus

This comment has been minimized.

Show comment
Hide comment
@Mic92

This comment has been minimized.

Show comment
Hide comment
@Mic92

Mic92 Mar 9, 2017

@Ri0n would it be legal as a Russian user to choose a provider in a free country like mine and using OMEMO there?

Mic92 commented Mar 9, 2017

@Ri0n would it be legal as a Russian user to choose a provider in a free country like mine and using OMEMO there?

@Ri0n

This comment has been minimized.

Show comment
Hide comment
@Ri0n

Ri0n Mar 9, 2017

Member

Well yes and no. From government point of view if Russians use foreign services then these foreign services should keep their user database on territory of Russian Federation. At least for Russian users.
And then we have all the laws =)

Actually this makes little sense for end user since it's a problem of service provider, not user. So it's fine to implement and use it. And if the government bans such a service provider for such illegal activity like not keeping unencrypted chat history, well that's the destiny =)

Member

Ri0n commented Mar 9, 2017

Well yes and no. From government point of view if Russians use foreign services then these foreign services should keep their user database on territory of Russian Federation. At least for Russian users.
And then we have all the laws =)

Actually this makes little sense for end user since it's a problem of service provider, not user. So it's fine to implement and use it. And if the government bans such a service provider for such illegal activity like not keeping unencrypted chat history, well that's the destiny =)

@iavael

This comment has been minimized.

Show comment
Hide comment
@iavael

iavael Mar 9, 2017

@Ri0n

From government point of view if Russians use foreign services then these foreign services should keep their user database on territory of Russian Federation

That's not really so. Services must keep only users' personal information (real name, address, credit card info, social security number and other info, which identifies user's person) on russian territory.

iavael commented Mar 9, 2017

@Ri0n

From government point of view if Russians use foreign services then these foreign services should keep their user database on territory of Russian Federation

That's not really so. Services must keep only users' personal information (real name, address, credit card info, social security number and other info, which identifies user's person) on russian territory.

@Ri0n

This comment has been minimized.

Show comment
Hide comment
@Ri0n

Ri0n Mar 9, 2017

Member

Ok. it's fine without using VCards :-D

Member

Ri0n commented Mar 9, 2017

Ok. it's fine without using VCards :-D

@tehnick

This comment has been minimized.

Show comment
Hide comment
@tehnick

tehnick Mar 9, 2017

Member

@Ri0n How about deletion of messages unrelated to a topic?

@GreenLunar , @Neustradamus Have you seen any self-contained C or C++ library with OMEMO encryption support? (Like libotr for OTR.)

Member

tehnick commented Mar 9, 2017

@Ri0n How about deletion of messages unrelated to a topic?

@GreenLunar , @Neustradamus Have you seen any self-contained C or C++ library with OMEMO encryption support? (Like libotr for OTR.)

@Moarc

This comment has been minimized.

Show comment
Hide comment
@Moarc

Moarc Mar 9, 2017

Hi,
Sorry for butting in when you explicitly asked GreenLunar and Neustradamus, but the Pidgin plugin (not Lurch) seems to use libsignal-protocol-c.

Moarc commented Mar 9, 2017

Hi,
Sorry for butting in when you explicitly asked GreenLunar and Neustradamus, but the Pidgin plugin (not Lurch) seems to use libsignal-protocol-c.

@YoukaiCat

This comment has been minimized.

Show comment
Hide comment
@YoukaiCat

YoukaiCat Mar 9, 2017

There is also libolm:

An implementation of the Double Ratchet cryptographic ratchet, written in C and C++11 and exposed as a C API.

YoukaiCat commented Mar 9, 2017

There is also libolm:

An implementation of the Double Ratchet cryptographic ratchet, written in C and C++11 and exposed as a C API.

@tehnick

This comment has been minimized.

Show comment
Hide comment
@tehnick

tehnick Mar 9, 2017

Member

I found libomemo. It looks raw, but this is better than nothing.

Member

tehnick commented Mar 9, 2017

I found libomemo. It looks raw, but this is better than nothing.

@msva

This comment has been minimized.

Show comment
Hide comment
@msva

msva Mar 10, 2017

msva commented Mar 10, 2017

@ValdikSS

This comment has been minimized.

Show comment
Hide comment
@ValdikSS

ValdikSS Jan 13, 2018

Contributor

I offer $1000 bounty for OMEMO encryption support in Psi+. This should be implemented either directly in a code or as a plugin, and should be fully compatible with the specification and with existing implementations. It should work with multiple connections on one account (multiple resources).

Contributor

ValdikSS commented Jan 13, 2018

I offer $1000 bounty for OMEMO encryption support in Psi+. This should be implemented either directly in a code or as a plugin, and should be fully compatible with the specification and with existing implementations. It should work with multiple connections on one account (multiple resources).

@stigger

This comment has been minimized.

Show comment
Hide comment
@stigger

stigger Jan 17, 2018

Member

I have a prototype. It's functional, but still far from being done. Hopefully, I'll have something to publish in a few weeks. In the meantime, here is a short teaser.

Member

stigger commented Jan 17, 2018

I have a prototype. It's functional, but still far from being done. Hopefully, I'll have something to publish in a few weeks. In the meantime, here is a short teaser.

@ValdikSS

This comment has been minimized.

Show comment
Hide comment
@ValdikSS

ValdikSS Jan 17, 2018

Contributor

AFAIK Wime (a fork of Psi+) has OMEMO support. It could be ported from there.

Contributor

ValdikSS commented Jan 17, 2018

AFAIK Wime (a fork of Psi+) has OMEMO support. It could be ported from there.

@stigger

This comment has been minimized.

Show comment
Hide comment
@stigger

stigger Jan 17, 2018

Member

Nope, they have only OTR.

Member

stigger commented Jan 17, 2018

Nope, they have only OTR.

@ValdikSS

This comment has been minimized.

Show comment
Hide comment
@ValdikSS

ValdikSS Jan 18, 2018

Contributor

@stigger Wime indeed has OMEMO plugin, but I can't find it's source code. There's libomemoplugin in the binary bundle.

Contributor

ValdikSS commented Jan 18, 2018

@stigger Wime indeed has OMEMO plugin, but I can't find it's source code. There's libomemoplugin in the binary bundle.

@ValdikSS

This comment has been minimized.

Show comment
Hide comment
@ValdikSS

ValdikSS Jan 18, 2018

Contributor

Seems they stopped to update their source code on bitbucket. I'll request a fresh one.
https://bitbucket.org/whoernet/wime/issues/10/repository-is-not-up-to-date

Contributor

ValdikSS commented Jan 18, 2018

Seems they stopped to update their source code on bitbucket. I'll request a fresh one.
https://bitbucket.org/whoernet/wime/issues/10/repository-is-not-up-to-date

@stigger

This comment has been minimized.

Show comment
Hide comment
@stigger

stigger Jan 27, 2018

Member

stigger@7b7ec5d

The protocol itself should be fully supported, but there is no UI implemented and it blindly trusts all devices, so not suitable for sensitive communication yet! But it would be great if while I'm working on that, someone could take a look and report possible issues, e.g. compatibility problems with other clients.

Requires psi-im/psi#341 & psi-im/iris#52.

Member

stigger commented Jan 27, 2018

stigger@7b7ec5d

The protocol itself should be fully supported, but there is no UI implemented and it blindly trusts all devices, so not suitable for sensitive communication yet! But it would be great if while I'm working on that, someone could take a look and report possible issues, e.g. compatibility problems with other clients.

Requires psi-im/psi#341 & psi-im/iris#52.

@ValdikSS

This comment has been minimized.

Show comment
Hide comment
@ValdikSS

ValdikSS Jan 27, 2018

Contributor

Good job!
Is it compatible with current GPLv2 license of Psi? I heard there are license problems with official Signal implementation.
anurodhp/Monal#9 (comment)

Contributor

ValdikSS commented Jan 27, 2018

Good job!
Is it compatible with current GPLv2 license of Psi? I heard there are license problems with official Signal implementation.
anurodhp/Monal#9 (comment)

@stigger

This comment has been minimized.

Show comment
Hide comment
@stigger

stigger Jan 27, 2018

Member

The referenced comment is about publishing an app that uses libsignal on Apple's App Store, which is not applicable for Psi. At the moment libsignal is licensed under GPLv3 with an exemption for App Store, so it should be compatible.

More details:

Member

stigger commented Jan 27, 2018

The referenced comment is about publishing an app that uses libsignal on Apple's App Store, which is not applicable for Psi. At the moment libsignal is licensed under GPLv3 with an exemption for App Store, so it should be compatible.

More details:

@mrDoctorWho

This comment has been minimized.

Show comment
Hide comment
@mrDoctorWho

mrDoctorWho Feb 16, 2018

Status update?

mrDoctorWho commented Feb 16, 2018

Status update?

@stigger

This comment has been minimized.

Show comment
Hide comment
@stigger

stigger Feb 16, 2018

Member

No updates at the moment, but planning to work on it this weekend.

Member

stigger commented Feb 16, 2018

No updates at the moment, but planning to work on it this weekend.

@milada-horakova

This comment has been minimized.

Show comment
Hide comment
@milada-horakova

milada-horakova Apr 5, 2018

any psi+ end to end encryption is currently broken with windows (10) portable version (psi-plus-1.3.306_win7_x86_64)

psi+ crashes on OTR key generation.
OMEMO can only receive but not send. also cannot send OMEMO to myself: *** [OMEMO] Unable to build any sessions, the message was not sent

this is an unlucky situation because both gajim and conversations dropped OTR in favour of OMEMO, but OMEMO is still experimental on psi+. nevertheless the OTR plugin should not crash so there is no constellation i can use psi+ with end to end encryption currently.

milada-horakova commented Apr 5, 2018

any psi+ end to end encryption is currently broken with windows (10) portable version (psi-plus-1.3.306_win7_x86_64)

psi+ crashes on OTR key generation.
OMEMO can only receive but not send. also cannot send OMEMO to myself: *** [OMEMO] Unable to build any sessions, the message was not sent

this is an unlucky situation because both gajim and conversations dropped OTR in favour of OMEMO, but OMEMO is still experimental on psi+. nevertheless the OTR plugin should not crash so there is no constellation i can use psi+ with end to end encryption currently.

@Ri0n Ri0n added this to the 2.0 milestone Apr 5, 2018

@tehnick

This comment has been minimized.

Show comment
Hide comment
@tehnick

tehnick Apr 5, 2018

Member

@milada-horakova

psi+ crashes on OTR key generation.

This is known bug in 64-bit version of libotr. You may use 32-bit version of Psi+ with OTR plugin until this bug is fixed.

OMEMO can only receive but not send. also cannot send OMEMO to myself: *** [OMEMO] Unable to build any sessions, the message was not sent

I have just re-checked it in clean Win8.1 environment and all work fine. Try to clear the list of your OMEMO keys from other XMPP client (for example, from Conversations or Gajim), then delete omemo.sqlite file from your Psi+ configs and then try OMEMO plugin from Psi+ again.

Member

tehnick commented Apr 5, 2018

@milada-horakova

psi+ crashes on OTR key generation.

This is known bug in 64-bit version of libotr. You may use 32-bit version of Psi+ with OTR plugin until this bug is fixed.

OMEMO can only receive but not send. also cannot send OMEMO to myself: *** [OMEMO] Unable to build any sessions, the message was not sent

I have just re-checked it in clean Win8.1 environment and all work fine. Try to clear the list of your OMEMO keys from other XMPP client (for example, from Conversations or Gajim), then delete omemo.sqlite file from your Psi+ configs and then try OMEMO plugin from Psi+ again.

@tehnick

This comment has been minimized.

Show comment
Hide comment
@tehnick

tehnick Apr 5, 2018

Member

this is an unlucky situation because both gajim and conversations dropped OTR in favour of OMEMO

This is a very strange decision. Usage of OMEMO is more simple from end user point of view, but OTR is more secure...

Member

tehnick commented Apr 5, 2018

this is an unlucky situation because both gajim and conversations dropped OTR in favour of OMEMO

This is a very strange decision. Usage of OMEMO is more simple from end user point of view, but OTR is more secure...

@nekoswag

This comment has been minimized.

Show comment
Hide comment
@nekoswag

nekoswag Apr 13, 2018

OTR is more secure

Could you explain this? I always thought OMEMO was more secure than OTR, because it has newer cryptographic primitives like Curve25519 for example.

nekoswag commented Apr 13, 2018

OTR is more secure

Could you explain this? I always thought OMEMO was more secure than OTR, because it has newer cryptographic primitives like Curve25519 for example.

@tehnick

This comment has been minimized.

Show comment
Hide comment
@tehnick

tehnick Apr 13, 2018

Member

Could you explain this? I always thought OMEMO was more secure than OTR, because it has newer cryptographic primitives like Curve25519 for example.

I am not talking about used cryptographic algorithms, but about whole architecture in common. For example:

  • Users are not forced to manipulate keys manually (in each device and/or client), authentificate interlocutor, etc.. It is optional.
  • By default devices keys are considered trusted. Yes, it simplify life for inexperienced users, but increases risks. More other, common users do not update their devices keys despite of this is supported by XEP and realized in most of XMPP clients.
  • Session keys in OMEMO are not updated during communication nor manually, nor automatically (it is possible in principle, but not described in XEP and not realized in XMPP clients which I saw).
  • Communication history may be stored on server side and decoded at any time later. Yes it is extremely convenient, but if offender will get or calculate (using computer cluster or quantum computer) your private key, the whole history will leak to him. Chats protected by OTR are usually not stored at all (even at current device).
Member

tehnick commented Apr 13, 2018

Could you explain this? I always thought OMEMO was more secure than OTR, because it has newer cryptographic primitives like Curve25519 for example.

I am not talking about used cryptographic algorithms, but about whole architecture in common. For example:

  • Users are not forced to manipulate keys manually (in each device and/or client), authentificate interlocutor, etc.. It is optional.
  • By default devices keys are considered trusted. Yes, it simplify life for inexperienced users, but increases risks. More other, common users do not update their devices keys despite of this is supported by XEP and realized in most of XMPP clients.
  • Session keys in OMEMO are not updated during communication nor manually, nor automatically (it is possible in principle, but not described in XEP and not realized in XMPP clients which I saw).
  • Communication history may be stored on server side and decoded at any time later. Yes it is extremely convenient, but if offender will get or calculate (using computer cluster or quantum computer) your private key, the whole history will leak to him. Chats protected by OTR are usually not stored at all (even at current device).
@themilkman

This comment has been minimized.

Show comment
Hide comment
@themilkman

themilkman Apr 14, 2018

Thank you for your detailed explanation to this, good points! 👍

themilkman commented Apr 14, 2018

Thank you for your detailed explanation to this, good points! 👍

@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Apr 27, 2018

More other, common users do not update their devices keys despite of this is supported by XEP and realized in most of XMPP clients.

What do you mean by "update"?

Session keys in OMEMO are not updated during communication nor manually, nor automatically (it is possible in principle, but not described in XEP and not realized in XMPP clients which I saw).

Do you know what the double ratchet does? It " updates" the session on every received and sent message, so your statement is wrong.

Communication history may be stored on server side and decoded at any time later. Yes it is extremely convenient, but if offender will get or calculate (using computer cluster or quantum computer) your private key, the whole history will leak to him. Chats protected by OTR are usually not stored at all (even at current device).

Communication is encrypted when stored on the server. Even if you would get acces to "the private key", you could only decode a limited amount of the data (exactly one message). One property of the axolotl ratchet is, that it is self healing and provides both forward secrecy, as well as future secrecy.

vanitasvitae commented Apr 27, 2018

More other, common users do not update their devices keys despite of this is supported by XEP and realized in most of XMPP clients.

What do you mean by "update"?

Session keys in OMEMO are not updated during communication nor manually, nor automatically (it is possible in principle, but not described in XEP and not realized in XMPP clients which I saw).

Do you know what the double ratchet does? It " updates" the session on every received and sent message, so your statement is wrong.

Communication history may be stored on server side and decoded at any time later. Yes it is extremely convenient, but if offender will get or calculate (using computer cluster or quantum computer) your private key, the whole history will leak to him. Chats protected by OTR are usually not stored at all (even at current device).

Communication is encrypted when stored on the server. Even if you would get acces to "the private key", you could only decode a limited amount of the data (exactly one message). One property of the axolotl ratchet is, that it is self healing and provides both forward secrecy, as well as future secrecy.

@tehnick

This comment has been minimized.

Show comment
Hide comment
@tehnick

tehnick Apr 27, 2018

Member

More other, common users do not update their devices keys despite of this is supported by XEP and realized in most of XMPP clients.

What do you mean by "update"?

In OTR Plugin there is pushbutton "Generate new key". And only current XMPP client will be affected. In such way user may easily update his(her) private key any time s(he) find this necessary.

With OMEMO all is more global: there is "Clear devices" pushbutton which will cause to re-generation of "private keys" on all devices. And users use it more rarely.

Do you know what the double ratchet does? It "updates" the session on every received and sent message, so your statement is wrong.

It looks I remembered this wrong (or mixed up with another algorithm): I thought the session id for each two "devices" is generated only once during session initialization (if they do not have a common session yet) and is constant after that. In such case you need delete session id or device id to start a new session.

But after re-reading on OMEMO specification I see that session id is updated after receiving of each new message using an unique key from it.

Communication is encrypted when stored on the server. Even if you would get acces to "the private key", you could only decode a limited amount of the data (exactly one message). One property of the axolotl ratchet is, that it is self healing and provides both forward secrecy, as well as future secrecy.

Ok. You are right.

So a history with OMEMO encrypted messages on server side is less useful than I thought: it may be decrypted only one time (from each device) and after that it become useless.

Member

tehnick commented Apr 27, 2018

More other, common users do not update their devices keys despite of this is supported by XEP and realized in most of XMPP clients.

What do you mean by "update"?

In OTR Plugin there is pushbutton "Generate new key". And only current XMPP client will be affected. In such way user may easily update his(her) private key any time s(he) find this necessary.

With OMEMO all is more global: there is "Clear devices" pushbutton which will cause to re-generation of "private keys" on all devices. And users use it more rarely.

Do you know what the double ratchet does? It "updates" the session on every received and sent message, so your statement is wrong.

It looks I remembered this wrong (or mixed up with another algorithm): I thought the session id for each two "devices" is generated only once during session initialization (if they do not have a common session yet) and is constant after that. In such case you need delete session id or device id to start a new session.

But after re-reading on OMEMO specification I see that session id is updated after receiving of each new message using an unique key from it.

Communication is encrypted when stored on the server. Even if you would get acces to "the private key", you could only decode a limited amount of the data (exactly one message). One property of the axolotl ratchet is, that it is self healing and provides both forward secrecy, as well as future secrecy.

Ok. You are right.

So a history with OMEMO encrypted messages on server side is less useful than I thought: it may be decrypted only one time (from each device) and after that it become useless.

@vanitasvitae

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Apr 27, 2018

With OMEMO all is more global: there is "Clear devices" pushbutton which will cause to re-generation of "private keys" on all devices. And users use it more rarely.

This is wrong. The function will only "unpublish" OMEMO key material from the server. The actual keys stay untouched. Once an "unpublished" device comes online, it will republish its keys again.

However, some implementations offer you an option to regenerate your identity, which will delete the OMEMO keys of the device and create new ones.

So a history with OMEMO encrypted messages on server side is less useful than I thought: it may be decrypted only one time (from each device) and after that it become useless.

Exactly :)

vanitasvitae commented Apr 27, 2018

With OMEMO all is more global: there is "Clear devices" pushbutton which will cause to re-generation of "private keys" on all devices. And users use it more rarely.

This is wrong. The function will only "unpublish" OMEMO key material from the server. The actual keys stay untouched. Once an "unpublished" device comes online, it will republish its keys again.

However, some implementations offer you an option to regenerate your identity, which will delete the OMEMO keys of the device and create new ones.

So a history with OMEMO encrypted messages on server side is less useful than I thought: it may be decrypted only one time (from each device) and after that it become useless.

Exactly :)

@BigGiantHeadsHighCommander

This comment has been minimized.

Show comment
Hide comment
@BigGiantHeadsHighCommander

BigGiantHeadsHighCommander Jul 11, 2018

@tehnick [re Apr 13]

authentificate interlocutor,

I miss the Socialist Millionaire Protocol (to authenticate identity) but unfortunately it crashed receiver's clients. I wish SMP was an option to OMEMO authentication.

Communication history may be stored on server side and decoded at any time later.

mam / carbons should expose an additional setting in 'client's server archival preference' as in some clients [Conversations] to purge chat history after specified window. Not for the reason of your concern necessarily, but for the occasional client [Conversations] but of close/erase history, start new conversation, server archive restores.

You might want to read RiseUp.net critique of OMEMO.

@tehnick [re Apr 13]

authentificate interlocutor,

I miss the Socialist Millionaire Protocol (to authenticate identity) but unfortunately it crashed receiver's clients. I wish SMP was an option to OMEMO authentication.

Communication history may be stored on server side and decoded at any time later.

mam / carbons should expose an additional setting in 'client's server archival preference' as in some clients [Conversations] to purge chat history after specified window. Not for the reason of your concern necessarily, but for the occasional client [Conversations] but of close/erase history, start new conversation, server archive restores.

You might want to read RiseUp.net critique of OMEMO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment