Skip to content

Posts tagged ‘SHA256’

Jun 9

4 Comments

OAuth2 and LabVIEW — Revisited for 2020, A Bug in the SHA256 VI

In part one of this 2020 update, I began a journey of updating my OAuth2 example to use a new feature in LabVIEW 2020–the new hash function that supports SHA-256, among other algorithms.

Where I left off, I needed to modify the output of the new VI to create a byte array instead of converting it to a lowercase hex string.

I proposed three choices:

  1. Ignore the 2020 VI and just use the .Net implementation I used in 2019.
  2. In my SHA256.vi, add code after Byte Array Checksum.vi to convert the hex string back into a binary array.
  3. Make my own copy of Byte Array Checksum.vi and remove the subVI which converts to a lowercase string.

Which one did you choose? I decided to try all three. I already had #1, since it was the 2019 version. Here’s a quick and dirty implementation of #2, where I convert the hex string back to a byte array.

After calling the 2020 VI, convert it back to a byte array

And here’s an implementation of #3, where I went and found the VI that called Bytes to Lowercase Hex String, made a copy of it, and removed the subVI call. I replaced it with a straight Byte Array to String.

Modify the vi.lib VI to replace the ASCII conversion with a Byte Array to String

What do you think so far? There are things I dislike about both #2 and #3.

  • In #2, it seems wasteful to convert it to ASCII, and then convert it back. These aren’t large strings, but it just seems like a hack.
  • In #3, I dislike the idea of modifying a vi.lib VI–especially one that’s not on the palettes.

I’m leaning towards #3, because it feels like the right implementation, even if it violates the “don’t mess with vi.lib VIs” principle.

Before I commit to a solution, let’s run the unit tests on each. The results for #1 pass with flying colors, of course. The results for both #2 and #3, though, fail. And I thought this was going to be easy. Keep reading below…

Read more

Jun 8

5 Comments

OAuth2 and LabVIEW — Revisited for 2020, Using the New SHA256 VI

After LabVIEW 2020 released, I thought I should revisit my OAuth2 example to see how I could apply new features to improve the code. I thought it would be simple and straightforward and magically better, and fit into a single blog post. But, I think it’s going to be more of a journey than that.

I decided to start with something simple: LabVIEW 2020’s implementation of the SHA-256 secure hash that’s needed for the code verifier. This ought to be able to replace the SHA256.vi in my 2019 example, which was based on a .Net call. This is one of the only things that was Windows-specific in my code.

My first step was to create a new repo for my 2020 code. I think I want to keep my 2019 version around, so I’m hesitant to create a branch to merge back into it. I may regret it, but it felt like a new repo was the way to go.

Next, after loading the project into LabVIEW 2020, I went to SHA256.vi and selected Find -> Callers. It’s only called from two places, one of which is a unit test helper VI. (Aside: The unit test was only listed because it used a helper VI. If you think that Find -> Callers should have also reported which .lvtest files call the VI, kudo this idea.)

Good, I thought–I have unit tests and can ensure that the new VI passes all my old tests. Spoiler alert: it wasn’t that easy. Keep reading below.

Read more