Re: Algorithm Selections

Simon,

I just realized that you have a Certicom hostname. In no way did I intend to
slam Certicom. I just saw the name and did not bother to read the host name. My
only point was that I have never seen ECC implemented in a large scale
environment. I apologize if my remark came off as flippant or disrespectful.

-Aaron





Simon Blake-Wilson <sblakewilson@certicom.com>@w3.org on 11/28/2000 01:28:00 PM

Sent by:  xml-encryption-request@w3.org

To:   Aaron J Ferguson/US/ABAS/PwC
cc:   jimsch@nwlink.com, "'Xml-Encryption (E-mail)" <xml-encryption@w3.org>,
      Yongge Wang <ywang@certicom.com>
Subject:  Re: Algorithm Selections

1 file attached


Hi Aaron,

Thanks for your comments. I'd certainly push back and claim that ECC has passed
the implementation test.

I think there are a number of offerings out there including ECC ...

- Certicom and others in the commercial arena
- Freeware stuff like Wei Dai's Crypto++

Of course when you implement ECC there are several options to select ... as with
other algorithms like RSA and DH. I think the options issue has been addressed
and continues to be addressed in several ways:

- Commercial products tend to support a wide range of the possible options
- Organizations like NIST and SECG are making recommendations about things like
which parameters to use
- The same organizations are working on validation systems that implementors
will be able to use to check their implementations are correct.

My 2 cents. Thanks again.

Best regards. Simon





aaron.j.ferguson@us.pwcglobal.com on 11/27/2000 04:43:54 PM

To:   Simon Blake-Wilson/Certicom@Certicom
cc:   jimsch@nwlink.com, "'Xml-Encryption (E-mail)" <xml-encryption@w3.org>,
      Yongge Wang/Certicom@Certicom
Subject:  Re: Algorithm Selections






Simon,

Do you know of any vendors that offer a proven implementation of ECC? It seems
that the proverbial jury is still out on ECC implementation (as opposed to the
algorithm itself) as products that do purport to offer ECC functionality vary in
capability.

-Aaron

Regards,

Aaron J. Ferguson, Ph.D.
PricewaterhouseCoopers LLP
1306 Concourse Drive, Suite 100
Linthicum, MD 21090
Voice: 410.412.7993
Fax: 410.412.7997
Email: aaron.j.ferguson@us.pwcglobal.com

ABAS/TRS -- Balancing the need to connect with the need to protect





Simon Blake-Wilson <sblakewilson@certicom.com> on 11/27/2000 03:07:47 PM
To:   jimsch@nwlink.com
cc:   "'Xml-Encryption (E-mail)" <xml-encryption@w3.org>, Yongge Wang
      <ywang@certicom.com>
Subject:  Re: Algorithm Selections

1 file attached




I'd like to suggest including ECC as an option ... either ECDH key agreement or
ECIES key transport. My reasons:

- ECC offers favourable performance compared to RSA in constrained environments
like wireless ... particularly for private key operations like decryption.
- In general it seems sensible to standardize a reasonable selection of
algorithms to mitigate against the potential that some algorithms will be
broken.
- ECC is now fairly widely specified ... for example in IEEE 1363, PKIX, WAP,
etc. Dan Brown and I also have a reasonably stable "ECC in S/MIME" draft.

Of course, there are patent issues with ECC, but I don't think this should be a
reason to exclude optional ECC. Plus I think all the parties involved (certainly
the party I work for) are fairly accustomed to committing to the usual
'reasonable and non-discriminatory' terms that standards bodies' policies
typically request.

Best regards. Simon

S. Blake-Wilson
Certicom Corp.





"Jim Schaad" <jimsch@nwlink.com> on 11/15/2000 03:31:49 AM

Please respond to jimsch@nwlink.com

To:   "'Xml-Encryption \(E-mail\)" <xml-encryption@w3.org>
cc:    (bcc: Simon Blake-Wilson/Certicom)
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.





(See attached file: att1.htm)





----------------------------------------------------------------
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material.  Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited.   If you received this in error, please
contact the sender and delete the material from any computer.






----------------------------------------------------------------
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material.  Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited.   If you received this in error, please
contact the sender and delete the material from any computer.