Re: Proposal for XML Encryption Syntax and Processing

Joseph Ashwood, <jashwood@arcot.com>, writes, regarding padding:
> What I would suggest in this
> case though is a variation of block filling. If we add another (optional)
> attribute to the definition of the encrypted node, specifically a segmenting
> length, this can be overcome. In particular this segmenting length would
> consist of a number of bits, the encrypted data would be forced to a
> multiple of the segmenting length through a padding method.

We can distinguish padding techniques which require the receiver to know
the segment size from those which can be removed without this information.
If the latter type is used there is no need to add any attributes to
record the segment length used during encryption, which seems preferable.

> Because we can
> have potentially very large segmenting lengths many of the normal methods
> won't be functional, instead I suggest using the method that has been
> adopted by the hash functions, postpend a 1-bit, followed by enough 0 bits
> to fill all but the last 128-bits of the segment, postpend the length of the
> data in bits, high order bit first.

I don't think you have to go quite this far.  Storing 128 bits of message
length seems excessive.  It's done in hash functions to prevent specific
hash-collision attacks, which are not relevant here.  I'd suggest a simple
padding scheme which can be easily stripped off, like a zero byte and then
a set of nonzero random bytes, or something similar.  This can be as little
as one byte of overhead or as long as necessary.

> If the segmenting length is present
> there must be at least 128-bits added (the initial 1 bit is non-critical).
> Apply your favorite chaining mode and all message now have a length that is
> a multiple of segment length. Removal of the padding is simple, take the
> last 128-bits of the last segment, call the number K. Take the first K bits
> of the decrypted data that is the decrypted value, if there are any
> remaining bits after the removal of the last 128, and the first K, verify
> that the remaining bits are in fact 1 followed by 0s (to detect transmission
> errors).

I don't think that detecting transmission errors should be a goal of
the encryption transform.  That should be handled at other layers of
the message processing.

> To make this more secure, I would suggest allowing an ordering like:
> Padding
> All-Or-Nothing-Transform
> encryption

I can't imagine why you would want an AONT here!  Let's use a secure
cipher and trust it to do its job.  That will be far simpler and
ultimately more secure than using a weak cipher and then tossing in
complications to shield it from nonrandom inputs.

> The presence of the AONT in the middle will make any leakage of the padding
> information through the cipher impossible unless the entire message also
> leaks through the cipher (which would be perfectly equivalent to breaking
> the encryption). For some purposes the AONT phase is far more important than
> the padding portion. Placing the AONT before the Padding supplies potential
> to leak the very information that the padding is present to protect (the
> length of the message), so it is important that the AONT be performed after
> the segment filling padding. Following the AONT there may be padding to fill
> the last block of the cipher, but that is a trivial issue and will leak no
> information about the real length of the document.

The only justification for worrying that the presence of padding will
be leaked is if you don't trust your cipher.  With the strong ciphers
available in the cryptographer's toolkit today, particularly the heavily
analyzed AES contenders, this isn't something we should worry about.

Hal Finney

Received on Monday, 8 January 2001 20:56:29 UTC