RE: Encryption padding

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: []
Sent: Monday, November 13, 2000 10:33 AM
Subject: RE: Encryption padding

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

      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
a specification for how this information is provided to the

Hal Finney
PGP Security

> From: Thane Plambeck <>
> 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
> 650 429 5247 direct, Mt View Office
> 650 321 4884 home office
> 650 323 4928 home office fax

Version: PGP 6.5.3


Received on Monday, 13 November 2000 13:47:53 UTC