RE: Initialization Vector

I'm not sure what your question is but maybe my last append
wrt SMIL answers it.  I would only use XML for multimedia the
way SMIL uses it, as a control language; it wouldn't be 
practical to use a non-binary format for something like video.

My comment about doing XML parsing while showing encrypted video
didn't mean the video itself, encrypted or not, was encoded in XML.
I only meant that encryption parameters that would need to be
retrieved might be in XML and that we wouldn't want to require an
app to parse XML before it could re-sync a video clip.

Ed
------------------------------------------------------------------------
--------------
Ed Simon
Software Engineer, Entrust Technologies
email:  ed.simon@entrust.com
ph: (613) 247-2583
------------------------------------------------------------------------
--------------



-----Original Message-----
From: Aram Perez [mailto:aperez@wavesys.com]
Sent: Thursday, September 14, 2000 9:42 AM
To: Ed Simon
Cc: xml-encryption@w3.org
Subject: RE: Initialization Vector




Aram Perez@WAVE_DOMAIN
09/14/2000 09:41 AM
Hi Ed,

Why would you present encrypted video using XML? Why not present it using a
technique similar to what RealAudio or Quicktime use? The initial
information/link is presented using HTML, but then the RealAudio or
Quicktime
takes over the data stream, independent of HTML.

Regards,
Aram Perez





Ed Simon <ed.simon@entrust.com> on 09/14/2000 06:22:46 AM

To:   xml-encryption@w3.org
cc:    (bcc: Aram Perez/WAVE/US)

Subject:  RE: Initialization Vector




My guess is that it might be unacceptable to do XML parsing when
presenting encrypted video.  Any comments on this?  I just can't
see a re-syncing mechanism, which is operating under extreme time
constraints, attempting to parse an XML instance to get the info
it needs.  However, I'm not a video expert so maybe this perception
is wrong.

At the same time, it seems to me that for the large majority of
applications, which wouldn't have these extreme time constraints,
it makes sense to have the IV in XML.

And so,
I'm leaning toward having the IV specified in XML, but OPTIONALLY.
If the IV is not present, it is either not needed or the application
needs to determine the IV for itself.

Phill, do you think this approach would work for encrypted video?
If not, could you present in more detail an example of an encrypted
video scenario we need to handle.

I'm glad Phill brought up the subject of encrypted video.  With the
interest in digital rights, we need to carefully consider how XML
Encryption will work, for example, with SMIL and the media resources.

Ed
-----Original Message-----
From: Takeshi Imamura [mailto:IMAMU@jp.ibm.com]
Sent: Thursday, September 14, 2000 6:36 AM
To: xml-encryption@w3.org
Subject: Re: Initialization Vector





We think an IV may be prefixed to a ciphertext, but the IV and the other
portion
should be structured (i.e., be able to be parsed) and the presence of the IV
should be detectable easily because there are some cases where IVs are not
used.
For example, it is obvious for a case where DES with ECB mode is employed as
an
encryption algorithm.  Also consider a case like SSL where a sender and a
receiver share a secret and can generate IVs from it each other.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Japan, Ltd.
E-mail: imamu@jp.ibm.com



From: Ed Simon <ed.simon@entrust.com> on 2000/09/12 05:02 AM

To:   Public XML Encryption List <xml-encryption@w3.org>
cc:    (bcc: Takeshi Imamura/Japan/IBM)
Subject:  RE: Initialization Vector




I think this will be a hot topic during our next meeting whenever
and wherever that may be.  Personally, I have not come to a conclusion
and would like to hear others' thoughts on this.

Ed

P.S.  I think I will change the name of 'EncryptedNode' to
'EncryptedData' so we don't imply the encrypted thing is
necessarily XML.

-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Monday, September 11, 2000 11:03 AM
To: 'Hiroshi Maruyama'; Ed Simon
Cc: Public XML Encryption List
Subject: RE: Initialization Vector


Managing separate IVs for every encrypted node may get tiresome.

Since every ciphertext stream needs an IV why not simply prefix it to
the ciphertext? That way the temptation to 'reuse' IVs is avoided and
the IV is always in the same place as the ciphertext.

I am thinking of a bunch of 'content management' type possibilities.
Consider the case where we have a detached decryption blob. One blob
might map to a hundred ciphertext streams. If the IV is packaged with
the decryption blob I have to compile the crypto manifest in advance -
bad plan for streaming video. If on the other hand the IV is packaged
with the ciphertext I don't need any additional info.

          Phill

> -----Original Message-----
> From: Hiroshi Maruyama [mailto:MARUYAMA@jp.ibm.com]
> Sent: Sunday, September 10, 2000 9:06 PM
> To: Ed Simon
> Cc: Public XML Encryption List
> Subject: Initialization Vector
>
>
>
>
> Ed,
> I think you are working on the syntax of encrypted contents.
> One thing that I have noticed is that, if we want to separate
> EncryptionInfo and EncryptedNode (whatever name
> we choose :-)) so that the same key can be shared with
> multiple contents, we need to include an initialization vector
> for each EncryptedNode, as in
>
>   <EncryptedNode
>       NodeType="Element"
>       EncryptionInfo="URL to key"
>       IV="Base64-encoded IV">
>
> because otherwise one may know whether two encrypted nodes
> have the same prefix.
>
> Hiroshi
>
> --
> Hiroshi Maruyama
> Manager, Internet Technology, Tokyo Research Laboratory
> +81-46-215-4576
> maruyama@jp.ibm.com
>
>

Received on Thursday, 14 September 2000 12:46:44 UTC