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

RE: Encryption padding

From: Steve Wiley <steve@myProof.com>
Date: Wed, 15 Nov 2000 10:56:18 -0800
Message-Id: <4.3.2.7.2.20001115101851.00bae100@myProof.com>
To: Thane Plambeck <tplambeck@verisign.com>, "'hal@finney.org'" <hal@finney.org>, xml-encryption@w3.org
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>




At 10:08 AM 11/13/2000 -0800, Thane Plambeck wrote:
>Does anyone have a requirement for this kind of
>selective encryption of attributes?
>
>We (VeriSign) don't.  It seems to me to add complexity while
>also introducing footholds for cryptanalytic attacks, as alluded to below.
>The encryption padding (ie length) attack is only one example.  Others
>include known
>plaintext attacks and attacks that employ cryptographic depth analysis
>over reused keys.  This last category of attacks goes beyond selective
>attribute encryption though.
>
>XML encryption that takes place selectively
>inside a particular element, with some attributes
>encrypted but where possibly the element content or other
>attributes are in the clear, is going to lead to these types of problems I
>predict.  They're not unsurmountable, but why allow it unless there is
>a requirement?
>
>I would just say don't allow it, unless there is
>some strong requirement for it.
>
>
>
>Thane Plambeck
>tplambeck@verisign.com
>http://www.verisign.com
>650 429 5247 direct, Mt View Office
>650 321 4884 home office
>650 323 4928 home office fax
>
>
>
>-----Original Message-----
>From: hal@finney.org [mailto:hal@finney.org]
>Sent: Thursday, November 09, 2000 6:39 PM
>To: xml-encryption@w3.org
>Subject: Encryption padding
>
>
>Reading the minutes, I thought this comment was important:
>
>     Mike Wray: the more granular you get in encryption, the more
>     vulnerable the information becomes to attack. If you use a cipher over
>     attribute names you could figure out the length of the attribute name.
>
>Most encryption algorithms roughly preserve the length of the plaintext.
>They may pad it up to be a multiple of the the block size, usually 8 or
>16 bytes.  Therefore the length of the plaintext can be inferred from
>the length of the ciphertext, to within 8-16 bytes.
>
>This would be especially dangerous if you were encrypting enumerated
>attributes.  If they happened to have very different lengths then the
>leakage based on plaintext length could completely defeat the encryption.
>
>The same thing could happen to a lesser extent with encrypting the PCDATA
>but leaving the tags clear.  You might have a lot of short buffers to
>encrypt, leaking information about the plaintext length.
>
>Generally the solution needs to be some padding mechanism.  You pad
>the plaintext up to some maximum length before encrypting, so that
>all plausible plaintexts get encrypted to the same-length ciphertext.
>Then the padding is stripped off upon decryption.
>
>The problem is that the information needed to know how much to pad will
>generally not be locally available.  It will depend on the application.
>Maybe in some cases like the enumerated attributes it could be calculated
>in principle if the input to the encryptor included them, but this will
>not work in general.
>
>Would we consider requiring (or at least allowing) the input to be
>prepared by adding attributes to indicate field length?  Users who
>anticipated using XML encryption would include attributes (in an xmlenc
>namespace) that told how much the maximum length would be for following
>character data.  These lengths would then guide the XML encryption
>processor in adding necessary padding.
>
>This is less of a concern if you are encrypting relatively large blocks,
>such as entire elements with children, text, etc.  It is mostly an
>issue if you want to leave tags in the clear but encrypt the character
>data fields.
>
>Hal Finney
>PGP Security
Received on Wednesday, 15 November 2000 13:59:57 GMT

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