Better Support for Encryption/compression.

[Minty]

I would like to see more native support for compression and encryption/hash algorithms.

When it comes to compression and encryption. We are very much the poor relations to other languages that have a plethora of source and examples for SHA1, DES, 3DES, Blowfish, HMAC, Ryjindel, AES (encryption) and LZO, LZMA, LZW, GZip, JPEG2000 (compression) to name but a few.

Apart from "Zip" (which can only be used on files) and "twofish" (which is hardly an industry standard because of security concerns) we have very little choice but to use DLLs and SOs meaning our applications violate one of the biggest reasons for using LabView........cross-platform. We have very little in our tool-kit to make efficient and secure network applications for example. Especially if we are required to interface to existing systems that ave used these technologies for many years.

We cannot even write applications to access Twitter any more!

With the introduction of "Stream" prototypes in the new LV2010, it is essential to have these tools in our palettes.

[PhillipBrooks]

I contributed a .NET GZIP compress and decompress a while back, located here...

https://forums.ni.com/t5/Example-Code/GZIP-compress-uncompress-of-string-using-NET/ta-p/3507908

I don't have or use the Mac or Linux versions of LV. If those OSs have similar functions, then it should be possible to create cross-platform versions using the conditional disable structure.

Maybe someone with a Mac and/or Linux could take my code, add those platforms and submit it to the LabVIEW Example Code contest.

[TCPlomp]

---

@Minty wrote:

We cannot even write applications to access Twitter any more!

With the introduction of "Stream" prototypes in the new LV2010, it is essential to have these tools in our palettes.

---

Who is withholding you in developing an Oauth function?

Ton

[crossrulz]

Add Reed-Solomon to the list too

[AristosQueue (NI)]

Found this on the LabVIEW Tools Network:

http://sine.ni.com/nips/cds/view/p/lang/en/nid/209124 

Might have VIs to help you.

[Minty]

@TCPlomp

I did say native!. NI's support for encryption and compression is woefully inadequate.

There are bits and pieces around (there is an excellent "Blowfish" one around for example). But we are severly limited for choice and for encryption especially, it really needs experts in that field to ensure there are no back doors or mistakes that will compromise the security.

For OAuth with Twitter you need HMAC-SHA1.

@Aristos Queue

I have seen those and it was what I was referencing when I mistakenly said "TwoFish". But it isn't secure and not widely used. The biggest encryption ones (perhaps to be implemented first) would be RSA and SHA1 since they are used everywhere. For compression, I would settle for the Zip functions that we can use on strings as a starting point.

[PhillipBrooks]

---

@Minty wrote:

I did say native!. NI's support for encryption and compression is woefully inadequate.

There are bits and pieces around (there is an excellent "Blowfish" one around for example). But we are severly limited for choice and for encryption especially, it really needs experts in that field to ensure there are no back doors or mistakes that will compromise the security.

....

For compression, I would settle for the Zip functions that we can use on strings as a starting point.

---

I don't believe that NI should create their own code to implement various compression and encryption standards. I DO believe that they could provide platform independent VI libraries that could call the OS specific proven and tested APIs. If an OS vendor discovers a weakness or comprimise, they can release a patch and LabVIEW will 'just use it'.

As for string compression, my simple example does just that, but it's not platform independent.

If you want a LabVIEW native MD5 checksum function, look for

     vi.lib\Utility\MD5Checksum.llb\MD5Checksum File.vi.

I learned of this via Darren's Nuggets: http://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-05-15-2006/m-p/365252.

In the end, I agree with your idea; encryption is not something where you want to 'roll your own'. In a way, this also relates to the various ideas/requests for SSH/SFTP updates to the Internet Toolkit.

The addition of standardized security to data and connections is often a requirement, and LabVIEW is behind the times. NI can't possibly do it all themselves, but they can make it easier for us by wrapping up OS native functions for us. I certainly would NOT want to pay a premium for a "Security and Compression" toolkit!

Kudoed!

[PhillipBrooks]

See Exchange Idea: Native SSH and SFTP Support

In both cases, I'm reminded of my experiences before the lossy enqueue element was available; you can cobble something that will work, but it's like attaching curb feelers and dear whistles to a Ferrari.

[Minty]

@Phillip Brooks

I wholeheartedly agree that I wouldn't want to see it in yet another tool-kit (and the deer whistles/Fararri . lol). But that would be better than nothing. As for wrapper functions or NI created. I don't really care as long as NI supply prototypes so that I can use. But OSs only support a limited number of methods and I would ideally like to see much more. The Zip prototypes use a native function in the Labview.exe and I don't think it would be a great leap for them to allow us to pass strings instead of a file name.

As for SSH et al. If we had our own encryption libraries someone would have written them by now instead of asking for them in the internet tool-kit. I see those more of an implementation of encryption algorithms rather than than encryption in their own right though.

[AristosQueue (NI)]

As was mentioned earlier, NI writing its own security algorithms is a terrible idea -- no company should be doing that. The only viable security code is code that is open and vetted by huge numbers of mathematicians, cypher writers and hackers. Shipping DLLs and VIs that wrap those DLLs with each of our platforms would be viable, though it would represent a signficant amount of effort to maintain and rev. And it could pose problems for distribution of LabVIEW, since including encryption APIs limits where the US Gov't will let you sell products.

I think a far better approach for any user who wants to do encryption is to find an existing, open, shared DLL library and use the DLL Wrapper Wizard to create VI entry points for that DLL. You're going to need to patch that DLL as an independent part of your application anyway if any security vulnerabilities are discovered and the DLL revs. You don't want to be waiting for the next LabVIEW release to rebuild your app and apply a hot fix. And you don't want to be dependent upon any particular vendor's security model.

Now, if you can get one of the major white hat conglomerates to start programming in LabVIEW and developing the algorithms natively, that's a different story. But at that point you would still want a toolkit that is separate from LabVIEW and can rev independently. In this case, it's a case of wanting to be able to change the locks on your Fararri without buying a new car.

[Minty]

@Aristos Queue

No company should be doing this? NI already have. They already have one for TEA and XTEA for the FPGA (which I believe you pointed out).

Whats wrong with NI porting others to native LabView? Open for everyone to see and test. Buy the blowfish vi if they have too, tidy it up and put in in our palettes as part of the distribution as well as the TEA and XTEA..I think the "not our problem" defence is a bit weak. Do I really need to buy a new ferrari to change the locks???? I think you need to re-think that analogy 🙂

The only reason I can see that NI would only consider a DLL or including it in the Labview.exe is so that they could put it in a tool-kit.In which case its financial issue, not a technical one.

But this post is not only about encryption. Its also about compression as well.There are no "security" concerns with that. It is a request for functionality in Labview which is not currently available and is well supported in other langauges. Nothing more. How NI do it is of no concern to me, only that they do so that I don't have too.

By the way. How do you remove Kudos? Yesterday it was 8. now it is 7.