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.

[Minty]

What's the difference? (apart from no entries in the other area...lol).

Isn't it diluting the ideas a bit having multiple choices for where to post? I'm not complaining (I'm very pleased my idea caught your attention) but I (personally) would really like to see this as an inbuilt feature rather than an add-on tool-kit.

If it's a choice between nothing or a tool-kit, then a tool-kit it must be but I would rather the peeps at NI make that decision not me :).

[Biggeveen]

Do not forget SHA-2 (SHA-256 ect), and SHA-3 when it is released. SHA-2 has already been coded in pure G by TCPlomp, available for download in this post (note you need a tool like TortoiseHG to download from Bitbucket).

Many other hashing / encryption functions are available in the $20 Crypto-G library, but this should be included in Labview itself.

[AristosQueue (NI)]

> Many other hashing / encryption functions are available in the

> $20 Crypto-G library, but this should be included in Labview itself.

I don't know anything about the company that makes this toolkit. I am impressed that the toolkit ships with source diagrams included -- that's a pretty major security requirement in my book, and it is unusual for a paid product to do that. I know that the algorithms that they have implemented are public algorithms, but how much checking has the code been through to guarantee that the implementation is correct? How strong is LabVIEW's random number generator? Does the parallel nature of LabVIEW introduce some element into the computation that makes it unsecure? Did they use some LV feature that opens the encryption to spying from elsewhere on the network? There's no information on their web page about how much peer review has been done. The feature set does list "References and official documents", which might be certificates of correctness from some certifying authority, or similar. These somewhat paranoid concerns are things I do not have to worry about with the mainstream open source C/C++ libraries.

For NI to develop expertise in cryptography on its own would be a committment of resources that I do not believe is warranted, especially if a third party, already educated in encryption, can make the libraries available for a mere $20.

All this is merely my personal opinion. I'm stressing that because on this topic I definitely don't speak for NI -- whether or not we would create a toolkit dedicated to any given task is way outside my baliwick. So those of you who like this idea, don't be discouraged by my posts -- others at NI may decide this is something we should go after.

[GregSands]

@Biggeveen: "(note you need a tool like TortoiseHG to download from Bitbucket)"

Just a note - there's also a link "Get Source" on the right of the screen so you can download it without another tool.

[Minty]

Don't forget this is also about compression too. If it's "too hard" to do enryption (I don't think it is) then at least NI should give us LZMA and ZIP that can en/decode streams.

Aristos Queue on 12-01-2011 10:14 AM wrote

how much checking has the code been through to guarantee that the implementation is correct?

--------------

How much did TEA and XTEA go through?

Aristos Queue on 12-01-2011 10:14 AM wrote

How strong is LabVIEW's random number generator?

--------------

As strong as you want it to be. If it's not good enough you could use the OS's generator (if not the whole API )

Aristos Queue on 12-01-2011 10:14 AM wrote

Does the parallel nature of LabVIEW introduce some element into the computation that makes it unsecure?

--------------

I think you of all people should already know the answer to that one.

Aristos Queue on 12-01-2011 10:14 AM wrote

 Did they use some LV feature that opens the encryption to spying from elsewhere on the network?

--------------

I imagine you already know that too with the webserver SSL implementation.

I vote for Aristos Queue to be the compression & encryption champion at NI to represent the consumer

And how the hell do you quote other people in a reply

[AristosQueue (NI)]

> How much did TEA and XTEA go through?

I'm not questioning the algorithms. I'm questioning the implementations. The algorithm for a binary search is well known, but the first time I implemented it, I had a bug that would cause it to occassionally miss finding certain values. It usually worked, but occassionally not. Every time an algorithm gets reimplemented, there has to be concern about the correctness of the implementation.

> As strong as you want it to be. If it's not good enough you could use the OS's generator (if not the whole API )

I don't have the ability to evaluate the Random algorithm that LV uses. I don't know if that evaluation has been done. It's good enough for most purposes, but is that good enough for cryptography? No idea, and it is beyond my skill to find out. Do the folks who wrote this toolkit have that ability? Or are we all just assuming "random is random"? That would be one of the classic mistakes that algorithm writers have made over the years.

> I think you of all people should already know the answer to that one.

Why? I haven't studied their code. I am not intimate with the details of the algorithms being questioned. Maybe the algorithm as described says "store a value into this variable, then read it back in this other equation", but the way the code is written in LV, the equation gets evaluated before that variable gets set. Perhaps it should've been implemented in LV without using a variable and instead using dataflow, but maybe then you introduce some other concept (like a loop with a shift register), and now the implementation is drifing further away from the cannonical implementation.

> I imagine you already know that too with the webserver SSL implementation.

Cryptography in software requires a chain of trust. I use Firefox predominantly. I know the number of users that have their eyes on that source code. I know the respect that some of the folks who work on that have in the community. Therefore, although I don't have direct answers to those questions, I do have reasonable expectation that those questions have good answers. At the very least, all the concerns about "correctness of reimplementation" are gone -- they compile the same source code as the cannonical implementation. There's still the trusting trust attack, but there, again, the more eyes on that stuff, the less likely there is to be a problem. When I use a smaller product that uses cryptography, I'm definitely wanting as much extension of that chain of trust as possible -- knowledge that the smaller product is using the exact same DLLs that the big boys use goes a long way. Knowing that they used the same source code as the big boys when compiling their own DLL is still good. Knowing that they have their own implementation but it is open source is somewhat ok, but I hope you can see that it is substantially less trustworthy. Knowing that they have their own closed source implementation would make me avoid using the product for anything significant.

[Minty]

>I'm not questioning the algorithms. I'm questioning the implementations.

Thats what the approval process is for. TEA and XTEA have been through the process and obviously passed; they are now supplied by NI for the FPGA. Perhaps you should talk to the devs of those to see whats required.

>I don't have the ability to evaluate the Random algorithm that LV uses.

That should be documented (ISO compliance) so you shouldn't have to do it personally. It's probably in th NI security log-in binder :).

>Maybe the algorithm as described says "store a value into this variable, then read it back in this other equation",

Now your just being silly. No encryption algorythm is described in that way. It will be described as a mathematical and/or logical function block expression (Feistel Network).

>Cryptography in software requires a chain of trust

Are you saying that NI didn't evaluate the impact of including SSL in the NI webserver? I find that very, very difficult to believe.

What about compression 🙂 It's becomming the "elephant in the room" since you seem to be avoiding it.

[AristosQueue (NI)]

> What about compression 🙂 It's becomming the "elephant in the room" since you seem to be avoiding it.

Not avoiding it. It's just off-topic as far as the rest of the thread is concerned. Compression is fine.

[Igor_Titov]

About having only twofish and not having AES support... Actually, there is. Check free and native LabVIEW AES encryption library (NI certified) at http://vigods.com/toolkits/security/aes.html or https://decibel.ni.com/content/blogs/viGods/2012/06/04/labview-advanced-encryption-standart-aes-libr...

[Sam_Sharp]

I have just +1'ed this as I wanted to use GZIP compression on some JSON data I am sending using the HTTP Client VIs - the .NET GZIP implementation is apparently buggy and obviously isn't supported on RT and the closest I could get was finding the OpenG DEFLATE function which I tried to package into GZIP myself but I was getting framing errors.

It would have been nice if there was a native function for this.