[conorpp]

Have you heard of or used signal?

https://whispersystems.org/

Same idea -- strong crypto that's usable for anyone. It uses the OTR Ratchet protocol which uses perfect forward secrecy. The app also provides a way to verify keys through an OOB channel.

I would recommend considering OTR Ratchet integration just like WhatsApp did recently.

PGP is not a good design choice for a messaging app as you're always using asymmetric crypto operations which are computationally intense -- not terrible on modern computers but will be dreadful on mobile devices. Also can you provide some more documentation on how the app leverages PGP? Hopefully conversation is not using the same private keys to encrypt. That is vulnerable to data or side channel leakage. The modern approach is to generate and exchange an ephemeral key. Also please provide information on key storage.

Rather than making vague security claims like "first-rate" and " Security++ to the greatest extreme" you should rather provide a threat model and explain why one can remain confidential and have authenticity against particular types of adversaries. No security tool is perfect and it's only a matter of time before an adversary breaks it. Developers are doing a disservice by claiming anything more.

Before you can claim a first-rate security tool you will need to face a lot of scrutiny first.

[iancarroll]

PGP is a great choice when you want to be able to send encrypted messages over any channel you want. It sounds like you do not understand how PGP works -- you exchange public keys over a trusted medium and then use public key cryptography to encrypt the AES key used to encrypt the rest of the message.

The OpenPGP library it uses has been audited (twice). Most of the mistakes that could have be made are avoided this way.

Edit: Yes, you lose PFS by using PGP, but it would not really be possible to negotiate PFS via, say, email.

[cyphar]

> PGP is a great choice when you want to be able to send encrypted messages over any channel you want.

That has nothing to do with PGP. You could do the same by base64-ing an OTR session (in fact, people do that all the time).

I don't like the choice of PGP because it has non-repudability. If you send me a message, I can prove to anyone in the world that you sent me the message. OTR and Axolotl don't have this problem (only I can be sure you sent me the message and I cannot prove that I didn't fake it to anyone else).

[fabiom]

> If you send me a message, I can prove to anyone in the world that you sent me the message.

Only if you sign the message, right? But you can use PGP to send encrypted messages without signing them.

[cyphar]

And then if the message is corrupted you have know way of knowing. Not to mention that essentially nobody uses those modes.

Axolotl and OTR provide signatures, just that they are "non-transferrable" (so to speak). Not to mention that the actual crypto is more modern.

[e12e]

> That has nothing to do with PGP. You could do the same by base64-ing an OTR session (in fact, people do that all the time).

But PGP also works for printing stuff on a post-card (or you know, email) - asynchronous communication. While Axolotl does push OTR-like modes towards asynchronous use - they do involve a lot more than getting hold of a public key (say, one published in a magazine, or shown in a frame of a movie, or...).

There's been an argument since the early crypto-wars about whether gpg/pgp could (should) be made easier to use. And I absolutely think it could (and should).

Key distribution is still hard, but it's not helped by a silly cli app, and no great recommendations on how to manage trust (I suppose the gist is: get a hw token for your key, print a backup and store a revocation order in a safe, sign keys you trust and upload them to the keyservers. But even if that list seems easy, users are left with questions like: which hw tokens should I use? When I lose it, "re-trusting" keys? How big a problem is it that I've just exported meta-data about who I communicate with? Which clients easily integrates with my hw token so that I can use gpg on my smart phones, my laptop and my desktop? What if my phone lacks NFC? Can't use USB host? And last, but certainly not least -- why isn't there a fork of gpg2 that does "the right thing(tm)" out of the box -- and make this "best of breed" flow easy, rather than making all kinds of sub-key shenanigans equally cryptic?)

[cyphar]

If you don't need PFS (which you should need) then you can use DH to create the shared key you use for the HMAC. Maybe you could even do an original OTR-like ratchet scheme (only change the key once the recipient shows that they are using the new key) to get PFS. But in principle if you assume that key distribution is "solved" then you can implement the unique parts of OTR.

[e12e]

I'm not sure, you're saying the format and message standards of PGP of providing machine-readable signed keys aren't worth anything, because you can just memorize some base64 coded secrets and run with it?

That's how you'd prefer to bootstrap secure communication with a journalist, or for recruiting people to demonstrate against the current regime in Egypt?

> But in principle if you assume that key distribution is "solved" then you can implement the unique parts of OTR.

How can it make sense to think of it as solved? How do you backup your keys? Your list of trusted keys? Protect them against theft? Alert others to their compromise? Get alerted when keys are compromised?

Key distribution really is the only really interesting problem in secure, trusted, communication (with secure one time pads, most problems go away. The trick is to make sure you have secure one time pads, shared only with the person(s) you want to communicate with...).

Public key encryption opens up some new ways to make the problem easier, but it's just one step in the right direction.

[cyphar]

My point was that if PGP was suitable for "usable" encryption (which is the whole point of this program), then you could use the same key distribution methods but use Axolotl.

[conorpp]

Yes you're right.

It's hard to say that most mistakes are avoided from two audits. Especially in a browser; there's a lot of attack vectors.

[btreecat]

>you exchange public keys over a trusted medium and then use public key cryptography to encrypt the AES key used to encrypt the rest of the message.

What do you consider a "trusted medium?"