Re: [office] Fwd: OASIS and encryption

[Michael Brauer <michael.brauer@sun.com>]

Hi Lars,

Lars Oppermann wrote:
> Hi,
> 
> 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?

My opinion is that we should specify HMAC-SHA-1 as a MUST. This has two 
reasons:

1. If we allow specifying different algorithms and someone makes use of 
this, all others would have to support this algorithm as well, or they 
will not be able to read some encrypted documents. This differs from 
all/most other features in our specification, where not supporting a 
certain feature only has the consequence that this feature itself is lost.
2. We have security features on our list of topics we want to discuss in 
a later phase. It seems to me that flexibility regarding the encryption 
algorithms that can be used matches very well into that topic.

However, that's my personal opinion only.

Michael