Performance Measurement

To see if our design and implementation are practical, we took some measurements on the time to complete crucial group-oriented tasks. We measured response time, that is, the time lapse between when a task is invoked and when it is completed.

The first task is initiating a group or session. This includes initializing group control data structures, reading in from disk an access control file, starting a server listening on a socket, and displaying a control panel.

The second task we measured is joining an existing group. This includes the member requesting joining by sending an encrypted message, and the group leader checking authentication and group admission policy and responding with an encrypted message to distribute a group key. These messages are followed by a state transfer phase, again via an encrypted channel. Note that this measurement obviously depends on the size of the current state, the complexity in checking the group admission policy, network latency, and speed of the crypto software.

Our measurement is done within a lightly loaded local-area network, a speeded-up software implementation of DES, a small ACL file (a dozen or so entries) and a minimal group state. Also note that the time it takes to notify all group members of this new member is not measured, because notification should be done asynchronously and some delay in this step is not crucial in a leader-controlled group.

The third task is leaving a group. In this signing-off process, the group member sends a request message, which is securely encrypted, and the leader verifies authentication and sends an acknowledgment. Note that to completely remove the member from the group, the leader must also clear all state information that depends on the member (such as locks on files) and execute the group-key change protocol. These various activities, however, are not measured since they should be done after the member is acknowledged. Their costs can vary a lot, depending on the size of the group and of its state information.

The measurements are represented in Table 3. It is not surprising that joining a group takes the longest time because it involves more interactions between the group member and the group leader.

  
Table 3: Measured response time of operations in a leader-controlled group (October 1995)

We must emphasize that all execution except encryption is done in a scripting and interpreted language (and in user space). Compiled code should have about 10 times speedup. Also, the prototype paid no special attention to code optimization. Given that these tasks are initiated by human users, who choose menu items, type in data (such as password), and click on buttons, a few seconds latency in each task is insignificant and tolerable. Other tasks, such as introducing a new shared file, updating a file, or posting a group message, take much less time.

We expect that these numbers will be significantly improved in our re-implementation of the Enclaves system, which has already begun. Apart from the obvious code optimization, there are a number of design choices to improve efficiency. One is to precompute a stream cipher using the group key and DES. This would save the time to initialize DES (e.g., the time to load in the key and arrange the key table), which is a very expensive part of encryption. A second method is to arrange session keys (in addition to the group key) between each member and the group leader, and then use these temporary keys in point-to-point encryption. The benefit is that such keys are fresh and can identify the sender. Thus, the message length can be reduced; for example, timestamps and sender-recipient identifications are no longer necessary.

Need help? Use our Contacts page.

Conference Index USENIX home