File Encryption

[Travis_M.]

Hello,

" my security does not have to be super high...just high enough so an average joe can't mess it up =)"

I believe everyone here has made some excellent suggestions so this post is going to be pretty redundant, but it sounds like you have a couple choices in your implementation here:

1) Store the actual password to the file -- to do this you would need to encrypt it before writing, store the cyphertext, and decrypt it in your program. Those links to LabVIEW cryptosystems seem pretty good.  The open source blowfish algorithm looks like you could just use the top level VI and store the result of the encryption.

2) Store the result of a cryptographic one-way hashing function to the file and rehash/check the value every time Average Joe enters his password.  The probability of hash collisions and the more one-way the function is dictates the security level of the system.  Even a basic hash function seem sufficient for minimum security -- you could even write your own basic function if you did not want to mess with MD5 or some of the other algorithms out there.

A seemingly obvious solution would be to create an invisible control to represent the password, set the display to encrypted and make those values default.  However, the problem with this is programmatically making a control value default (i.e. this cannot be done) so it sounds like you are going to have to write to a file regardless.

Hope this helps a little, and I have attached an extremely basic string hashing function which will hash a string to a number within a ceartin range.

Regards,

Travis M
Applications Engineer
National Instruments

[esa_paranoid]

Thanks for all of the responses. 

I chose to go the route of just writing the actual password to the registry.  This is not really a "security" issue, more of a "I want to keep employees that do not know what they are doing" from changing anything...

thanks again

[JTAG]

Hi mike,

i'm trying to open your vi but i have labview 7.0  and your vi is 7.1 can you seand this vi for labview 7.0

regards,

eyal.

[mikeporter]

Here it is in 7.0...

Mike...

[alysko]

I would like to address this to NI:

there is a number of quesitons related to encryption in the forum. If encryption/decryption is implemented in labview level, so that any stream of data (data flow, variable, communication link) could be encrypted/decrypted by simply passing the data through a VI or/or setting an attribute (level/type of eencryption) to VISA/file ref/shared variable, most of the users would be very happy. The idea is to SIMPLIFY and to avoid usage of 3rd party software.

There is a number of applications that REQUIRE encryption. For example, a lab experiment does not need it, but an industrial application would really apreciate that. In academia, a lab experiment can be conducted, but encryption is highly desirable, if an automated system for marking the results or remote education is to be implemented.

Sincerely,

Albert

[mikeporter]

There is a larger issue here than convenience and that is security. The foundation of good crypto is the concept of peer review--the ability to have people that know crypto review implementations and insure that there are no security compromises (inadvertent or deliberate). if NI did something "built-in" you can bet your life that they would consider it "proprietary" and it would not be subject to peer-review. In the end we would have to take it on faith that there were no bugs or "backdoors". Over the years I have spent too much time fixing bugs in NI's toolboxes to feel comfortable with that idea.

A second point is that crypto is a discipline in and of itself. It seems unlikely that there is anyone at NI who is a crypto expert and anytime a company gets outside its area of core competency, there are problems. For example, database access is a lot easier that crypto and look at the mess that NI's toolkit makes of it...

Bottom line is that if the idea of encryption is privacy, then you need to be sure that information you encrypt really is secure.

Mike...

[rolfk]

---

@alysko wrote:

I would like to address this to NI:

there is a number of quesitons related to encryption in the forum. If encryption/decryption is implemented in labview level, so that any stream of data (data flow, variable, communication link) could be encrypted/decrypted by simply passing the data through a VI or/or setting an attribute (level/type of eencryption) to VISA/file ref/shared variable, most of the users would be very happy. The idea is to SIMPLIFY and to avoid usage of 3rd party software.

There is a number of applications that REQUIRE encryption. For example, a lab experiment does not need it, but an industrial application would really apreciate that. In academia, a lab experiment can be conducted, but encryption is highly desirable, if an automated system for marking the results or remote education is to be implemented.

Sincerely,

Albert

---

Mike already addressed the main issue about encryption and that is implementing encryption in a closed source app is almost always a bad idea. There is no peer review of any significance and the main security of such apps is not the encryption but in fact the closedness of it, and you can see where that leads with all the leaks and security issues the biggest closed source (eventhough it is sold as shared source) project on earth has.

Another one is the vast majority of security algorithmes and such you have. You have one way hashes of all sorts, encryption with public and private keys etc. While implementing an MD5 is not very difficult and once was considered a safe hash function if is nowadys recognized as having a few flaws and not being up to par to the task of really securing a password system. SHA is somewhat better but still might not be a good solution in all cases. Then there are many others and that are just the one way hashes. Public and private key systems are another sort and both more difficult to implement and also to incorporate in an app. Whatever NI might choose to implement (there is actually an internal MD5 algorithme in LabVIEW) it would always be not enough for some of the users, especially the ones who know how to use encryption for security and the rest would implement something in the bad assumption that they created something which would be secure.

Rolf Kalbermatter

[Enrique]

Security is better viewed as a system. "Encryption" is only a fraction of one third of the equation called "equipment" (i.e. tools); the other pieces are policy and people.

My experience is that most security violations occur because of vulnerabilities due to poor policies or people without a good sense of security. Usually the encryption algorithm works great but the key management policy is weak or non-existent; or people don't follow the rules (for example following a password selection guidance.)

It is also common to find security issues due to poor engineering practices - for example not removing code for testing purposes (probes) on the final release or not testing for invalid inputs. On this line: It is not just about which cryptographic algorithm to use - how you use it is more likely a bigger deal.

[Enrique]

---

@esa_paranoid wrote:

Thanks for all of the responses. 

I chose to go the route of just writing the actual password to the registry.  This is not really a "security" issue, more of a "I want to keep employees that do not know what they are doing" from changing anything...

thanks again

---

You did what?!?

[alysko]

At the moment, there is no special security features implemented in LabVIEW besides passwords. I need to have encryption to transfer data over the Internet. The level of security is the next topic. To discuss the topic of the level of security, you need to have some. Right now, there is NOTHING to use (supplied by NI), so the need is to have something and then it can be enhanced.

Another feature I would like is to be able to run secure web site with labview (to implement https server). This could be another solution and would exend the usability of LabVIEW further.