ShaunR

I don't really understand why you want a DLL at all but calling a 32 bit DLL from 64 bit is called "thunking" and you really, really don't want to go there. If it's just a case of choosing a 32 bit or 64 bit depending on the LV bitness then the CLFN wildcards will do that for you (for different platforms too).

Some things that need to be done so it doesn't crash arbitrarily (not particularly you, just commenting on the latest incarnation). EVP_DigestFinal_ex mdlen parameter needs to be pointer to value instead of value as it returns the length, Return values need to be used (and checked). Currently the functions return Void when they should be I32. Need to check the MD_CTX pointer isn't 0 for each function. Edit. almost forgot. Remove EVP_cleanup(). In versions prior to 1.1.0 it will crash other functions that use EVP and after 1.1.0 it's a no-op.

Not mine. It's just two unconnected error clusters. For this reason I have a VI that I wrote in 2009 similar to what NI eventually eventually implemented (except it defaults to 4). . This is the diagram

Error 4 (EOF)still really annoys me. I still maintain it should be a warning and not an error. Every time I have to use my filter error to prevent passing it through I curse and wish a plague on NI. lol

There is an opk package in one of the feeds if it's not there already. Chances are, if it has SSH, it'll have compatible binaries. NIlibeay is just NI's compilation of OpenSSL.

Nice work. Glad you got there.

The destroy should be an Unsigned Pointer Sized integer (Passed by value) rather than adapt to type. You can also set the nodes to "Run in any thread" Rolf got there 10 secs before me.lol Untitled 1.vi

I don't think you can see the wood for the trees. I am saying I can't supply the actual code I used because it's commercial but I can help you "discover" how to do it which isn't bound by commercial restraints.

That is the old way. The EVP_Digest interface abstracts away the different hashes into unified set of functions. All that is needed is a while loop where they have two update functions in the example about 2/3rds of the way down in that link..

As I explained. The code I used is part of ECL so commercial IP prevents me from sharing. You should know or at least appreciate this! Correct. New, Init, update, final and free (the EVP interface). You will also need digestbyname. Once you have this you will also be able to do *all* the hashes, not just MD5.

I have a different solution... .. which is demonstrably an improvement. You can lead a horse to water but, this time, I guess I underestimated it's thirstiness.

Sorry. No can do. It's part of ECL but I've given you all the info to replicate it and proved it might be worth your while

This is fun Here are my comparative benchmark results for MD5 the NI SHA are abysmal.

Yuck. Cmd line Try using the EVP_Digest interface of the NIlibeay32.dll You can even have progress events if you want to be fancy I don't know why NI didn't use it

That's BS. MD5 is still the 2nd fastest checksum (SHA-1 being the fastest) and a checksum has little to do with security. They are obviously confused between security and integrity.

Hmmmm. They have removed MD5Checksum from the palette in recent LabVIEW versions?

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.

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.

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

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.

Only the Widechar functions support it. The functions are listed at the end of the link I posted.

To use long pathnames you need Registry setting. Use the filename functions ending in W (not A) e.g. CreateFileW instead of CreateFileA. LongPath in the executable manifest. The native LabVIEW functions use the functions ending in A, under the hood, which is why I wrote drop-in replacements for the native file functions which uses the functions ending in W. When you create an executable, you have the option to define a manifest file so the replacements work in the built executable. So as long as the registry or policy enables long paths, the built executables work fine for >260.

Of course there is something they could do. I expect the use of the ANSI versions of the file operations is making them resistant. I've my own set of compane equivalent of the native file operations that do it just fine - it's the Path Control that is the problem.

I'd say it's a bug. If you uncheck the "Lock FP" for the "Do" case it works as expected. Clearly the FP locking is being triggered when it shouldn't. Changing the compiler optimisation has no effect so maybe it's something else. Rather nasty IMO. Congrats for isolating it. Also does it in 2009 so I suspect it's been around for a while.

I can't account for your experience but for this library it is fine.