OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [office] Fwd: OASIS and encryption


Michael Brauer wrote:
> [...]
> The PBKDF2 pseudo-random function is indeed HMAC-SHA-1, as defined in 
> the PKCS#5 v2.0 document in appendices A.2 and B.1.1:
> [...]
> If it helps, we of course might add a sentence to chapter 16.3 
> clarifying that actually HMAC-SHA-1 is used within PBKDF2.

After reviewing PKCS#5 I am of the opinion that we should do something 
in order to better define the key dervation process. If some 
implementation would for some reason choose an other PRNG function for 
salt creation, documents encrypted by that implementation could not be 
decrypted by an implementation using the now standard HMAC function.

I see two possibilities: we might either want to specify HMAC as a MUST 
in the specification, or we might include a new property that holds a 
name identfying the method used to generate the salt in the manifest.
Since crypto related algorithms are sometimes obsoleted because of 
discovered weaknesses (MD5 or SHA-0 in recent times), specifying the 
encryption and key dervation mechanism in the manifest might be the way 
to go.

What are your opinions on this?


Lars Oppermann <lars.oppermann@sun.com>               Sun Microsystems
Software Engineer - StarOffice                           Sachsenfeld 4
Phone: +49 40 23646 959                                D-20097 Hamburg
Fax:   +49 40 23646 550                  http://www.sun.com/staroffice

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]