offline message end-to-end encryption via AGP

[hmeyer]

Security is essential for mobile instant messaging. While OTR is very common in Jabber implentations nowadays it is quite impractical in a mobile environment. In those environments network connections aren't stable, IPs change, partys become offline from time to time.
As OTR needs both partys online for direct handshake OTR won't work flawlessly in such environments.
One solution might be to give up some of the nice additional privacy properties of OTR and switch back to simply Public Key Crypto. Therefore:

Please integrate AGP (http://thialfihar.org/projects/apg/) into Yaxim. Make Yaxim the first working secure mobile messenger!

[mentago]

I am very greate pleasure to take part in the AGP~ How to participate?

2012/11/23 Henning Meyer notifications@github.com

Security is essential for mobile instant messaging. While OTR is very
common in Jabber implentations nowadays it is quite impractical in a mobile
environment. In those environments network connections aren't stable, IPs
change, partys become offline from time to time.
As OTR needs both partys online for direct handshake OTR won't work
flawlessly in such environments.
One solution might be to give up some of the nice additional privacy
properties of OTR and switch back to simply Public Key Crypto. Therefore:

Please integrate AGP (http://thialfihar.org/projects/apg/) into Yaxim.
Make Yaxim the first working secure mobile messenger!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/83.

[hmeyer]

I guess it's fork, implement and publish git-pull requests.
First of all we would need to select a number of pgp-capable Jabber-Clients, which we can use for testing our implementation. As far as I know Psi should be PGP-capable, although I never tried to use it.

[mentago]

sorry~ I can not quite follow you~

2012/11/23 Henning Meyer notifications@github.com

I guess it's fork, implement and publish git-pull requests.
First of all we would need to select a number of pgp-capable
Jabber-Clients, which we can use for testing our implementation. As far as
I know Psi should be PGP-capable, although I never tried to use it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/83#issuecomment-10650298.

[untitaker]

I think OTR support would be way more useful in practice, since it has a larger user base.

[ge0rg]

OTR is already requested in #82, I will comment on that there. What is needed in the XMPP message format to indicate PGP encryption at work?

[hmeyer]

@untitaker I disagree. OTR is not made for unreliable (e.g. mobile) networks. See @ge0rg post in #82.

[untitaker]

@hmeyer I didn't say OTR would be a technically better solution (i don't know about that)

[hmeyer]

@untitaker I doubt it even would be more useful. Because OTR just doesn't work in mobile networks.

[doits]

there's also an AIDL-Branch of APG. I could try to get this merged into mainline of APG if you prefered to use this way to communicate with APG. Encrypting strings (messages sent by yaxim) is easy with it (with public/private keys or passwords).

[ge0rg]

Check also this fork, it seems to be still under development.

I would prefer a solution that uses Intents to the APG app, not one that carries the whole code within yaxim.
Also, it should integrate with a version of APG that is available via Google Play, for the easiest user experience. I would not mind putting my own fork on Google Play for that, but I did not manage to compile the dschuermann code so far.

[doits]

I would prefer a solution that uses Intents to the APG app, not one that carries the whole code within yaxim

AIDL does exactly this: It is just an interface to APG to call from external programs. Basically an API to access APG from anywhere with simple (async) function calls. (Intents can provide something similar afaik, but I found AIDL easier to implement when I developed a programm some years ago).

Check also this fork, it seems to be still under development.

I see an AIDL interface is noted there in readme, too. I'm not sure what's exaclty new about this fork (or is it simply developing APG further, because main development stalled?).

[ge0rg]

• Markus Doits notifications@github.com [2013-01-19 14:51]:

  AIDL does exactly this: It is just an interface to APG to call from external programs.

Ok, I am fine with this. So far I only used AIDL for app-internal services, therefore the misunderstanding. Feel free to add support! :)

I see an AIDL interface is noted there in readme, too. I'm not sure what's exaclty new about this fork (or is it simply developing APG further, because main development stalled?).

I suppose it is doing further development, like an improved UI. Not sure if it is maintaining API compatibility, at least I could not find the new version on Google Play - therefore I would suggest providing compatibility with the official release, even if it is outdated.

[hmeyer]

corresponding XEP: http://xmpp.org/extensions/xep-0027.html

[kevincox]

Just adding that Gajim has support for GPG as well so that would be good for testing.

[sbriskin]

There are no any changes on this issue for a long time. Hope you'll not forget about it. OTR works terrible on most clients. With SSL, if the latest news about NSA are true, there is no secure data transfer between clients and servers, so GPG is realy needed. I hope yaxim would be the first mobile client that could make our talks really secure.

[jplitza]

XEP 0027 has been obsoleted by the XMPP Council in its 2014-04-12 meeting because it's massively flawed (only encryption, no signing, no replay-attack protection), see XMPP E2E Security.

You might want to reconsider its implementation.

[dschuermann]

If you still want to implement some sort of PGP support, consider using our new API. See https://github.com/open-keychain/open-keychain/wiki/OpenPGP-API

[ge0rg]

It seems like there remains no usable specification for OpenPGP integration in XMPP clients. I will close this issue for now, until a new XEP emerges for that, or until DTLS-SCTP provides sufficient maturity to be a full replacement.