Что: 3be33febda3acdc0711dd466d76e97d6192c6185
Когда: 2021-11-19 11:42:13+03:00
Темы: 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.
Сгенерирован: SGBlog 0.34.0