W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2000

RE: Algorithm Selections

From: Jim Schaad <jimsch@nwlink.com>
Date: Wed, 15 Nov 2000 13:49:37 -0800
To: "'Ed Simon'" <ed.simon@entrust.com>, "'Xml-Encryption \(E-mail\)" <xml-encryption@w3.org>
Message-ID: <280C17FB2FDDFF4C8ACBF27D4B2CD417F366@genesis.soaringhawk.net>
Ed,

Is the ability to do streaming media a requirement for this specification?
It is my impression that the security on streaming ciphers is less that that
of block ciphers and streaming can be done by block ciphers with some
tricks.

jim

-----Original Message-----
From: xml-encryption-request@w3.org [mailto:xml-encryption-request@w3.org]On
Behalf Of Ed Simon
Posted At: Wednesday, November 15, 2000 12:40 PM
Posted To: XML-Encryption
Conversation: Algorithm Selections
Subject: RE: Algorithm Selections


If XML Encryption is to be used for streaming media, as discussed in my
presentation at the work shop, then we will also need streaming ciphers.

Ed

-----Original Message-----
From: Jim Schaad [mailto:jimsch@nwlink.com]
Sent: Wednesday, November 15, 2000 3:32 AM
To: 'Xml-Encryption (E-mail)
Subject: Algorithm Selections



As promised at the XML Encryption workshop, here is a description of the
different types of algorithms along with what I would recommend for the
different levels of support.  Let the discussion begin:


Stream Encryption Algorithms:

The most common stream encryption algorithm currently in use is RC4.  I do
not see any reason to include a Stream Encryption algorithm in the suite of
algorithms included in the document.  Most encryption that is used for store
and forward operations is block encryption.

Recomendation: No Stream Encryption Algorithms are selected for the
document.

Block Encryption Algorithms:

TripleDES - This is the current U.S. government standard algorithm.  In
almost all instances the algorithm is run using 3 DES keys used in EDE
(encryption, decryption, encryption) sequence.  Unless you are only
encrypting one block of data it almost always uses CBC chaining mode with
PKCS#5 padding.

AES - This is the proposed U.S. government standard algorithm based on the
Rijndael submission.  Used as the AES algorithm it is fixed to a 128-bit
block size but still uses 128, 192 and 256-bit keys.  As with TripleDES the
most common mode is CBC chaining with PKCS#5 padding.

Recomendation:  AES is MUST in the same key lengths as CMS adopts.  AES in
other key lengths and TripleDES are MAY.

Chaining Modes

CBC (Cipher block chaining) has the property that all subsequent blocks are
dependent on all previous blocks.  This is currently the version of chaining
used in all CMS algorithms.  It requires that a padding algorithm be used
(ususually PKCS#5) unless plain text is known to always occur in multiples
of the block size.

CTS (Cipher Text Stealing) has the property that the cipher text and plain
text are always the same length.  Based on the main from Hal Finney this may
not be a desireable attribute for XML encryption.

Recomendation: Block encryption should be done using CBC and PKCS#5 padding.

Key Transport Algorithms:

RSA-v1.5 - This is the standard RSA algorithm used in CMS today.  It has the
benifit of being widely used and the downside that there is a known attack
againist it.

RSA-OEAP - This is the revised RSA algorithm for doing key transport.  The
same RSA public/private key pair can be used for both RSA-v1.5 and RSA-OEAP
so there is no need to choose just one of these variants.

Recommendation:  RSA-OEAP should be used with AES.  RSA-v1.5 should be used
with TripleDES.

Key Agreement Algorithms:

Key agreement algorithms consist of two different parts that need to be
specified.  The first is how the shared secret value is compuated and the
second is how that shared secret is converted into a key.

Diffie-Hellman is the CMS defined key agreement algorithm.  It should be
noted that several patent claims have been made againist improvements on the
base DH algorithm to prevent some known attacks.  (The IETF S/MIME working
group has put out an informational document on these attacks.)  There is no
need to differenentate between the Ephemeral-Static and Static-Static
variants in the XML Encryption standard  as the same syntax and processing
can be used for both variants. (All that differs is how the Originator
KeyInfo is specified.)

The S/MIME working group has defined a method of getting a TripleDES key
from DH key agreement, however the same has not been defined for AES.

Recommendation:  Unless there is a strong reason for putting in a Key
Agreement algorithm, no key agreement algorithm should be proposed.

Symmetric Key Wrap Algorithms:

The S/MIME working group has two different key wrap algorithms specified.

CMS-KeyWrap is used for wrapping Triple-DES and RC2 keys.  The algorithm is
simple and has been implemented by several different groups of people.  This
is the algorithm that is used for S/MIME ES-DH key agreement key wraping.

S/MIME-Password is an alternate that has been proposed for use when
encrypting a Triple-DES or RC2 key when the wrapping key is derived from a
password.  There is currently no consensus in the working group that this
should be come a standard wrapping algorithm.

AES key wrap has been requested from the NSA by the S/MIME working group.
It is currently expected that we will recieve this by March 2001.  In the
event that we don't get one in the working group we would most likely adapt
the CMS-KeyWrap algorithm for AES purposes.

Recommondation.:  Make the AES keywrap from the NSA be the manditory when it
appears.

Password Derivation Algorithms:

There are several different password to key derivation algorithms available
for use.  If a password key derivation algorithm is to be used, I would
expect it to be placed in the KeyInfo as a new Key Identifier rather than as
an EncryptionMethod algorithm.

Recommondation:  Don't make any password derivation algorithms standard.

Other Algorithms:

Message Authentication - There was a desire at one point to do message
authentication as part of encryption.  However it can easily be done as part
of the digital signature standard so one just needs to encrypt and sign the
object with a MAC.

Compression - The Workshop took a straw poll and determined that compression
would not be part of the XML Encryption standard.
Received on Wednesday, 15 November 2000 17:01:08 GMT

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