RE: Early Draft Algorithms Section

%% See comments at %%.

-----Original Message-----
From: Joseph Ashwood [mailto:jashwood@arcot.com]
Sent: Monday, May 14, 2001 6:47 PM
To: Eastlake III Donald-LDE008; xml-encryption@w3.org
Subject: Re: Early Draft Algorithms Section

I did not intend any post of mine to be a personal attack. I appologize if
it is interpretted that way.

%% OK then, but perhaps you should consider that when I write something
%% (and I think I'm following the working group consensus) that is "sheer
%% folly" or that I have "completely missed" something, it is conceivable
%% that there is a reason favoring that design decision or making that
%% omission, not that I am denying that you might spot some error or point
%% out some consideration that has been missed.

----- Original Message -----
From: "Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com>
> ## Hi, See comments preceded by ##

> ## I don't think we need a stream cipher just to have a stream cipher
> ## but if you would like to propose some particular one and its level
> ## of implementation (mandatory, recommended, or optional), the group
> ## could discuss it.

Well there are some desirable properties to stream ciphers under some
circumstances. (please note I will only be talking about common stream
ciphers, so I will drop the use of the word common) Normally this is reduced

%% What's the difference between a common and an uncommon stream cipher?

to speed, but stream ciphers also give us the ability to precompute the
stream, and in some cases proofs of security (e.g. BBS). Sometimes these
will outweight any contribution that could be supplied by the known block
ciphers. To this end I propose the addition of 4 algorithms that fall into
the category of stream ciphers:
OTP with XOR as a combiner (required)
ARCFOUR/ARC4/RC4 with XOR as a combiner (recommended)
BBS with XOR as a combiner (optional)
ISAAC with XOR as a combiner (optional)

%% What is the licensing status of RC4? I think we would like to avoid
%% encumbered technology.

The logic behind requiring OTP is that each of the others can be reduced to
it with some extra prework. In particular by precomputing the stream, and
treating it as a OTP. The others being optional stems from this, and that it
remains very easy to seperate the stream generator from the
encryption/decryption process. Because of notation issues with OTP, I would
certainly consider it acceptable to drop it, and not require any stream
cipher.

%% I must admit I had never considered one time pads (which I assume is what
%% your mean by OTP) as an algorithm.  I suppose the only type of key info
%% that would be applicable is KeyName which would name the pad. But the
%% enormous logistical problems of one time pads make them impractical for
%% Internet use so I really see no point in specifying this.  If the "pad"
%% is really generated by an algorithm, it isn't a one time pad and calling
%% it that, as many snake oil vendors do, just creates confusion.  OTP seems
%% inappropriate and I would oppose including it.

%% It is my impression that RC4 is fast and BBS (by which I assume you mean
%% Blum Blum Shub) has interesting provable security properties.  Is ISAAC
%% really enough different from RC4 to bother including?

%% In any case, while this is something for the working group to decide,
%% I don't know that adding any stream ciphers is actually worth the effort
%% and specification bulk...

> ## Some people like orthogonally specifying the different sub-algorithms
> ## that go together to make up a suite and some think that opens holes
> ## and gives opportunities for improper use.  In XML DSIG, we ended up
> ## with a consensus for unified algorithm URIs, which bundled
> ## together the hash, padding, and public key algorithm in a single
> ## signature algorithm identifier.

With the large selection of ciphers that is available, I don't think having
a unified list is appropriate. Just as a beginning Crypto++ has 39 symmetric
key algorihms, most of which will almost certainly be used with XML Enc in
some form. There are also 14 hash functions. Using a unified selection gives
546 (39*14) entries just in the selection process, without even counting the
unkeyed MAC functions. Going with a 2 phase setup, one for authenticator,
one for encryptor results in 53 entries (again without MAC functions), a
savings of over 90% in space.

%% Well, if you look in Schneier's book I'm sure you can find hundreds of
%% algorithms, but so what?  The specification is extensible so that people
%% who want to use rare, proprietary, or bizarre algorithms certainly can.
%% And that may be appropriate for some organizations that are
%% operating in a closed environment.  I consider a primary goal to be
%% interoperability so you really want to encourage a minimal diversity of
%% algorithms. If the parties can negotiate, then a profusion of algorithms
%% just encourages breaks by negotiation to the least secure.  If the parties
%% can't negotiate, then a profusion of algorithms either breaks
%% interoperability or puts an enormous burden, especially on low end limited
%% memory and processing devices, to implement all these algorithms.  I, for
%% one, just do not believe there is any good reason to provide for 39
%% symmetric algorithms.  2 or 3 well chosen strong algorithms are a much
%% better idea from the viewpoint of the goals of interoperability and
%% widespread implementation, including lower end devices.

%% But I guess the above does not really speak directly to the question of
%% orthogonality. We could go that way.  The integrity hash algorithm
%% specification could be moved out as per correspondence with Amir.  For
%% the Key Transport and Symmetric Key Wrap algorithms, the type of key
%% wrapped or transported could be specified by the Type attribute of the
%% EncryptedKey element, etc.  Hopefully others on the WG will indicate
%% some preference on this.

> ## I'd be happy to specify SHA-256 as the optional integrity hash function
> ## for 3DES if people want that.  I suppose it should be about 224 bits of
> ## strong hash, more than SHA-1 and less than SHA-256.

Actually 3DES only offers 2^90 work making it fit with a 180-bit hash.

> ## But in XMLDSIG
> ## there was a lot of fulminating against providing a truncation option for
> ## SHA-256.

I agree with that, there's no reason to do work, and then discard it.

> ## The XML Encryption Algorithms section was meant to specify only
> ## AES-128 and so it does, I believe, match SHA-256.

The problem is that AES is to be specified as requiring the implementation
of 192 and 256-bit versions. By specifying only the 128-bit version we
precisely and completely break the specification.

%% I do not agree that incorporating a subset of another specification by
%% reference constitutes any kind of "break"ing of that other specification
%% let alone "precisely and completely break"ing it.  After all, it's not
%% like I said you had to send the plain text along with the ciphertext or
%% include the key in plaintext, which would break it.

> ## If people would like me to add AES-196
> ## & 256, I'm certainly willing to do so, with appropriately sized optional
> ## hashes for integrity, which is why I made this a parenthetical question
> ## in the draft.

I'd skip the SHA-384 usage for the same reason that I wouldn't want SHA-256
truncated to 224 bits. SHA-384 is SHA-512 with the last bits removed. In

%% I'm aware of that and actually agree with you here but only because we
%% are operating in the verbose XML environment.  There are other environments
%% in which every bit counts and it makes perfect sense to truncate hash
%% values down to just the strength you need.

spite of this I would very much support the addition of 192 and 256-bit
Rijndael (soon to be called AES) to the standard. I would also support the
addition of Serpent, Twofish, MARS, RC6, RC5, SKIPJACK and several others as
optional (I'd actually rather see Twofish and Serpent as recommended)

%% See discussion above.  Adding the longer AES key lengths if probably the
%% thing to do.  However, I do not believe there is cause to add any additional
%% mandatory or recommended block ciphers and while I suppose adding one or two
%% optional ones wouldn't hurt that much, I just don't see any reason to stuff
%% in every prominent block cipher.  See comments above re stream ciphers.

> ## You don't seem to like most of the SHA hashes, but frankly I don't think
> ## you are going to get anywhere on changing to something else unless you
> ## propose specific alternatives.

I'd suggest Panama, Tiger, RIPEMD, HAVAL instead. It's not that I don't like
them, it's that reliance on algorithms that have been submitted for public
review before being standardized is not the most reasonable thing to do. The
extended SHA series is relatively new, and relatively unstudied so it should
not be trusted for anything critical, by binding encryption algorithms to
hash functions we restrict ourselves even further in this direction.

%% Well, all you said before was that you thought they were too slow.  Now
%% you also say they are too green... I don't want to see five hash algorithms
%% specified.  Personally I feel confident that the SHA series represents
%% an honest and successful effort by NSA and the US government to produce
%% secure hash functions.  Others may differ.  If one new hash algorithm
%% were to be added, which one would you suggest?

> ## Triple DES, which I refer to as 3DES and FIPS 46-3 refers to as TDES,
> ## is specified by ANSI X9.52.  The FIPS document just references the ANSI
> ## specification.

Regardless the FIPS is the authoritative document. The DES name (and all
derivitives) is the property of the US Government, and they have documents
specifying them, as such those are the authoritative documents. Their
decision to reference an external document does not remove the
authoritativeness of the FIPS.

%% I do not think we will agree here.  It wouldn't matter to me if the FIPS
%% document had the seal of every member of the United Nations and the
%% blessings of the Pope.  You can't implement 3DES from the FIPS.  Sending
%% someone to the FIPS just causes them to read a pointer which sends them to
%% the ANSI document.  Therefore, the ANSI document is the specification
%% and, to my mind, that's all there is to it.
%% However, this document is not mine but the working group's and if there is
%% consensus to change the wording, I'll write it that way.  Perhaps the
%% best compromise would be to reference both the ANSI and FIPS documents.

> ## On searching FIPS 46-3
> ## I am unable to find a reference to EDE or EEE.

EEE refers to the model of Encrypt, Encrypt, Encrypt. EDE is Encrypt,
Decrypt, Encrypt. The primary mode is EDE, and apparently (I just downloaded
a new copy since mine was a prepress) the fips standard only specifies EDE
mode, and only with 3 keys.

%% Precisely.  Exactly this one well defined mode and chaining is intended
%% to be specified and embodied in the algorithm identifier given.

> The Diffie-Hellman specification needs to be completed, but it cannot
> ## The intent is to specify an algorithm similar to that in RFC 2631.

I'd personally rather see it parameterized by the distillation function to
be appplied afterward (this will commonly be a hash function), and to make
it's implementation with SHA-1 and SHA-256 required.

%% The question of parameterization is as I have commented above and needs,
%% in my opinion, more feedback from WG members to determine a consensus.
%% In this case, parameterization would probably have to be via child
%% parameter element(s) of the algorithm role element.

%% The consensus of the WG has been that DH key agreement should be
%% optional. To make it Recommended or Mandatory would, I think, require
%% evidence of a new consensus.

> CMS Key Checksum. Quite frankly this should never have been designed. It is
> horrendous in design, making use of the worst features of SHA-1, and
> continuing to eliminate the best features. Since we are not overly concerned
> about space, remove this and use SHA-1.
>
> ## I'm certainly willing to change this stuff if the consensus of the
> ## working group is to do so.  But it is my impression that the WG,
> ## in many cases, wants to do THE SAME CRYPTO people are currently
> ## do for S/MIME which is based on CMS (RFC 2630 and replacement drafts
> ## in progress).
[snip my comment about CMS ...]
> ## See above comment re using CMS/S/MIME crypto.

I'd rather see something secure. The crypto people didn't do CMS, it was
published without our input, and suffers several rather severe flaws, many
of which have been ignored to this day. I'd personally rather see this group
come up with something secure from the beginning.

%% I'm not sure that everyone involved in S/MIME and CMS would agree that
%% with your assessment that they are not crypto people.  A lot of their
%% stuff (which, by the way, I was not involved with designing) looks
%% pretty kludgy, but I would not asses it, as you apparently do, as being
%% insecure.

> ## Well, perhaps your arguments will persuade people to change and
> ## perhaps not.  The lack of choice of chaining modes is quite
> ## deliberate, with the intent in the current draft of restricting
> ## to only one.

Restricting the chaining modes is pure folly. While CBC is the chain du
jour, it has significant problems. There needs to be different options. For
example IBM has two proposals to the AES modes operation that offer almost
free authentication, and strong chaining. PCBC offers advantages over CBC in
every category except speed. I have personally chosen ECB for some things
because it would be the strongest mode (the data was already inherently
random so any other chaining mode could only have induced problems). Counter
mode is almost guarenteed to be the most desired mode for AES. Feedback
modes offer vast lists of advantages in certain environments. The list goes
on for a long time, CBC is not the end all, and neither is any other
chaining mode.

%% Adding chaining modes is like adding algorithms... it either breaks
%% interoperability or bulks up implementations everywhere.  (I'm personally
%% not very concerned with the closed system case.)  I don't know what
%% the licensing situation is with the IBM modes or how their authentication
%% function would be integrated with XML Encryption and/or XMLDSIG.  In
%% cases where ECB would work because the data is random, I am unaware of any
%% insecurity that CBC would cause.  You can certainly point to advantages of
%% each of many chaining modes but each addition to the specification has
%% inherently a cost in implementation, complexity, etc., associated with it.

%% Thanks, Donald

Received on Tuesday, 15 May 2001 12:43:08 UTC