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.

[AristosQueue (NI)]

Kudos can be revoked by clicking on Idea Options at the top of the idea. Someone must've changed their mind.

I pointed out the toolkit because I was trying to point people to a workaround ... I'm not sure where that toolkit is based on, it was just the best I could find.

I don't think any lone company or individual should be porting algorithms because that's very error prone and one small tick in an encryption algorithm is a disaster for security. Not everyone agrees with my position -- clearly some people at NI have provided various algorithms at various points. I'm just saying I think it is in general a bad idea and if I was writing a secure protocol in LabVIEW, I would actually be happier getting my secure DLLs from a known security source than taking NI's word for it that the algorithm was implemented exactly, point for point, as it was in the original specification or code. If NI did generate LV VIs to implement secure algorithms, I'm not sure I'd rely upon those unless the code got the same inspection level that your average crypto distribution for Linux gets, which is highly unlikely.

[Minty]

Ok. That's your personal view, which you are entitled to (although I think you are selling the Labview community short on their abilities). What about compression? That is also what this request is asking for.

[AristosQueue (NI)]

> (although I think you are selling the Labview community short on their abilities)

Not just the LV community... I'm selling the entire programming community in all languages short. I've just seen too many encryption botches and I've come to believe only a very very conservative approach is viable. Please don't think I'm discounting the abilities of my users -- security is hard in any language, and should always have copious peer review. In my opinion.

As for compression, that's a very different story. We could implement libraries to do this. It's still the sort of operation that I'd (myself) prefer to just wrap standard libraries rather than reimplement (particularly since I may want to decompress data that was compressed by a source other than LabVIEW). But on that one I'd conceed that LV wrapping a different DLL on every platform would suffice. I'm still not sure you want NI to develop such libraries -- compression is hardly our prime area of research, but at least compression doesn't have the same risks if it isn't done exactly to spec that security does.

[JackDunaway]

>>  I think you are selling the Labview community short on their abilities

I wouldn't doubt if AQ is approaching this issue from an internal resource allocation standpoint... NI has finite resources which must accomplish not only development, but also maintenance, documentation, marketing, legal and so forth. There's also opportunity cost involved - if they commit to this project, what are they not doing?

I Kudo'ed this Idea for support of a very basic level of security and compression. I would consider this Idea complete if we got eight low-level VI's called Compress, Decompress, Encode, and Decode that work for streams (strings) and files. Just enough to make big things smaller, and keep data obscured from somewhat-bit-savvy users. Others may not consider this Idea complete unless NI offers a full range of protocol choices for security/compression, to which I would defer to AQ's viewpoint - it's best for NI to not reroll time-proven external libraries.

[Minty]

@JackDunaway > I wouldn't doubt if AQ is approaching this issue from an internal resource allocation standpoint

I'd agree with that. But that's not a discussion for here. That's an internal NI debate I thought the idea exchange was for NI to get feedback on what users want or would like to see to improve the product, regardless of if it's very hard or easy eye-candy (which many suggestions seem to be). 

I'm also guessing that AQ is a C or C++ programmer (or was in a former life) where writing or compiling a DLL on multiple platforms isn't an issue because he is familiar (or more likely an expert) with it and has all the tools. Many users of Labview are proudly "Graphical" programmers and only graphical programmers. I wonder how a C++ programmer would react if he was told you can't do that, you have to use pascal, write a class wrapper then support the pascal program on multiple platforms. But I digress.

The fact is. As a programmer using a development tool to produce programs for customers. For compression and encryption II have virtually nothing. Its a bit like having a farari (we'll keep on the theme...lol) without a license. You can drive it ok, but when a policeman asks you for your paperwork....your stuffed.

[tst]

If you want compression today, OpenG has a ZIP package, which I believe is multi-platform as well.

[Minty]

@tst

The open G version uses the zip dll. It didn't work on my LVx64 because you need a dll compiled for x64 (I just ended up with broken VIs). These are the sorts of problems you run into when going for external solutions and why I'd like to see them in native Labview. Labview does already have a Zip function as I believe I mentioned earlier, But I cannot use it on strings, only files. I would imagine the OpenG ones would be the same.

[TCPlomp]

Minty, I would raise this question on the OpenG forums. Rolf Kalbermatter (the main developer of the OpenG Zip library) is very helpfull. He'll probably asks you to compile a file on your system (natively). It is very hard to have all the possible targets available...

I am looking at the repository on Sourceforge, there is a DLL in the Win64 folder specifically for win 64 (direct download). Does that DLL work for you?

Ton

[Minty]

@TCPlomp

Thanks for the advice. But I only tried it to see what it was. The fact I couldn't use it isn't an issue.

@TCPlomp > It is very hard to have all the possible targets available

I agree. Which is why I am requesting these for labview which is x-platform..

[Jervin Justin]

Hi Minty,

We just launched a new branch of the NI Idea Exchange to foster ideas for LabVIEW Add-ons. The intent was to create a place for LabVIEW Add-on developers (both NI R&D and developers in the community) to find ideas that matter to the community.

This is part of our ongoing effort to enable LabVIEW developers to productize LabVIEW code. Some of the other things we’ve done this year were adding Licensing & Activation for 3^rd Parties, launching the Compatible with LabVIEW Program and the LabVIEW Tools Network.

We’ve identified your particular idea as one that could potentially be made into an Add-on and would like to move it to this new Idea Exchange so that Add-on developers can easily find it. Would this be okay with you?

Thanks!