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
