# SSL3 padding algorithm

George Chung (gchung@openhorizon.com)
Mon, 16 Mar 1998 12:47:20 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: David Brownell: "Re: Java SSL / SSLeay interoperability"
- Previous message: Frank Maritato: "Java SSL / SSLeay interoperability"

    From: "George Chung" <gchung@openhorizon.com>

    To: <java-security@javasoft.com>

    Subject: SSL3 padding algorithm

    Date: Mon, 16 Mar 1998 12:47:20 -0800

You may want to consider documenting the SSL3 padding algorithm as a valid
padding scheme (perhaps "SSL3Padding"?). It differs slightly from
PKCS5Padding in the following way...

In The SSL Protocol Version 3.0, November 18, 1996, it states in Section
5.2.3.2 (CBC block cipher) that the GenericBlockCipher structure looks like
the following:

block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;

The size of an instance of a GenericBlockCipher must be a multiple of the
block cipher's block length.

The padding length, which is ALWAYS present, contributes to the padding.
Which implies that if:

sizeof(content) + sizeof(MAC) % block_length = 0, padding has to be
(block_length - 1) bytes long because of the existence of padding_length.

This make the padding scheme similar (but not quite) to PKCS#5 where the
padding length is encoded in the padding (and ranges from 1 to
block_length). With the SSL scheme, the sizeof(padding) is encoded in the
always present padding_length and therefore ranges from 0 to block_length-1.

- Next message: David Brownell: "Re: Java SSL / SSLeay interoperability"
- Previous message: Frank Maritato: "Java SSL / SSLeay interoperability"