LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Password protected TDMS files

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

I need to guarantee data integrity as requested from the FDA/GMP. If we write our Properties and RAW-Results down to the TDMS files it would be very helpful to protect the data with a password to avoid data manipulation.

=> Please add a password! 😉

Proven Zealot

The format of the TDMS file is documented.  NI can't just "add a password" without many repercussions.


If you want encrypted data, encrypt it before you write it to TDMS.


If you need proper security, you need to TRACK changes made and you end up with CFR 21 Part 11 compliance.


From my point of view, data encryption is not the way to go. I would like to read the data from exp. Diadem or Excel without any special plugin. The file format wouldnt be changed except if you want to manipulate the Data. In this case the Password would be necessary.
=> Data intergrity rules: standard data formats, human readable, protect from manipulation, trackable (all possible except the protection)

Proven Zealot

If you want to retain human readability, then you might want to write a CRC for each data set so that you can detect if changes have been made.


The other option I see is switching to a service like SQL as opposed to a file format.  There you can define passwords to be able to connect.


Adding a password to TDMS is a no-go I think.


CRC was my first step to navigate arround this problem. But if you have a file > 300MB this solution is very slow. The database solution is really a good way to go, but not for every customer! 😉


=> Where do you see the problem with the password?

Proven Zealot

The file format is open.  How would you implement a password with an open file format without having a service between or encrypting the data when writing?

Trusted Enthusiast

It sounds like asking NI to put a password on a text file.

You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

Proven Zealot

The solution here is the same as for *any* file that you want to certify:

If you want the data to be readable, then what you want is a way to do signing. You can do that yourself -- write the data to the file and then sign the file using an encryption library and save the signature next to the TDMS file. If the signature cannot be verified, then the data has been tampered with.


If you're trying to sign that 300 MB has not been tampered with, yes, it takes time (it may or may not be slow depending upon your view of slow). NI doesn't have any magic that would make that not be slow if we did it compared to you doing it.


Achieving this should not require changing the file format of TDMS.

Proven Zealot

Fridu: if you're unfamiliar with using encryption to do signing, there's a pretty good summary here:

Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

DNatt, NI