Cryptographic hash functions

[ncny]

Ten years ago a post asked if Calc supported cryptographic hash functions, and was brushed off with the reply that only functions mentioned in the ODF standard are implementation candidates, and community-supplied extensions should be used.

Since then, Calc has added the RAND.NV() and RANDBETWEEN.NV() functions which are not part of the ODF standard (this is explicitly stated in their documentation), so this reason no longer applies.

As the original question pointed out, having hash/digest functions available natively in Calc would assist in creating more robust and secure processes where Calc is part of the workflow. Arguably, they’re at least as important as RAND.RV(). Is there a chance we’ll be seeing hash and digest functions in the future?

[erAck]

“Brushed off” by someone who has no say in what would get implemented and what not (in fact no one really has, if a code contribution is well implemented and useful it would probably get accepted).

But core-wise there are certainly more important functions to implement. These types of hash and digest functions would be good candidates for a Calc Add-In implementation.

[lalle]

Thank you for this comment that push for hash functions in Calc. This is badly needed, as pointed out, for workflows and file integrity checks. I too request this, as a good advantage compared to Microsoft excel too.

[robleyd]

How to Report Bugs in LibreOffice - The Document Foundation Wiki

Also for enhancement requests.

[sokol92]

@lalle

I too request this, as a good advantage compared to Microsoft excel too.

Unlike MS Office, Libreoffice has a hashlib “under the hood” with a huge selection of features.

[mikekaganski]

These functions should not be implemented in Calc core anyway, even though the reason stated in that older Q&A is wrong (as @erAck mentioned). All cryptographic functions deal with bytes. In Calc, you deal with numbers, strings, formats, formulas… but not with bytes. So a SHA512(A1) would be very loosely defined; and the specific decision how to treat e.g. the text there (as UTF16, as the underlying string implementation? as UTF8? as user locale specific encoding?) that would be implemented in the program would only fit some fraction of possible interested users. Not to mention the endianness of numbers, specific floating-point bytes representation, etc.

Without even asking how Calc could be used in that workflow that you mention, I think that using the appropriate tooling, like the Python library mentioned by @sokol92, it the proper solution.

[lalle]

Thanks for pointing out the “under the hood” capabilities. So this could potentially help implementation of actual calc functions for regular users.

[erAck]

You might be misinterpreting the information. That wasn’t about “implementation of actual calc functions for regular users”, but the libraries an Add-In implementation in Python (under the hood) could use.