W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

Re: Proposal for XML Encryption Syntax and Processing

From: <hal@finney.org>
Date: Mon, 8 Jan 2001 16:11:59 -0800
Message-Id: <200101090011.QAA11029@finney.org>
To: jashwood@arcot.com, xml-encryption@w3.org
Joseph Ashwood, <jashwood@arcot.com>, writes:
> The problem lies in a slightly different direction. The problem is that the
> encrypted values are the same for the same input, the cause is simple, the
> encryption function is deterministic. For systems with some amount of
> entropy this is not a severe issue, however as the entropy tends to 0 the
> determinism of the function becomes an issue. The obvious solution to me is
> to use non-deterministic cryptography. The two most prominent examples are
> ElGamal and RSA-OAEP, but there are plenty of others.

These are normally impractical to use to encrypt the raw data of the message,
and they can still leak length information if used in that mode.

> A simple way to add
> the non-determinism to the system where it is needed is to instead of
> encrypting just the data using the chainging mode, prepend a random value of
> known length. This will add some amount of entropy to the system, which will
> have the desired result, assuming a good chaining method. This is in all
> honesty the same technique that is applied to password encryption, a salt.

All decent encryption chaining modes already do this, in the form of
a random Initial Vector (IV) which guarantees that encrypting the same
plaintext leads to different ciphertexts.

The issue we have been discussing here is the leakage of (approximate)
message length, rather than message content per se.  Most ciphers do
little to conceal this.  And in some contexts, knowing the message length
will reveal a great deal about the plaintext.  This is especially true
of cases where the plaintext may be one of only a relatively small number
of possible values, and the possible values differ greatly in length.

The problem can be solved by allowing for a padding transform either
applied before encrypting or as part of the encryption.  This must be
a reversible transform which can be removed upon decryption.

Hal Finney
Received on Monday, 8 January 2001 19:12:46 GMT

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