[about] [index] [prev] [2021-11-19 11:42:13+03:00] [3be33febda3acdc0711dd466d76e97d6192c6185]
Topics: [crypto]

Стоит ли OTR использования в XMPP?

Написал тут одному человеку своё мнение про OTR протокол, почему бы и
сюда не скопировать?

    >Do you know about the OTR protocol? Is this worthwhile?

    Yes, yes and yes :-)!

    >I have a small Prosody server running on my Beaglebone
    >Black through which I use mcabber to chat over XMPP with
    >two friends.

    Both prosody and mcabber were my favourite server/client programs
    (when I used XMPP).

    >I wonder if OTR is a good alternative.

    First of all: they can not be compared so easily, because they are aimed
    for very different tasks. OTR is intended to be used in online
    interactive conversations only. Main PGP disadvantage is its lack of
    so-called forward secrecy feature: if your long-term (and PGP has only
    long-term keys) keys are compromised, then every previously sent message
    can be decrypted. Ephemeral (Diffie-Hellman) key exchange must be done,
    to use ephemeral (non long-term living) keying material for forward
    secrecy, but that forces you to do at least one additional full
    round-trip, that is not the use case for PGP (where you can just "fire"
    message and forget about it).

    OTR is aimed exactly for ephemeral conversations, with full forward
    secrecy. They use Diffie-Hellman exchange with every message exchange,
    so even compromising of current session keys won't harm for future
    messages done during the current session/conversation. Of course by the
    price of CPU overhead and slightly increased traffic (comparing to
    purely symmetrically encrypted ciphertexts), but OTR is for human text
    conversations, that are very low traffic with relatively small messages,
    so that DH overhead should not be noticeable in practice.

    OTR also even offers deniability of the authorship on the message: you
    can verify the authenticity of the incoming message immediately, but its
    authentication MAC key will be revealed in next messages -- so any third
    party can create valid "signature" on any previous message, that means
    that noone can prove that only and only you could be the author of some
    exact message. Actually I doubt that there was any occasions where it
    (deniability property) helped and was useful to anybody, but it is cool
    thing in theory that is practically made :-)

    OTR additionally has an additional zero-knowledge authentication scheme
    SMP: https://en.wikipedia.org/wiki/Socialist_millionaire_problem
    That thing technically is just for comparing two strings, without
    revealing their values to the opposite side. For example you start
    conversation with somebody without preliminary known public key. Or
    possibly someone steals the computer of the buddy and its keys are
    compromised. And you decide to authenticate that person by asking
    question where the answer must be known only to both of you, something
    like "what was I wearing yesterday on my head" (of course it should be
    something more serious and less predictable). You and the buddy on the
    other side enter the expected answer and SMP protocol checks those
    strings equality, without revealing possibly compromised opposite side
    the exact value of the answer.

    OTR is valuable by the fact that it is very widely supported in
    software. Its messages are plain-text ASCII Base64 encoded strings, that
    can be sent over *any* text protocol. So you can use OTR over virtually
    any text-based message protocol. For example irssi IRC client has its
    built-in support and no support from the transport (IM) protocol is
    needed at all: if I use irssi with bitlbee with XMPP -- I just use
    irssi's built-in OTR support. I am sure that OTR is the most widely
    supported online IM protocol (I mean by number of implementations and
    client support, not by the absolute numbers, where any WhatsApp/Telegram
    will beat it).

    The only bad thing about OTRv3 (older version are not used) -- it uses
    quiet ancient and slow cryptographic algorithms. That is not the real
    problem, but its DH key sizes are only 1536-bits. Well, that still
    enough nowadays, especially when we are talking about ephemeral keys,
    not the long-term used for years (as in PGP). But more modern IM
    protocols with elliptic curve based algorithms will be much more faster
    (CPU time) and have much smaller key sizes.

    There is very good survey on all modern IM E2E protocols:
    https://hardenedvault.net/2021/06/02/vault1317-thesis.html
    PGP lacks PFS property -- this is the main disadvantage, plus it has
    pretty big overhead per message. OTRv3 is very well known, supported and
    still beating beating nearly everybody by its deniability property.
    Signal protocol -- *very* good, very modern, very effective and very
    respectful from cryptographic point of view. OMEMO, OLM -- they are used
    in XMPP (optionally) and in Matrix protocol. I have never seen and used
    any XMPP client with OMEMO support, but I heard that many used it for
    years. OMEMO seems to be quiet good, definitely better than PGP, except
    that it is XMPP-specific and requires all participating XMPP-clients to
    support it. OTRv4 should be the coolest one, that took in advance all
    experience in E2E protocols development and research, but... its author
    is in Equador's prison: https://en.wikipedia.org/wiki/Ola_Bini
    OTRv4 draft exists and still developed, but it is backwards incompatible
    with OTRv3 and requires many libraries/clients update to support it.

    So if you have got OMEMO-compatible XMPP-clients, if you do not need
    identity anonymity preserving and deniability properties, do not need
    interactive zero-knowledge authentication feature (SMP protocol), then
    OMEMO can be recommended, at least for better efficiency. OTRv3 is also
    not in favour by many people by its inability to send a message when
    opposite party is not online (obviously no ephemeral key establishment
    can be done), but OMEMO (like Signal and others) can store pregenerated
    ephemeral keys on the server, so other people can still send you the
    message while you are temporary offline. But MCabber does not support
    OMEMO, so OTRv3 is the remaining choice, really better than PGP.

[leave comment]