RE: HW Support and XML Encryption Requirements

>This is a good point, but how would one meet this requirement? I expect
that 
>in addition to providing the IV in the encryption syntax itself it would be

>fed as a parameter to the encryption algorithm?

IVs should not be a parameter passed to an encryption engine.  The
generation of the random IV should be the result of processing by the
encryption engine.  It's not very useful to separate out the IV from the
encrypted data into a "human readable" XML field.  Having the IV as a
parameter complicates hardware implementations of the algorithm and
potentially promote bad implementations of IV generation.

The process of transforming the data should include the generation of the IV
and it's concatenation to the front of the encrypted data. The IV is then an
opaque part of the encrypted data.  Most practical IVs are simply a random
first block of data.

The standards for cryptographic algorithms focus on the mathematics and
modularity of the transforms.  The practical application of encryption
requires the complete definition of the algorithm and can include block
size, rounds, mode (e.g. cbc) and key size.  Block oriented algorithms need
to define formats and procedures for the padding.  In this context, the IV
is not a fixed option selected as part of the transformation.  The IV must
change for every usage of a specific transformation.      

One approach might be to better define the complete algorithm as the
complete suite of processing.  For example:

  <xenc:EncryptionMethod
xenc:Algorithm="urn:nist-gov:tripledes-ede-cbc-IV-pad">

I'd propose that any mandatory to implement algorithms not have any
parameters.  Flexibility could be provided to allow other algorithms with
parameters and even IVs in the XML portion of the syntax.


Paul

-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Wednesday, February 21, 2001 11:25 AM
To: Paul Lambert
Cc: XML Encryption WG
Subject: Re: HW Support and XML Encryption Requirements


At 14:45 2/16/2001 -0800, Paul Lambert wrote:
>4.0 The encryption and XML processing should be
>    - support the use of hardware implementation of the encryption 
> processing

I've added that under the security section.

>Hardware considerations introduce design consideration that impact the 
>sytax.  For example, the current draft proposal places cryptographic 
>initialization information early in the header:
>
><xenc:EncryptedData 
>xmlns:xenc='<http://www.w3.org/2000/11/temp-xmlenc>http://www.w3.org/2000/1
1/temp-xmlenc'> 
>
>   <xenc:EncryptionMethod xenc:Algorithm="urn:nist-gov:tripledes-ede-cbc">
>     <s0:IV xmlns:s0='<http://somens>http://somens'>ABCD</s0:IV>
>     .... etc ....
>
>It is "best" to have hardware directly support the creation of the 
>initialization information required for encryption transforms 
>(IV).  Ideally, the IV should be directly in front of the cipher text to 
>support the tight integration of the generation of the IV with the 
>cryptographic process.

This is a good point, but how would one meet this requirement? I expect that

in addition to providing the IV in the encryption syntax itself it would be 
fed as a parameter to the encryption algorithm?


__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/