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

RE: Encryption padding

From: Smith, Ned <ned.smith@intel.com>
Date: Mon, 13 Nov 2000 10:46:26 -0800
Message-ID: <19BD7227A489D411AC5200902746200B0F8A83@orsmsx55.jf.intel.com>
To: "'hal@finney.org'" <hal@finney.org>, tplambeck@verisign.com, xml-encryption@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One approach could be to hash the contents and return the encrypted
hash value. It will always be the same size. Since the possible
choices are few, the recipient can easily compare hash values from
the set of possible answers.
- -Ned Smith

- -----Original Message-----
From: hal@finney.org [mailto:hal@finney.org]
Sent: Monday, November 13, 2000 10:33 AM
To: hal@finney.org; tplambeck@verisign.com; xml-encryption@w3.org
Subject: 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


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3

iQA/AwUBOhA3yxdTablCCzU/EQJG6QCfW/Emx16HFTrJervceOmTzzn7NS4An3LI
rjenI50+tyUjEyYKR7371XbZ
=V9li
-----END PGP SIGNATURE-----
Received on Monday, 13 November 2000 13:47:53 GMT

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