Performance

 

For each outgoing packet, the sender only needs to compute one HMAC function per packet per authentication chain, since the key chain can be pre-computed. Table 1 shows the performance of the MD5, and HMAC-MD5 functions provided by Cryptix [10] running on a 550 MHz Pentium III Linux PC. The Java code was executed by the JIT compiler which comes with the JDK 1.1.8 provided by IBM [17].

 

$.8$

Table 1: Performance of primitives of the Cryptix native Java library. The performance is displayed in the number of operations per second. 

We analyze the performance of our stream authentication scheme by measuring the number of packets per second that a sender can create. Table 2 shows the packet rates for different packet sizes and different numbers of authentication chains. We suspect that an optimized C implementation might be at least twice as fast.

The communication overhead of our prototype is 24 bytes per authentication chain. Since we use 80 bit HMAC-MD5, both the disclosed key and the MAC are 10 bytes long. The remaining four bytes are used to send the interval index.

 

$.8$

Table 2: Performance of our packet authentication scheme for a varying number of authentication chains. All performance numbers are in packets per second. 

Also, the overhead of pre-computing the key chain is minimal. In our experiments we use an interval length of $1/10$th of a second. To pre-compute a key chain long enough to authenticate packets for one hour, the sender pre-computation time is only $36000/74626\; \approx 0.5$ seconds.

The computational overhead on the receiver side is the same as on the sender side, except that the receiver needs to recompute the key chain while the sender can pre-compute it. However, the overhead of computing the key chain is negligible, since it involves computing one HMAC functions in each time interval, and in practice only tens of intervals are used per second.