SHA256 Hash Algorithm

[ACS]

Greetings, all!

This is pretty self-explanatory. I need a LabVIEW implementation of the SHA256 hash algorithm. I could do it myself, but I was hoping one already exists. Has anyone written such a beast?

Thanks!

[hooovahh]

I've never made anything like this in LabVIEW but there are several commonly used DLLs which give you this function.

Searching Hashes.dll in google came up with several places to get a DLL that calculates a whole bunch of hashes.

MD2

MD4

MD5

SHA1

SHA256

SHA384

SHA512

HAVAL128

HAVAL160

HAVAL192

HAVAL224

HAVAL256

GHOST

TIGER128

TIGER160

TIGER192

RIPE-MD128

RIPE-MD160

CRC32

CRC16

ARC-CRC

I don't have any VI that uses this DLL but I don't think it should be too hard to get the functionality you want.

[Shaun Hayward]

On on a mac at the moment so can't check but I'm sure there must be a SHA256 call in the .NET stuff (probably in system.security.cryptography)

[MikaelH]

I tried it through .net and it works.

I had to browse for the mscorlib.dll file for LabVIEW to find the SHA256Managed-class.

Cheers,

Mikael

[ACS]

I tried it through .net and it works.

Awesome, thanks!

[Jim Kring]

On 7/15/2010 at 7:31 PM, MikaelH said:

I tried it through .net and it works.

I had to browse for the mscorlib.dll file for LabVIEW to find the SHA256Managed-class.

Cheers,

Mikael

Hey @MikaelH. I can't seem to be able to create this on my system. Can you post a VI or a snippet of the above code? Thanks and wishing you well.

[dadreamer]

I have just tested on LabVIEW 2019 and this works fine. Here are the VI and the Snippet, back-saved to LV 2014.

SHA256.vi

[Rolf Kalbermatter]

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.

Edited March 29, 2020 by Rolf Kalbermatter

[gb119]

For the first of those, you'd want the LV2018 branch. Jim K recently brpught some infelicities in the code to my attention - which of cousre becomes an incentive to fix things (thus proving Rolf's point!). I'm still having an issue with files> 2Gb - there's something I don't understand when dealing with 64bit files (on 64bit Windows and 64bit Labview). Not helped by the fact that testing is slooooooow.

[Neil Pate]

On 4/4/2020 at 11:15 AM, gb119 said:

For the first of those, you'd want the LV2018 branch. Jim K recently brpught some infelicities in the code to my attention - which of cousre becomes an incentive to fix things (thus proving Rolf's point!). I'm still having an issue with files> 2Gb - there's something I don't understand when dealing with 64bit files (on 64bit Windows and 64bit Labview). Not helped by the fact that testing is slooooooow.

@gb119 I am trying to use your HMAC - SHA256 to generate a token to allow me access to an Azure Iot hub. I have a snippet of c# code that works fine and I am trying to translate into LabVIEW but not having much luck.

I don't really understand the HMAC stuff properly. Are all SHA256 HMAC implementations the same?

 

The LabVIEW code above is mostly correct, the decoding of the URI is not quite the same but I manually change this to match the c# code.

I have verified that stringToSign is identical in both implementations, so something is happening after this. The string coming out of the HMA SHA256 is completely different to the c# code which does not look like a Base64 string at all.

My knowledge of this kinda stuff is not good so I am probably missing something super obvious.

Any tips?

ps: apologies for resurrecting this old thread, I should certainly have started a new one.

Edited August 3, 2020 by Neil Pate

[Darren]

34 minutes ago, Neil Pate said:

I am trying to use your HMAC - SHA256 to generate a token to allow me access to an Azure Iot hub. I have a snippet of c# code that works fine and I am trying to translate into LabVIEW but not having much luck.

I remember having to figure this out when generating tokens for the LabVIEW Cloud Toolkit for Azure. I remember that there was some weird stuff I had to figure out, but I've long since forgotten how I did it. On the bright side, the toolkit is open source, you can browse through the source code here to see how I did it.

[Neil Pate]

29 minutes ago, Darren said:

