RE: Encryption padding

These problems will arise any time a small piece of data is encrypted on
its own, and the contents comes from a small set of guessable values with
different lengths.  It's not specific to attribute values.  For example:

    <presidential_vote>
      Al Gore
    </presidential_vote>
vs
    <presidential_vote>
      George Bush
    </presidential_vote>

If you encrypt just element text, this may become something like:

    <presidential_vote>
      OC/BBJqbdvM=
    </presidential_vote>
vs
    <presidential_vote>
      kXq8QIPZcJl7KEIBdj7pYQ==
    </presidential_vote>

The ciphertext length in this case can provide a strong clue as to
the plaintext.

Even if you encrypt the whole element that may not help, as the size
of the element tags will often be fixed and so you could still have
substantially correlation between ciphertext length and plaintext.

The use of padding can alleviate this problem.  Clearly the
encryption transform has to be informed of which nodes to encrypt.
Padding information could be considered a parameter to be included in
this information.  I don't know whether the group would want to create
a specification for how this information is provided to the encryption
transform.

Hal Finney
PGP Security

> From: Thane Plambeck <tplambeck@verisign.com>
> Date: Mon, 13 Nov 2000 10:08:43 -0800
>
> 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

Received on Monday, 13 November 2000 13:32:51 UTC