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

Re: Proposal for XML Encryption Syntax and Processing

From: Joseph Ashwood <jashwood@arcot.com>
Date: Tue, 9 Jan 2001 11:27:13 -0800
Message-ID: <008101c07a76$2f3d73e0$2a0210ac@livermore>
To: <xml-encryption@w3.org>

----- Original Message -----
From: <hal@finney.org>
> Joseph Ashwood, <jashwood@arcot.com>, writes, regarding padding:
> > What I would suggest [snip segment size]
> 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.

I agree that we should distinguish them, that was the exact point of
providing that the segmenting length was optional, if it is not present it
is obviously not necessary.

>
> > 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.

It was done here for an equally reasonable purpose. Padding with a 0 byte,
followed by random bytes fails under many circumstances, and avoiding those
circumstances only weakens the encryption that will be used in the future
(mathematical proof available upon request). The reason for using the
128-bits of length was very simply there so that it is possible to remove
the padding, 128-bits was chosen because 64-bits is becoming close to
possible. There are solutions that cover less average area, but they require
more compute time to deal with.

>
> > 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.

Then don't use the possibility of it. Just because my car has a cigarette
lighter doesn't mean I have to smoke, likewise I'm not going to get rid of a
perfectly good car, just because it has a cigarette lighter.

>
> > 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.

I want an AONT because it offers a provable level of security, it is proven
(by definition) that an AONT prevents anything about the plaintext from
being known until the entire data is known. At any rate, if we trusted our
secure cipher to do it's job we wouldn't use chaining modes. And at what
point did I even hint that a weak cipher should be used? Also you seem to
have missed another very critical word in the meaning of what I said,
"allow" in other words, just like the segment length padding, when it should
be an optional component.

>
> > 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.

This is the very thing we should worry about. This view has time and again
proven folly for individuals, groups, and even countries, never trust your
cipher absolutely. The most recognised case where those using it believed
the cipher was so unbreakable they ignored it's breaking was the Enigma
during WWII, it cost Germany all of Europe. There are times to compromise on
options, and there are times not to, when adding an inexpensive option to a
potential spec, which people may choose whether or not to support is not the
time.

You also seem to be under the impression that everyone should use strong
crypto. I am a cryptanalyst, I have dealt with hundreds of algorithms,
created by hundreds of different minds, I have designed several dozens
protocols in use in various places, and I'm telling you that strong crypto
is rarely the real solution. I have in the last month recommended using
(single)DES on 2 occassions simply because it was the best for the job at
hand, and offered security that was in excess of the requirements.
Q:Why do I sometimes recommend other than the most secure algorithm?
A:For the same reason that not everyone buys a Rolls-Royce, in many
circumstances it's just too expensive for the job at hand. Sometimes using
the strong crypto creates risks of it's own (continuing the car analogy, I'm
much more likely to get carjacked in a Rolls-Royce than a Toyota Starlet).

The considerations almost always go far beyond simply which will take the
most effort to break, into which one if fast enough, how large is the
information (if the information is 64-bits, Rijndael actually becomes weak
unless you add random padding), is hardware needed (there is little hardware
available for Rijndael), how tested does the hardware have to be (The
hardware that is available is brand new), how secret does this cipher have
to be (the hardware for Rijndael can be easily tracked), what's the main
players favorite cipher (if he/she prefers 3DES to Rijndael, 3DES gets it),
what's the main player's wife's favorite color (named a custom altered
cipher after the color to get faster acceptance). The considerations on
choosing a cipher or a stack of components is not as simple as picking the
Rijndael, it can be as complicated as choosing 3DES with redone s-boxes
designed to confound attempts to retrieve the sboxes (been there done this
one several times). XML Encryption needs to be able to handle these and many
other issues.
                                Joe
Received on Tuesday, 9 January 2001 14:56:41 GMT

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