ODF 1.2 Part 1 CD04: More Digest Algorithms are Wasteful and Burdensome

The introduction of table:protection-key-digest-algorithm (19.700) and text:protection-key-digest-algorithm (19.852) opens up the prospect of additional algorithms beside the default SHA1. In fact, SHA256 must be supported by consumers and should be used by producers. The current text also permits SHA512 and RIPEMD-160 by reference to [xmlenc-core]. Additonal algorithms, identified by other URIs, are also allowed.

This is wasted effort. The digest algorithm does not protect the protection, it only protects the key. Furrthermore, having the hash of the key exposed and available, as it is in the table:protection-key and text:protection-key entries makes it easy to discover the key by well-known password attacks. The only safe key to use in setting protection is one that is worthless for any other purpose and for which its discovery is no loss. In general, hashes should not be used to protect secrets where the hash itself is readily obtained and where the secret is of any serious value. The prospect of possible collisions that have the same hash is in fact uninteresting for this use case.

By requiring support for stronger digest algorithms in the specification, there is also an unnecessary burden on implementers, conformance assurance efforts, and just plain code bloat for no useful value.

My preference is that these attributes be removed from the ODF 1.2 specification altogether and that the requirement to use SHA1 be stated as part of the specification for table:protection-key and text:protection-key. That's already more than enough. (XOR folding would probably be sufficient but it is too late for that.).

Acknowledging that the SHA256 recommendation is likely established in implementations, I propose that only SHA1 and SHA256 be permitted, there be no requirement on producers other than they use one, and no other digest algorithms be allowed or expected.