INMUNODIAGNÓSTICO: USO DE KITS COMERCIALES

This section provides a theoretical background for the performance tests de- scribed in section 5.6. The focus is on the AS, although one aspect of client performance, key generation times, will also be discussed. From the system design in section 5.2, one can observe that the AS has two main modes of operation: Initial issuing of certificates using SPEKE, and renewal of cer- tificates using digital signatures for client authentication. Both modes of operation must be tested for performance. In both cases, the dependent (measured) variable is the number of issued client certificates per second, but the independent (manipulated) variables for the two modes of operation are different. The independent variables for each mode of operation are the parameters that have a significant impact on the performance of the system. An in-depth background on performance in cryptographic algorithms will not be presented here, for a more detailed description and analysis see [27]. The general assumption used is that modular exponentiation using a huge mod- ulus is so computationally expensive that it eclipses the performance impact of other parameters. The main focus will therefore be on the most computa- tionally expensive operations, the asymmetric ones. It is assumed that the symmetric operations and hashing have such a small impact that they can be ignored.

When using SPEKE, the client and server each have to perform two mod- ular exponentiations, as explained in section 4.2. The first exponentiation produces the SPEKE public key, while the second produces the shared se- cret key. For DSA signing, the server or client has to perform one modular exponentiation. For DSA signature verification, they have to perform two modular exponentiations, although they can be performed simultaneously,

which results in the performance impact being approximately 1.17 modu- lar exponentiations, see pages 453-454 of [27] for details. For RSA signing and signature verifications, one modular exponentiation is performed. How- ever, a small number is often chosen as the encryption exponent e in RSA, which results in signature verification being a lot faster than signing. As a consequence, e = 216_{+ 1 = 65537 is used as the encryption exponent, as}

recommended on page 291 of [27]. A summary of the performance impacts of the different operations is shown in table 5.5. For the initial authenti-

Mode Number of modular exponentiations

SPEKE 2

DSA signature 1

DSA verification 1.17

RSA signature 1

RSA verification 1

Table 5.5: Theoretical performance comparison

cation using SPEKE, there are three independent variables: The SPEKE modulus, the CA modulus, and the CA signature algorithm. The only effect of changing the client modulus in the initial authentication is to make the PKIMessage a little longer, so this has a minimal impact on performance. This is why the client modulus and signature algorithm are not included as independent variables. For the initial issuing of a certificate, the AS has to perform two modular exponentiations using the SPEKE modulus, and one digital signature using the CA algorithm and modulus.

For renewal of certificates, there are four independent variables: The CA modulus, CA signature algorithm, client modulus and client signature algorithm. SPEKE is not used for renewal of certificates. In this mode of operation, the AS has to check the client’s signature on the new certificate, then check the CA signature on the old certificate, and finally sign the new certificate.

The performance impact of the independent variables for the two different modes of operation are summarized in table 5.6.

Before performing actual tests, it might be enlightening to make a few conjectures about the performance of the various combinations of algorithms presented. First of all, one might assume that the initial issuing of certificates will be faster when using DSA than when using RSA. The argument support- ing this is simply that signing using RSA is more time-consuming than when using DSA. When considering renewal of certificates, the situation is a little

Entity Operation SPEKE CA sign CA verify Client sign Client verify

AS Initial 1 1 0 0 0

Client Initial 1 0 1 0 0

AS Renew 0 1 1 0 1

Client Renew 0 0 1 1 0

Table 5.6: Number of performance critical operations

more complex. One thing that is known is that the AS has to perform two verifications and one signature. Based on the information in table 5.6, the fastest combination of algorithms for renewal would probably be RSA on the client and DSA on the AS. That would result in the AS performing one RSA verification, which is extremely fast, and then one DSA verification and sig- nature. This is at least faster than using DSA on both the client and the AS, and in the last two cases the AS has to sign using RSA, which will probably result in lower performance.

One performance issue that has not yet been discussed is the time used for key generation on the client. For the initial authentication procedure, key generation times of more than a few seconds is probably unacceptable. Users do not wish to have to wait for a long time after entering their password before they are allowed to access the system. Based on conventional knowledge, DSA parameter generation is quite slow. Because of this, the parameters p, q and g used for DSA are often generated when the software is installed, rather than at login time. The key generation itself, when the parameters are available, is very fast when using DSA. With RSA, on the other hand, it is not possible to pre-compute key generation parameters, so key generation will be slower. Two questions that need to be answered through experiments is therefore: Is generation of RSA keys at login time a viable approach? And is the generation of DSA parameters fast enough to be used on-the-fly?