That would require us to use an external library (most likely rnp from Mozilla).

@wojtek Am I correct, that with OpenPGP for E2E and key synchronization between devices it would be better (and more usable) that OMEMO. From the end-user viewpoint) it would allow user to "restore" his encryption key from the server (after providing a password to decode it) he would be able to restore whole his message history which is not possible with OMEMO.

@kobit What would you think about adding this feature and using rnp library from Mozilla.

@andrzej.wojcik I'd say yes. There may be cases where PFS may be required, but for majority of the users having E2E and convenience of history synchronisation would win easily (I know it does for me).

One thing that I'm curious about are security implications of storing private key (password-protected) on the server in PEP. It's defined XEP-0373: OpenPGP for XMPP in but still - private key leaves our device. While this most likely is more convenient for the server, I'm kinda iffy about that (@bmalkow - any thoughts?). XEP-0373 is optional so maybe we could share private keys via QR code or something like that? (I was concerned about the sizes and QR code limitations but found https://github.com/z9u2k/rsqueezea, which looks interesting)

@wojtek Storing private key on the server is iffy. I was considering exchange done either with QR code (key in QR code), or by QR code being used as a "token" to confirm OOB (WebRTC data stream) or IBB (IQ/PubSub with strong key encryption) code exchange, but storing the encrypted key on the server is convenient.

Also, the PEP node according to the specification should be configured with access model whitelist which should, in fact, be available only to the owner (or system admins). Keeping encrypted keys in this way may not be insecure, but for sure it is not very secure.

be available only to the owner (or system admins). Keeping encrypted keys in this way may not be insecure, but for sure it is not very secure.

Exactly. And if we have alternatives (and I think we do) to using XMPP server to exchange the keys, then having OX wouldn't be worst than OMEMO (in the forseable future).

+1 or even +11, I like it way more then OMEMO

I've tried to review what we can do to add support for OpenPGP and I've found that this can be problematic. There are a few libraries that we "could" use, but each of them has its own problems.

1. ObjectivePGP That could be the simplest one to use (as it is already written for Objective-C, so it would be really easy to use if from Swift). However, it is dual-licensed. For non-commercial usage it is BSD, but for commercial (even if apps are free) this requires a separate license from the author. Internally, this library relies on the OpenSSL library which we are already using anyway, but we may be forced to embed the same version for our app and the one required by this library.

2. NetPGP This is an older library created in plain C, so we would need to wrap it in Swift, but that should be rather simple. As the library is licensed under a 2-clause BSD license it should be usable for us. However, it relies on OpenSSL, the latest version is from 2014, and there is limited documentation. Also, this library stores keys internally and it would be tricky to hook it up to use KeyChain.

3. libGPGME This library is licensed under GPLv2, with parts licensed under LGPLv2 and MIT. This library relies on other libraries such as libassuan and libgpg-error (most likely on gnupg as well), so to use it we would need to embed this whole stack and it is rather large. As this is GPLv2 and not v3, we may not need to have permission for distribution in the AppStore (as we were forced to have for libsignal - permission published on their website).

I've also checked the possibility to implement OpenPGP support on our own as it doesn't look very problematic. The biggest issue would be relying on OpenSSL (for RSA support and maybe some other algorithms) as OpenPGP may use many different types of keys (RSA, ECDH, ElGamal) for key exchanges and then internally for data encryption any of AES(128/192/256), Twofish256, Blowfish, CAST5, IDEA, TripleDES algorithms (not to mention many different hashing algorithms or compression algorithms).

That makes implementation problematic as we would need to embed a lot of libraries. However, using one of the libraries mentioned before will force use to embed their dependencies anyway (ie. bzlib, openssl or gnupg).

Anyway, to move forward we would need to make a decision, about which library we would like to use or decide that we need to build our own. I would prefer to use ObjectivePGP (looks simplest to embed) or libGPGME (the most recent).

@kobit Could you check if any of those libraries (and their licensing) would work for us?

I think the ObjectivePGP is the most sensible option for us. Could you contact the author and ask if we need paid license? Our software is free and open source but we also offer commercial license. Also, for the case like Tygrys, all the software is free and open source but we would sell some services based on the software.

And then how much would be the commercial license.

In case of Tygrys, we may have even bigger issue, as we will need to use Kotlin multiplatform, so either we would need to have PGP library written in Kotlin native or we would need to have a separate library for each platform.

I'll contact ObjectivePGP developer.