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

RE: Encryption padding

From: <hal@finney.org>
Date: Mon, 13 Nov 2000 10:33:13 -0800
Message-Id: <200011131833.KAA06957@finney.org>
To: hal@finney.org, tplambeck@verisign.com, xml-encryption@w3.org
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:

      Al Gore
      George Bush

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


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:00 UTC