Section
https://www.w3.org/TR/epub-34/#sec-font-obfuscation
Describe the problem
The Font obfuscation algorithm starts by creating an obfuscation key. This key is, essentially, the hash of the publication's unique ID. The specification refers to SHA-1 as the hashing algorithm to be used. However, SHA-1 is, by now, considered to be outdated, insecure, vulnerable to hash collision attacks, see, e.g., the relevant Wikipedia page. The current alternative is to use a member of the SHA-2 family (SHA-256, SHA-384, or SHA-512).
We may say we do not really care because we do not claim to be very secure when performing obfuscation. I.e., SHA-1 works for us. Which is correct, but the practical problem is that NIST has officially retired SHA1:
"NIST is announcing that SHA-1 should be phased out by Dec. 31, 2030, in favor of the more secure SHA-2 and SHA-3 groups of algorithms.
This means that some organizations may not be allowed to use SHA-1 after that date. I.e., we cannot be idle on this.
Describe the fix or new feature you propose
My proposal is to:
- declare the usage of SHA-1 deprecated, and replaced by SHA-256 (this is the most widely used version of SHA-2; other, more secure versions like SHA-384 or SHA-512 are used for highly security-sensitive applications, which we are not)
- reading systems are required to understand SHA-1 for backward compatibility reasons.
Note that the details of the obfuscation algorithm's will have to be modified, too: the current wording relies on the fact that the output of SHA-1, i.e., the obfuscation key, has exactly 20 bytes as opposed to SHA-256, which produces 32 bytes.
Section
https://www.w3.org/TR/epub-34/#sec-font-obfuscation
Describe the problem
The Font obfuscation algorithm starts by creating an obfuscation key. This key is, essentially, the hash of the publication's unique ID. The specification refers to SHA-1 as the hashing algorithm to be used. However, SHA-1 is, by now, considered to be outdated, insecure, vulnerable to hash collision attacks, see, e.g., the relevant Wikipedia page. The current alternative is to use a member of the SHA-2 family (SHA-256, SHA-384, or SHA-512).
We may say we do not really care because we do not claim to be very secure when performing obfuscation. I.e., SHA-1 works for us. Which is correct, but the practical problem is that NIST has officially retired SHA1:
This means that some organizations may not be allowed to use SHA-1 after that date. I.e., we cannot be idle on this.
Describe the fix or new feature you propose
My proposal is to:
Note that the details of the obfuscation algorithm's will have to be modified, too: the current wording relies on the fact that the output of SHA-1, i.e., the obfuscation key, has exactly 20 bytes as opposed to SHA-256, which produces 32 bytes.