W3C home > Mailing lists > Public > public-xmlsec@w3.org > January 2009

RE: Algorithms draft created

From: Hallam-Baker, Phillip <pbaker@verisign.com>
Date: Wed, 7 Jan 2009 07:39:45 -0800
Message-ID: <2788466ED3E31C418E9ACC5C316615572FFC48@mou1wnexmb09.vcorp.ad.vrsn.com>
To: "Sean Mullan" <Sean.Mullan@Sun.COM>, "Frederick Hirsch" <frederick.hirsch@nokia.com>
Cc: "XMLSec WG Public List" <public-xmlsec@w3.org>, "ext Kelvin Yiu" <kelviny@exchange.microsoft.com>

The section HMAC URIs should be headed MAC URIs and should include identifiers for CMAC-AES modes.

HMAC is a construction for producing a MAC from a digest function. CMAC is a construction for producing a MAC from a block cipher. The fundamental cryptologic unit here is the Message Authentication Code function. We don't break encryption out according to whether it is CBC or EBC or whatever. We should be consistent.


One use for MAC functions that needs to be considered separately (possibly) is the use of a MAC function as a digest function, using a randomly chosen key as an Initialization Vector in the same way that this is done in AES-CBC. The advantage of using this particular construction is that it guarantees security against a chosen source text collision attack, even in the case that the cryptographic primitive is broken.

There are two cases in which this mode is useful. One is in highly constrained devices such as micro-controllers where memory is severely limited (386 bytes) and being able to generate every symmetric cryptographic function (encryption, digest, MAC) from a single function is highly desirable. The second is in cases where you want to have the highest possible assurance that a signature is authentic and you are either unable to wait around for the results of the SHA-2 contest or not necessarily willing to accept the choice.


A third case is when you want to have a compact one way identifier that does not reveal the fact that two referenced objects are identical. With a normal digest, H(x) <> H(y) => x <> y. With a random keyed digest H(x) <> H(y) tells you nothing more.

This struck me as interesting, anyone know of a reference in the literature that should be cited?


-----Original Message-----
From: public-xmlsec-request@w3.org on behalf of Sean Mullan
Sent: Wed 1/7/2009 9:16 AM
To: Frederick Hirsch
Cc: XMLSec WG Public List; ext Kelvin Yiu
Subject: Re: Algorithms draft created
 

Exc. C14n algorithm URIs are missing from section 6.

--Sean

Frederick Hirsch wrote:
> 
> I have created an initial editors draft document for a note listing 
> algorithm URIs and the related specifications.
> 
> http://www.w3.org/2008/xmlsec/Drafts/xmlsec-algorithms/Overview.html
> 
> Kelvin can you please review this document and add additional algorithm 
> information?
> 
> This should complete ACTION-130
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> 
Received on Wednesday, 7 January 2009 15:40:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:43:57 GMT