3 ms·

> The ZRTP encryption mechanism is no longer supported (please use TLS+SRTP) I thought SRTP used certificates rather than the diffie-hellman handshake used by

> The ZRTP encryption mechanism is no longer supported (please use TLS+SRTP) I thought SRTP used certificates rather than the diffie-hellman handshake used by ZRTP -or to put it another way, doesn't this destroy forward secrecy?

Elv13 11y ago
ZRTP may be back at some point. We had to disable it because of dependency issues (we switched to LibAV from CCRTP due to a long string of stability problems and constant regressions, not what you want for a network facing library). While you are right that this open the door to MiM attacks, this can be mitigated by certificate pinning and should be mostly fixed once we switch to a closed network (see some comments below). As it is implemented now, it all depend on how you transmit the Ring hash. This hash is the public key id, so if, for example, you double click on a Google contact with a Ring "phone number", the problem doesn't exist. So, all in all, a mix of trusted hash distribution, certificate pining and chain of trust should eliminate the problem from all angles. Again, this is work in progress (remember, this is an alpha) and ZRTP may come back if we get the resources/contribution to implement it in LibAV.
- BuildTheRobots 11y ago
  Thank you for the detailed reply. Can I confirm that without ZRTP, or rather, with the current implementation, there's no forward secrecy; so should the keys get compromised either through technological or legal attack, all bets are off?
  - Elv13 11y ago
    Well, if you lose your private key and it get into their hand, as of now, yes, you can be impersonalized. As for perfect forward secrecy, it will be enabled sooner or later. We currently don't handle the case where your computer itself get compromised and the disk content is made available. Those scenario should be handled by encrypting your devices and sandboxing network facing applications. In Linux, we also use DBus as the main IPC between the client and the daemon. Anyone with root access could theoretically mess with it and do a local MiM attack. There is little any application can do about this kind of compromission so it is kind of pointless to try to tackle them. At best it would slow such an attack, at worst give a false sense of security.

Elv13 11y ago

ZRTP may be back at some point. We had to disable it because of dependency issues (we switched to LibAV from CCRTP due to a long string of stability problems and constant regressions, not what you want for a network facing library). While you are right that this open the door to MiM attacks, this can be mitigated by certificate pinning and should be mostly fixed once we switch to a closed network (see some comments below). As it is implemented now, it all depend on how you transmit the Ring hash. This hash is the public key id, so if, for example, you double click on a Google contact with a Ring "phone number", the problem doesn't exist. So, all in all, a mix of trusted hash distribution, certificate pining and chain of trust should eliminate the problem from all angles. Again, this is work in progress (remember, this is an alpha) and ZRTP may come back if we get the resources/contribution to implement it in LibAV.

BuildTheRobots 11y ago
Thank you for the detailed reply. Can I confirm that without ZRTP, or rather, with the current implementation, there's no forward secrecy; so should the keys get compromised either through technological or legal attack, all bets are off?
- Elv13 11y ago
  Well, if you lose your private key and it get into their hand, as of now, yes, you can be impersonalized. As for perfect forward secrecy, it will be enabled sooner or later. We currently don't handle the case where your computer itself get compromised and the disk content is made available. Those scenario should be handled by encrypting your devices and sandboxing network facing applications. In Linux, we also use DBus as the main IPC between the client and the daemon. Anyone with root access could theoretically mess with it and do a local MiM attack. There is little any application can do about this kind of compromission so it is kind of pointless to try to tackle them. At best it would slow such an attack, at worst give a false sense of security.