Leaderboard

There is no need to go through external code for this. There have been many attempts at crypto libraries that are written natively in LabVIEW and they didn't fail because it is impossible but because nobody is interested to spend some time in searching for them or what a bad word, fork a few dollars over for them. That way authors have put out libraries in the past only to have them forgotten by the public and that is the most sure way for any maintenance work and improvement to be discouraged. Probably the first one was Enrico Vargas who wrote a pretty versatile Crypto library all in LabVIEW somewhere around 2000. It contained many hash and even symmetric algorithmes that were pretty well tested and he was an expert in that subject. And yes he charged something for that library which I found reasonable, I bought a license too and collaborated with him a little on some algorithmes and testing of them. I doubt he made much money with it though, as most Toolkit providers. Eventually it died of because he pursuaded other carrier options and maybe also partly because providing support for something that many were asking for but very few were willing to pay for is a frustrating exercise. A little googling delivers following solutions currently available: https://github.com/gb119/LabVIEW-Bits/tree/master/Cryptographic Services/SHA256 https://lvs-tools.co.uk/software/encryption-compendium-labview-library/ https://gpackage.io/packages/@mgi/hash Interesting disclaimer in the last link! 😀 I would say whoever understands the implications of this, is already aware of the limits in using such functions, but whoever isn't won't be bothered by it. There are several aspects to this, such that calling the same function in .Net or WinAPI (also a possibility) is not necessarily more safe as the actual string is still possibly somewhere in LabVIEW memory after the function is called, no matter how diligent the external library is about clearing any buffer it uses. Also many hashes are mostly used for hashing known sources. which does not have the problem that the original string or byte stream needs to stay secret at all as it is already in memory anyways elsewhere. So for such applications the use of these functions in LabVIEW would not cause any extra concerns about lingering memory buffers that might contain "the secret" after the function has finished.