Estimated read time: 2 minutes
As it happened with MD5 hashes in the past, the world is currently moving from SHA1 hashes to SHA-256 hashes these days. This affects LibreOffice’s ODF signing feature as well, where we previously wrote and read SHA-1 hashes, but not SHA-256 ones. First, thanks to the Dutch Ministry of Defense who made this work possible (as part of a project implementing trusted signing and communication in LibreOffice), I could start work on tdf#76142 which attached a reproducer document as well, helping the implementation of this feature.
If you’re not into the digital signature details, SHA-256 is relevant in two aspects here:
it can be a signature method, denoted by the
it can be a digest method, denoted by the
Hashing is interesting in the context of digital signatures because typically not the whole document is signed, just a hash of it, and crypto frameworks like nss or mscrypto typically tie these two together, so you just say you sign with rsa-sha256, which in more detail means hashing with SHA-256 and then signing using rsa.
A valid signed document using SHA-256 hashing looked like this before:
I.e. we failed to validate the signature, and presented a dialog that suggested the signature is not valid. After my changes, it looks like this:
I.e. no error on loading, and the status bar icon tells the user that everything is fine, except that we can’t validate the certificate used for signing.
As for when should LibreOffice start writing (not reading) SHA-256 hashes when creating signatures, it’s an open question. Probably best to wait till most users already have a version that can read those hashes. Then we would still keep support for reading SHA-1 hashes, but we would use SHA-256 when creating new signatures.
Another detail is that the hard work of signing in LibreOffice is done by using libxmlsec. We bundled a heavily patched version from 2009, and it wasn’t clear how much work it is to port our patches to a newer upstream version, so I’ve initially backported the SHA-256 patches to our older version (for the nss and mscrypto backends of libxmlsec, as that covers what LibreOffice uses on Linux, Windows and OS X). At the end I managed to update our bundled libxmlsec to a newer (even if not the newest yet) version, so latest master got rid of those custom backports. As usual, you can try this right now with a 5.2 daily build. :-)