RE: Encryption padding

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 Monday, 13 November 2000 13:10:41 UTC