I will just correct that Signal in fact is a protocol too now. Axolotl protocol
was renamed to Signal protocol and is used in Signal application and a few
others. It is a modification of OTR protocol, a major feature it adds is
ability to send message without initiating a secure session requiring two
client to be online before (OTR requires that and messages send to offline
contacts are not encrypted). It should be as easy to implement as OTR, but
provides some useful features like offline messaging and is new.
Thanks for the replies, this clears a lot for me. I'm awaiting some better
solution for out-of-call messaging.
Keep up the good work!
-------- Original Message --------
Subject: Re: [Ring] Are text messages encrypted?
Local Time: August 8, 2016 6:54 PM
UTC Time: August 8, 2016 6:54 PM
From: [email protected]
To: [email protected]
CC: [email protected]
Hi Takeback,
Disclaimer: I base following comparison using code and information publicly
available on web sites, see References foot-notes.
This represents my own comprehension of these information and not a view of
their respective authors.
** NaCl
NaCl is a crypto-library, not a protocol. It's comparable to nettle, a
crypto-library used by gnutls. Both gives almost same features for our needs.
** Signal
Signal is also not a protocol, it's an application (well in fact it's multiple
projects: a base library in many languages and many clients based on)
to exchange messages and RT media between peers.
Underlaying architecture uses SRTP and ZRTP (on the Android client) for an
authenticated/encrypted RTP transport.
Based on code found on their github repository [1], the SRTP is the classical
one as defined by rfc3711 [2]: so a AES-CTR-128 to (en/de)crypt and a HMAC-SHA1
for authentification.
So it's exactly what we provide today, just notice we use DTLS for the
ephemeral-keys exchange (made over SIP signaling).
I've not searched how Signal exchange SRTP key, I let you discover that :-)
The real difference is in the support of ZRTP, an alternative to DTLS-SRTP
method.
Both are PFS, to usage of ephemeral keys protects each session against possible
key discovery: compromise one session-key doesn't compromise all sessions.
For messaging, I found some code using AES-CBC (256bits key ???), I don't know
for authentification... I let you find.
** OTR
This is a protocol [3]: it could be also seen as an altenative to DTLS-SRTP,
except that the latter is dedicated to RTP packet transport and the former is
dedicated to messaging.
OTR in its version 3 uses long-term key pair for authentification (only) where
public parts are exchanged using a Diffie-Hellman (DH) method for to create a
un-authentified but crypted channel.
This is described by Authenticated Key Exchange chapter in [3]. When this step
is done, messages are exchanged by using an AES-CM-128 as cipher and SHA-256 as
HMAC..
Keys needed to this cipher is also created/exchanged using again a DH method.
So it's PFS, only the HMAC used by OTR is -superior- on the one used by classic
SRTP.
** TLS
TLS is a protocol giving a method to negotiate a cipher-suite, keys and
certificates and making secure connections between a client and a server.
So it's a layer on top of a crypto-library (like nettle or NaCl).
TLS is not dedicated to a particular usage, letting the application decide that.
TLS runs over TCP socket and DTLS over UDP sockets.
** Ring
You know... :-)
I just emphasis the fact we've differents methods depending on the final usage:
- Ring accounts use DTLS-SRTP for SIP and RTP (media) messages.
- IMs have two methods of transport:
1) over the SIP channel when a call is on going
2) over the DHT when not in call (aka "offline-messaging")
The case 2) uses long-term key-pair (the one associated to the RingID) for
authentification and encryption.
This is -not- a PFS method, we're aware of that, and we search for a better
solution. Offline messaging is an active subject of research.
It's not easy as the peer is not supposed to be connected (that's why we use
the DHT).
A possible idea is to generate a pool of keys during the trust-request (when
you ask to be a friend), but trust-request are in going for implementation.
Then re-generate the pool when keys are consumed.
** Final notes
- SRTP is not made for general messaging, it's only dedicated to secure RTP
packets, nothing else.
- Signal uses secure MMS but I don't look how it's implemented in details, so I
can't tell more.
- OTR doesn't support offline messaging (correct me if I'm wrong).
- we're all use the same cipher (AES), so speed is not different (HW accel
exist for such cipher), some uses 128-bits key (mostly all), some 256 (Signal?
also use 128 version for SRTP).
- not listed here, but some messager uses AEAD ciphers, like AES-GCM or
ChaCha20-Poly1305... they are better than all previously auth/encrypt methods.
But it's another story :-)
A work is in WIP in Ring to support an AEAD cipher for SRTP.
-guillaume
References:
[1] https://github.com/WhisperSystems/Signal-Android
[2] https://tools.ietf.org/html/rfc3711
[3] https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html
----- Le 7 Aoû 16, à 8:02, Takeback <[email protected]> a écrit :
@Guillaume Roguez
"TL;DR: IM messages are as secure as SIP packets. We use DTLS for that, with
PFS cipher suites."
How does this compare to protocols such as OTR, Signal, NaCl?
// Answer to the whole message.
So as I understand DTLS (which is normal TLS, right?) is used, but not
client-server, but client-client thanks to P2P? And perfect forward secrecy
ciphers provide similar security to protocols such as OTR and Signal, but the
key exchange is done automatically (unlike OTR) and the security keys (to check
if there's eavesdropping present) are not available? Am I missing something?
Is this a proper and secure way to use TLS? I'm asking because I'm not aware
that TLS was designed to be used this way and in security very little things
may pose huge risks.
Also, AFAIK SRTP was designed with low latency, that is speed in mind. I'm
guessing the crypto in it is not as good as in message encryptionzz protocols.
"Now, out-of-call messaging is another story and use DHT and RSA-AES to secure
the transmission."
Um, is that it? Shouldn't there be key-exchange, perfect forward secrecy etc.,
all the feature protocols provide?
-------- Original Message --------
Subject: Re: [Ring] Are text messages encrypted?
Local Time: April 4, 2016 3:54 PM
UTC Time: April 4, 2016 3:54 PM
From: [email protected]
To: [email protected]
CC: [email protected]
Hi Takeback,
TL;DR: IM messages are as secure as SIP packets. We use DTLS for that, with PFS
cipher suites.
I know it's confusing for non-crypto-aware guy. But it's not so complex... just
a bit subtle :-)
This is how it works, not in hard details, but how flows are organized:
1) When 2 peers do a call connections, IPs of both are resolved using DHT/ICE.
The result of ICE negotiation is a normal UDP socket (non secure): one for each
peer.
Ring connects these endpoints together.
2) These sockets are carrying a DTLS connection: we obtain a secure transport.
Used cipher depends on negotiation, but on Ring PFS ciphers are enforced.
3) Finally we use this secure channel to transport SIP packets, starting by an
INVITE packet.
=> As this SIP channel is secured by DTLS and IM messages during this call are
sent as «SIP MESSAGE» packets, they are secure.
4) When the callee has accepted the call (hangup), each peers know how many
media (realtime audio/video) ports have to be open.
These port are open re-using ICE information of the SIP channel, using another
ICE handler to obtain enough sockets to transport these media channels.
5) We're using SRTP to transport media RTP data on these socket. SRTP uses
AES-128 to encrypt data: this requires a password to process.
This last is choosen by sender and sent in clear in the invite SIP packet
(during points 3 & 4). But as the SIP channel is encrypted, passwords are not
in clear on network.
Now, out-of-call messaging is another story and use DHT and RSA-AES to secure
the transmission.
ZRTP is an alternative to DTLS-SRTP method and uses AES as SRTP to encrypt data.
RSA != TLS, TLS uses RSA, as PGP uses also RSA.
I hope this clarifies things for you ;-)
-Guillaume
----- Le 4 Avr 16, à 7:06, Takeback <[email protected]> a écrit :
Hello,
As of my knowledge, SIP applications do not encrypt messages, only voice and
video calls (with DTLS, SRTP or ZRTP) and transit (with TLS). Correct me if I'm
wrong.
According to Ring FAQ it uses TLS/SRTP to secure connection and communications
over the network and implement SRTP over SIP.
As I understand this, Ring is a sort of a "layer" over SIP, does everything
what SIP does and in an exactly the same way, but through a decentralized
network. Does this mean the only encrypted data is voice and video calls and
it's encrypted with TLS/SRTP (or maybe rather DTLS?) and text messages are not
encrypted?
As I understand, the data in transit (connection data exchanged over the
network) is encrypted with RSA. That would mean the messages are encrypted with
this. It seems like a better choice than TLS, just because I don't trust it,
but from the other hand, it would be the only tool that uses RSA to encrypt
messages, while everything else uses OTR, things based on OTR or different
solutions intended to be better and well-suited for this use case. From what
I've read it's similar to PGP, but for some reason PGP is the one that's
considered good, I'll read the wikipedia article about it as I don't know
anything about RSA yet.
Please confirm if I'm correct and I also ask you to clarify the information in
the FAQ, it should be clearly explained how specific things are encrypted. I
find this very confusing as all the SIP applications somehow miss the mention
that text messages aren't encrypted. A non technical user would think
everything is encrypted with this super good cipher ZRTP and would end up using
an unencrypted communication solution... I'm planning to contact Linphone and
Jitsi for this same reason too.
Perhaps you can also explain why RSA and not OTR?
Regards.
_______________________________________________
Ring mailing list
[email protected]
https://lists.savoirfairelinux.net/mailman/listinfo/ring
_______________________________________________
Ring mailing list
[email protected]
https://lists.savoirfairelinux.net/mailman/listinfo/ring
