7 ms·

> Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/ recently. Signal, Matrix, Telegram, XMPP; U

> Also relevant https://soatok.blog/2024/08/04/against-xmppomemo/ https://soatok.blog/2024/08/04/against-xmppomemo/ recently. Signal, Matrix, Telegram, XMPP; Use whatever you want. But there is a lot of FUD if not outright lies in that blog post. The author looked at Conversations for all but five minutes, desperately trying to dig up some dirt.

Kye 2y ago
>> "But there is a lot of FUD if not outright lies in that blog post. " For example...
- inputmice 2y ago
  * Conversations uses two different OpenPGP implementations. (It doesn’t) * The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely * ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool) * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
  - some_furry 2y ago
    > * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS) It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202. Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway. "Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
    - inputmice 2y ago
      There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.

Kye 2y ago

>> "But there is a lot of FUD if not outright lies in that blog post. " For example...

inputmice 2y ago
* Conversations uses two different OpenPGP implementations. (It doesn’t) * The auth tag truncation was 'silently' introduced in the spec. It wasn’t. The author retracted that but only barely * ominously pointing out that Conversations has a SASL implementation (In fact Conversations can use that to detect some MITM attacks; which is pretty cool) * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS)
- some_furry 2y ago
  > * ominously pointing out that Conversations has a certificate parser (yes and so does almost everything that uses TLS) It's trivial to use TLS without writing your own certificate parser. Doing this means taking on a lot of unnecessary risk, such as CVE-2023-33202. Your encrypted messaging application shouldn't need to have a separate X.509 or ASN.1 parser built into it. If you're going to use them from TLS, you should rely on the library your OS vendor maintains for you, since they have an incentive to keep theirs secure anyway. "Ominously pointing out" that the Conversations project has taken on an unhealthy amount of complexity and risk isn't FUD, it's a criticism of how the project is managed. Confuse the two at your own peril.
  - inputmice 2y ago
    There are certificates that are valid for the XMPP domain example.com but not for the regular (HTTP) server on example.com. Off-the-shelf verifier don’t have support for that.