[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ZRTP comments part 2: performance
More comments below.
Thanks,
Alan
EKR wrote:
This message is part 2 of my comments on ZRTP, focusing on
performance.
1. Round-Trip Latency
Figure 1 indicates that ZRTP requires 7 messages (3.5 RTTs) in
the best case (one side is passive) to set up a secure channel:
-> Hello
<- Commit
-> DHPart1
<- DHPart2
-> Confirm1
<- Confirm2
-> Confirm2AK
Based on Figure 1, it appears that if both sides want to be active the
situation is worse.
Most common crypto protocols (SIGMA, DTLS, etc.) do their handshake in
2 RTTs, so 1.5 RTT better. Arguably, you can start sending media after
4 messages (2 RTTs), but that leaves you with only *some* protection
over the handshake parameters in terms of downgrade attack.
I don't understand you. The Confirm messages are about maintaining
cache integrity. The only case where they have any authentication role
is if they are carrying an SAS signature. The real protection in ZRTP
comes from key continuity and the SAS.
2. CPU Consumption
The only DH algorithms supported are 3072 and 4096 which are extremely
slow. Here are timings for DH on my 1.1 GHz laptop using OpenSSL to
do a key generation followed by a DH operation (in milliseconds):
Modulus
3072 4096
+-------------
Key 256 | 120 185
Size 512 | 240 369
As the draft notes, you can improve matters somewhat (~45%) by doing
the key generation in the background, but consider also that many
handsets will be far slower than my laptop.
Given that most current cryptographic systems (e.g., practically
every TLS-based web server) uses 1024 bit keys, one really should specify
a shorter set of groups. I appreciate that 1024-bit RSA doesn't
have a security level comparable to 128-bit AES, let alone 256-bit
AES, but that seems like a decision that people ought to be able to
make for themselves. The standard solution for those who wish to
have much stronger public key key exchange is to use ECC, which is
currently unsupported in ZRTP. Obviously it could be added, but it's
not a total no-brainer how to do so.
We do intend to support ECC in the future. The FIPS requirement is
likely to require us to support shorter key lengths you are suggesting
(very ironic - reducing protocol security in order to comply with a
security recommendation...)
3. Parallel Handshakes
Reading S 5.2, I see:
Because the DH exchange affects the state of the retained shared
secret cache, only one in-process ZRTP DH exchange may occur at a
time between two ZRTP endpoints. Otherwise, race conditions and
cache integrity problems will result. When multiple media streams
are established in parallel between the same pair of ZRTP endpoints
(determined by the ZIDs in the Hello Messages), only one can be
processed. Once that exchange completes with Confirm2 and Conf2ACK
messages, another ZRTP DH exchange can begin. In the event that
Commit messages are sent by both ZRTP endpoints at the same time, but
are received in different media streams, the same resolution rules
apply - the Commit message with the lowest hvi value is discarded and
the other side is the initiator. The media stream in which the
Commit was sent will proceed through the ZRTP exchange while the
media stream with the discarded Commit must wait for the completion
of the other ZRTP exchange.
So, just to clarify, if you want to have totally unrelated keying
material between each stream, you need to serialize the DH
computations? That seems unattractive.
This is true. For cases where this could be a problem (e.g. a large
gateway which might support
hundreds of concurrent calls with another gateway), multiple ZIDs can be
used instead of just one. Note
that with ZRTP, there is no such thing as totally unrelated key material
- the key continuity makes sure
this isn't so to make it more difficult for an attacker.
Also, it is worth noting that even when the Preshared keying mode is
used, there are always different SRTP keys for each media stream. This
is a common feature that I'm not sure DTLS-SRTP supports.
-Ekr