W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2000

RE: Encryption padding

From: <hal@finney.org>
Date: Wed, 15 Nov 2000 12:23:28 -0800
Message-Id: <200011152023.MAA13193@finney.org>
To: hal@finney.org, steve@myProof.com, tplambeck@verisign.com, xml-encryption@w3.org
Another idea would be to use padding similar to that in PKCS-1 (v 1.5).
Prepend a string of non-zero random bytes (octets), then a zero byte.
This would be followed by the plaintext.

This allows padding of any length, and can be recognized and removed
by searching for a zero.  PKCS-5 padding can only pad up to 256 bytes,
although granted, in most cases that would be plenty.

One question is whether such padding would be part of the encryption,
or perhaps would be a separate transform.  We've talked about possibly
having transforms specified, and this might be a candidate.

CBC encryption mode does require padding up to the block size (8 or 16
bytes) and it seems awkward to have two forms of padding, one to hide
message length and another to round up to the block size.  OTOH if
we are using standard crypto libraries, they might do PKCS-5 padding
automatically (I'm not sure which ones do or don't).

The choices seem to be:

1. Ignore this problem (leakage of plaintext length) and just use PKCS-5
padding for CBC mode.

2. Add some form of length-hiding padding as a separate transform and
continue to use PKCS-5 to pad up to the block size for the CBC mode
encryption.

3. Use this padding in place of PKCS-5 to achieve both length hiding
and block-size rounding.

Hal Finney
PGP Security


> From: Steve Wiley <steve@myProof.com>
>
> Here is a possible padding solution.
>
> 1. Determine the minimum padding length (min-pad-len) to achieve the 
> desired security.
> 2. For each plaintext generate a random pad length that is larger that the 
> min-pad-len.
> 3. For each plaintext generate a pad string of random 
> characters.   Reserving one character
>     to use as a delimiter.
> 4. Append the reserved character to the beginning and the end of the pad 
> string.  I doesn't
>     matter if the delimiter is a member of the original plaintext, it just 
> can't be part of the pad.
> 5. Append the delimited pad to the plaintext.
> 6. Pad every plaintext to be encrypted.  This simplifies the decryption 
> process, adds security,
>     allows an easy way to determine the pad delimiters, allows random pad 
> delimiters.
>
> Example:
> <name>
>    <first>Jane<first>
>    <mid>Ellen<mid>
>    <last>Doe<last>
> </name>
>
>   Pad strings:
>   a03urnguf7e3beiure8eyde3ej3ehda
>   ndkeu375096lrkducn
>   zkdjf7405-t6[y;h/.tjktrur749rtjturir;;re./r,rlgiureyegehrjz
>
> <name>
>    <first>Janea03urnguf7e3beiure8eyde3ej3ehda<first>
>    <mid>Ellenndkeu375096lrkducn<mid>
>    <last>Doezkdjf7405-t6[y;h/.tjktrur749rtjturir;;re./r,rlgiureyegehrjz<last>
> </name>
>
> Then encrypt the plaintext.
>
> The decryption process decrypts the cyphertext, then checks the last character
> of the plaintext.  It then deletes tailing characters until it reads the 
> same character as
> the last character deleting it as well.
>
> The nice thing about this method is that the decryption process doesn't have to
> know the length of the pad or the pad delimiters.  The encryption process gets
> to choose random pad lengths, delimiters and characters.  The only things that
> need to be determined is the minimum and maximum pad lengths.
>
> Steve Wiley <steve@myproof.com>
Received on Wednesday, 15 November 2000 15:22:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:18 GMT