I remember having to figure this out when generating tokens for the LabVIEW Cloud Toolkit for Azure. I remember that there was some weird stuff I had to figure out, but I've long since forgotten how I did it. On the bright side, the toolkit is open source, you can browse through the source code here to see how I did it.

Ah excellent, thanks!

[Neil Pate]

And it is working! Thanks @Darren

 

Edited August 3, 2020 by Neil Pate

[FixedWire]

"Available in LabVIEW 2020 and later: the TLS functions are available in the Functions > Data Communication > Protocols > TCP > Transport Layer Security (TLS) palette."

I'm posting here in case someone comes along like myself after stepping into a deep "let's secure this" hole and needs ideas or hasn't seen this yet.

[djac]

Hi Everyone, 

I'm doing something similar. Can anyone offer some advice. I have a python code that I'm trying to convert to LabVIEW. It uses HMAC and base64 encoding. To make sure that the logic is working, I'm comparing the outputs from python code with LabVIEW by using the python node in LV 18. Ideally both signatures should be matching. Here is the python script and the  LabVIEW VI that I made.

 

But the signature generated by LabVIEW VI doesn't match the python output. I'm using https://www.vipm.io/package/university_of_leeds_lib_sha256/ for HMAC signature generation.

For base64 encoding/decoding, the example code VI's were modified and used. https://forums.ni.com/t5/Example-Code/LabVIEW-Utility-VIs-for-Base64-and-Base32Hex-Encoding-Using/ta-p/3491477?profile.language=en.

Attached are the VI's and the python script.

 

auth.py HMAC Sign.zip

Edited September 7, 2021 by djac

[ShaunR]

37 minutes ago, djac said:

Hi Everyone, 

I'm doing something similar. Can anyone offer some advice. I have a python code that I'm trying to convert to LabVIEW. It uses HMAC and base64 encoding. To make sure that the logic is working, I'm comparing the outputs from python code with LabVIEW by using the python node in LV 18. Ideally both signatures should be matching. Here is the python script and the  LabVIEW VI that I made.

 

But the signature generated by LabVIEW VI doesn't match the python output. I'm using https://www.vipm.io/package/university_of_leeds_lib_sha256/ for HMAC signature generation.

For base64 encoding/decoding, the example code VI's were modified and used. https://forums.ni.com/t5/Example-Code/LabVIEW-Utility-VIs-for-Base64-and-Base32Hex-Encoding-Using/ta-p/3491477?profile.language=en.

Attached are the VI's and the python script.

 

auth.py 371 B · 0 downloads HMAC Sign.zip 199.9 kB · 0 downloads

At a guess I expect it's because you are decoding with UTF-8 in your python.

I checked the HMAC library you are using and it produces the correct hashes for test vectors.

[djac]

Hi @ShaunR,

Thanks for your reply. Any idea how to replicate UTF-8 decoding in LabVIEW? 

[ShaunR]

5 minutes ago, djac said:

Hi @ShaunR,

Thanks for your reply. Any idea how to replicate UTF-8 decoding in LabVIEW? 

There are some primitives but not easy to get to, so here they are.

UTF8 LV80.vi

[djac]

Thanks. But using that VI didn't make any difference.

[ShaunR]

10 minutes ago, djac said:

Thanks. But using that VI didn't make any difference.

Well. If your key is greater than the block size (64 bytes) then the library you are using will hash it first to make it 64 bytes in length. If you are passing the hex-text representation of the key, it will probably be longer than that so maybe it's being hashed first.

[djac]

That makes sense..let me try by providing the key as normal text.

[djac]

well. that isn't the issue. Do you have any other suggestions for me to try.

[ShaunR]

3 hours ago, djac said:

well. that isn't the issue. Do you have any other suggestions for me to try.

Well. the output of the python hmac is a byte array and the output of the LV hmac is a hex string so I expect you have to convert the LV hmac output into a byte array before passing it to the encode like this:

Generate Signature.vi

By the way. None of your sources (message or key) are base64 encoded so you may run into errors when trying to b64decode normal text.

Edited September 7, 2021 by ShaunR

[djac]

Hi @ShaunR,

Thank you!. I figured it out a couple of minutes ago. The way you have shown is exactly how I did it. I had to print each output in python to understand what was going wrong. I hope this helps someone in future.