Patrick wrote:
>
> Hello,
>
> Given a 100 bytes of data being sent over a network, how can I estimate or
> calculate the corresponding number of bytes it would take to send the same
> 100 bytes in encrypted form using NSS?
>
> In order words, how many bytes are sent during:
>
> 1. the SSL handshake (connection setup/overhead)?
>
> 2. the actual data exchange (after the SSL handshake is done)?
Patrick,
Your question seems to really be about SSL rather than NSS. The answers
to your questions would be the same for any SSL implementation.
The answer to the second question is simpler than the answer to the first
question, so I'll answer the second question first.
A2. When sending application data, SSL breaks the application data up
into "fragments" of 16 K bytes (if the application is trying to send
more than 16 K bytes), and then for each fragment, SSL sends an SSL
"record" whose length is as follows:
record header size (always 5 bytes)
+ size of plain text (whatever the application wrote)
+ size of MAC (16 bytes for MD5, or 20 bytes for SHA1)
+ size of padding (stream ciphers: none, block ciphers: up to 8 bytes)
As you can see, there are several variables here, other than the size of
the application's data. The cipher suite uses either MD5 or SHA1, which
affects the size of the MAC. Block ciphers, such as RC2, DES, triple-DES
and rijndael (AES) add 1-8 bytes of padding, so that the total of plain
text size plus MAC size plus padding is a multiple of the block size
(e.g., 8 bytes).
A1. There are two kinds of SSL handshakes, "full" ones that use
certificates and (typically) RSA encrypted values, and "restart"
handshakes that do not, and are much shorter.
A typical restart handshake is 300 to 330 bytes long, total for both sides.
I'll explain more about that below.
Full handshakes can range from about 1k byte up to more than 8k bytes.
There are many variables in the size of the full SSL handshake, such as:
a) Is the handshake a "full" (e.g. RSA) handshake, or a shorter "restart"
handshake that does no public key operations?
b) Does the server request that the client authenticate with a cert?
and if so,
c) how many CAs does the server trust to issue client certificates,
and how long are the names of those CAs?
d) How many certificates are in the chain of certs sent by the server?
e) How big are each of those certificates?
f) How big is the server's public key?
g) How many certificates are in the client's cert chain, if any?
h) How big are each of those certs?
i) How big is the client's public key (if sent)?
j) How many different SSL cipher suites does the client support?
(The client sends the list of them to the server)
k) Does the negotiated cipher suite require the use of a "server key
exchange" message? (e.g. export cipher suite, diffie-hellman
cipher suite, fortezza cipher suite)
l) is the negotiated cipher suite an "export" suite, or a "domestic" suite?
So the question "how big is the full handshake" cannot be answered
without first knowing (or assuming) the answers to the above questions.
Let's look at two example handshakes, a "full" handshake and a "restart"
handshake. For our example, both handshakes will use domestic (128-bit)
RC4 (stream cipher, no padding), and MD5 MACs.
In the full handshake, the client will tell the server that it supports
9 cipher suites. The server will send two certificates to the client,
and will request that the client authenticate with a certificate chain.
The server will send a list of the names of 43 CAs that it trusts to
issue client certs. (Admittedly, trusting 43 CAs is not typical.)
The client will send a chain of two certs back. Both sides' RSA public
keys are 512 bits. This is more-or-less a worst-case example. Typical
full handshakes are shorter than this one.
In the "restart" handshake, no certs are sent by either side, and no
RSA computations are done. It's much shorter.
The entire details of these handshakes (and others) are given in a set
of web pages, intended to help SSL developers understand SSL better.
You can see these handshakes for yourself by visiting:
http://home.netscape.com/eng/ssl3/traces/index.html
Full handshake:
The client's first transmission to the server is 54 bytes, containing
the 9 cipher suites that the client supports.
The server's first reply message is 6260 bytes. Of that space, 1324
bytes are two certificates, 636 and 688 bytes respectively; and 4842
bytes are the list of 43 CA DNs (average 112 bytes each). There is
no server-key-exchange message. In a more typical example, with only
one CA DN for client certs, this message would be only ~ 1530 bytes.
The client's second transmission to the server is 1473 bytes, of which
1323 bytes are two certificates, 635 and 688 bytes respectively;
68 bytes are the encrypted pre-master secret (which would be twice as
big if the server's public key had been 1024 bits); and 70 bytes
contain the client's signature (would be twice as big if the client's
public key had been 1024 bits).
Then both sides send two short transmissions of 66 bytes, and the
full handshake is finished. Each side makes 2 transmissions, for a
total of 4. (The client's 1473 byte and 66 byte transmissions are
sent combined.)
So, the total for this example is 7919 bytes. A more typical example
(RC4. MD5. RSA. 1024-bit keys, no client authentication) would be
around 1750 bytes.
Restart handshake:
The restart handshake has only 3 transmissions, not 4 like the full
handshake, and are much smaller because there are no certificates,
no CA DNs and no public key encrypted values. The numbers below are
typical for all restart handshakes.
The client's first message is 90 bytes, including the session number.
The server's reply is 145 bytes, being 79 bytes to restart the session,
and 66 bytes to finish its side of the handshake.
The client finishes with a 66-byte transmission (same as in full
handshake).
The total for all 3 transmissions is 301 bytes. This is typical for
all restart handshakes. With a block cipher and SHA1 MACs, it would
be 16 more bytes typically.
--
Nelson Bolyard Netscape Communications (subsidiary of AOL)
Disclaimer: I speak for myself, not for Netscape
