4 ms·
Could you elaborate on what do you mean by that? It's possible to use OpenPGP in instant messaging [0] and it works fine (transparent encryption and decryption
by Shoothe 9y ago
Could you elaborate on what do you mean by that?
It's possible to use OpenPGP in instant messaging [0] and it works fine (transparent encryption and decryption in a client) although there are newer solutions more suited to IM [1].
[0]: https://xmpp.org/extensions/xep-0027.html https://xmpp.org/extensions/xep-0027.html
[1]: https://xmpp.org/extensions/xep-0384.html https://xmpp.org/extensions/xep-0384.html
- dsacco 9y ago> It's possible to use OpenPGP in instant messaging [0] and it works fine (transparent encryption and decryption in a client) For some definitions of "possible" and "works fine", sure. But OpenPGP is not natively designed for instant messaging. You can use OpenPGP as the public-key component of a cryptosystem that is suited for instant messaging, but at that point you're better off just going with an OTR protocol that already has the key-exchange and secret-key encryption functionality baked into it. Beyond that, the page you're citing mentions this: > The method defined herein has the following security issues: > Key exchange relies on the web of trust model used on the OpenPGP keys network. > There is no mechanism for checking a fingerprint or ownership of a key other than checking the user IDs on a key. > When the recipient is not mentioned in the encrypted body, replay attacks are possible on messages. > Replay of the signed <presence/> status is possible. > It relies on signing or encryption of XML character data; therefore, it does not support signing or encryption of <iq/> stanzas, and it allows signing of the presence <status/> element and encryption of the message <body/> element only. > Thus the method is not acceptable when signing or encryption of full stanzas is required. It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body. In particular, the warts of using an asynchronous protocol for a synchronous communication system are exposed here: you can replay the signed presence status, which sort of defeats the purpose of having an open connection. In a secure, synchronous communication channel, the "freshness" checks incorporate non-repudiation. This is before we even address the problem of not being able to verify key ownership aside from the user IDs.
- Joeboy 9y agoI mean that at least relatively speaking, nobody[1] uses OpenPGP for messaging, so it's not a threat to Signal's market share. Which is presumably the implied motive for Moxie to trash talk OpenPGP. [1] I can admittedly think of two people I know for whom I could probably find public keys and who would probably be able to decrypt a PGP'ed email if I were to send them one, but they're both Debian maintainers who I met via IRC. Whereas I have maybe a couple of hundred people on my phone from various walks of life I could send Signal messages to with literally no extra effort.
- Shoothe 9y ago> Which is presumably the implied motive for Moxie to trash talk OpenPGP. I'd rather say that Moxie implies that OpenPGP is broken beyond repair and thus the only alternative is his centralized solution. While he doesn't say this explicitly his other post (The ecosystem is moving) says exactly this. Your anecdotal evidence while interesting does not show that OpenPGP cannot be improved, only that given enough government funding you can build a nice centralized, encrypted solution but as the top comment by lmm shows [0] it's not clear what audience is Signal aimed at: > There is no threat model where Signal makes sense. [0]: https://news.ycombinator.com/item?id=16062193 https://news.ycombinator.com/item?id=16062193