​​NI LabVIEW Cryptography and Secure Communications Guide​

Cryptography is more important today than ever before to protect data. Even for test systems, engineers must consider cryptographic techniques to protect test data both in transmission and in storage. Encryption can protect the data if the system becomes compromised, either by a malicious actor gaining access or by an inside actor unintentionally making the data available outside of the intended use. Data protection, including encryption, is important to protect a company’s intellectual property, to protect customer data, or to comply with security regulations.

This document provides a practical, implementation-focused guide to cryptography in LabVIEW environments, designed for engineers who may not have prior experience with cryptography.

​What Is Cryptography?

​Cryptography is a broad field of data protection techniques including encryption, hashing, digital signatures, and key exchange.

​Encryption is analogous to locking data with a key. Plaintext is the text before encryption, which can be read by anyone without a key. Ciphertext is the text after encryption, which can be accessed only by someone with a key to unlock the encryption.

​In digital encryption, a key is a set of characters used to encode the bits of plaintext to turn it into ciphertext. Anyone with a key can unlock the data, so keys must be protected. No encryption algorithm can overcome the inadvertent sharing of the key that unlocks the encrypted data. To protect data, keys are often rotated to generate new ones, making the older keys obsolete.

​Hashing is a one-way transformation. It transforms a collection of data bits into a fixed-length digest that is extremely unlikely to be duplicated by different inputs. This is used to verify the integrity of source data. Unlike encryption, a hash cannot be reversed to the original source data.

​A digital signature uses a private key to generate a cryptographic signature based on a hash of the data. The signature is sent along with the document. The recipient uses the sender’s public key to verify the signature and confirms that the document has not changed since it was signed.

​Encryption Details

​This section provides a detailed description of how encryption works. For readers interested in a deeper discussion, JKI provides an excellent introduction at Simple XOR Cipher Encryption in LabVIEW.

​Encryption begins at the lowest level with the XOR function. The mathematical properties of XOR are unique and allow for no information to be lost as data is moved through it. The XOR function is unique because the half of the outputs are true and half are false:

​Table 1: XOR Truth Table

​XOR also has associative and commutative properties that allow it to move data in both directions through the functions. This fact means that data can be processed through XOR, then reprocessed to restore the original data.

​Using these properties, a message can be XORed against a key to generate a ciphered message. Using XOR and the same key, the ciphered message can be restored to the original message.

​Using XOR for encryption, one can create an unbreakable code if all of these conditions are met:

• ​The key is truly random.
• ​The key is at least as long as the message.
• ​No part of the key is reused.
• ​The key is kept secret.

​There are challenges to doing this. It is not reasonable to expect the key to always be the same length as the message, especially when the length of the message is not known before starting transmission. It is also difficult for modern systems to generate truly random keys with no repeated parts.

​To overcome the problem of the key length, an algorithm is used to generate a key of any length, based on a known starting point. The starting point for the algorithm is generated randomly and shared between the sender and receiver. Using the same seed and the same algorithm, the receiver can generate the same key generated by the sender using that same seed and algorithm.

​The LabVIEW program shown in Figure 1 illustrates this concept using the Gaussian white noise generator. Because this pattern appears random, passes many randomness tests, and is fully reproducible if you know the initial seed, this pattern is pseudo-random.

​Figure 1: Pseudo-Random Number Pattern Generation in LabVIEW

​The preceding code lets the user select between using the same seed or different seeds. When the same seed is used, the same “random” pattern is generated, shown in Figure 2:

​Figure 2: Pseudo-Random White Gaussian Noise Generation

​If both the sender and the receiver know the seed and the algorithm, they can recreate a key without transmitting a key that is the same size as the message.

​Sending an encrypted message therefore consists of two parts: generating a key using a seed and algorithm and performing XOR on each character of the message using the generated characters of the key.

​It is important to note that a password is not the key; the key is generated from the password. A password is transformed into a strong, fixed-length cryptographic key using a process called a key derivation function (KDF). Passwords are short, predictable, of variable length, and often weak. KDFs turn passwords into something of an exact size, with high randomness, and with consistent formatting.

​Keys must be generated from a cryptographically secure random source. In general, operating system random generators should be used instead of application-generated randomness. OS random generators generate random numbers from a variety of sources including keyboard timing, mouse movement, CPU jitter, and other measurements not typically used by an application. 

​A KDF adds “salt” to a password, as depicted in Figure 3. Salt prevents attackers from guessing keys because two identical passwords produce two very different keys.

​Figure 3: Salt Added to Password by KDF to Generate a Key

​Some of the algorithms a user encounters in encryption are for the KDF, and some are for the actual encryption. Both are critical to ensure the security of the encrypted data.

​A key is a fixed length, while a message may be variable in length. In most encryption algorithms, the message is broken into chunks the same size as the key. The key is then applied repeatedly to each section of the message to encrypt the data.

​Security depends on both the algorithm and key length. Longer keys generally increase resistance to brute-force attacks. The minimum length to use depends on the type of encryption used, the sensitivity of the data, and the expected lifetime of the data. For general use today in AES encryption, 128-bit keys are considered the minimum length to keep data secure. Many organizations prefer AES-256 for highly sensitive or long-lived data, although AES-128 remains approved and secure for many applications. AES-256 is currently considered resistant to known quantum attacks, although future cryptographic standards will continue to evolve.

​Researchers have developed many types of encryption algorithms, each with advantages and disadvantages. There are two main categories of cryptography algorithms—symmetric and asymmetric.

Symmetric Encryption

​Symmetric algorithms use the same key to both encrypt and decrypt the data. The process is depicted in Figure 4.

​Figure 4: Symmetric Encryption

​Symmetric encryption is faster and more efficient than asymmetric encryption because the operations are simpler. Symmetric encryption is ideal for large files, streaming data, and real-time test systems.

​The security of symmetric encryption is highly dependent on the key protection—if someone gets the key, they can decrypt everything. Symmetric keys require that the sender and receiver both have the key, which means the key must be delivered to the receiver. In some cases, this is not possible, so asymmetric encryption is used.

​The most common symmetric encryption is AES. It is designated by the key length, so AES-128 and AES-256 vary in the length of the key used. For most applications, AES-256 is recommended unless you have a specific reason not to. AES is allowed for FIPS requirements. ChaCha20 is another symmetric encryption algorithm commonly used today.

​Transport layer security (TLS) uses symmetric encryption to send data, after securely exchanging keys using asymmetric encryption. Modern systems should use TLS 1.2 or TLS 1.3 and should avoid SSL and older TLS versions. These newer TLS implementations typically use authenticated encryption algorithms such as AES-GCM or ChaCha20-Poly1305.

​For most data storage and data transmission situations in test systems, use symmetric encryption.

​Asymmetric Encryption

​Asymmetric encryption is slower than symmetric encryption, so it is not used for large data. It is typically used for internet communication, device-to-server connections, and distributed systems. Asymmetric encryption uses two different yet mathematically related keys to encrypt and decrypt data. These two keys are called the public key (which can be shared), and the private key (which must be kept secret). Where symmetric encryption is like a safe where two people have matching keys to unlock it, asymmetric encryption is like a mailbox with a slot where anyone can drop a letter in (using a public key), but only the owner can unlock and read it (with a private key). The process is depicted in Figure 5.

​Figure 5: Asymmetric Encryption

​Public keys are shared openly, usually alongside a certificate file which verifies that the public key is authentic. Private keys are kept secret by the owner. This enables secure communication without prior trust; you don’t have to trust the party doing the encryption to share the key with them.

​The two most common asymmetric encryption algorithms are RSA and ECC. RSA is older with larger keys, but it has wide adoption today. RSA key lengths of at least 2,048 are recommended. Elliptic curve cryptography (ECC) is smaller and faster than RSA and is recommended for modern systems, with key lengths of at least 256 bits. Both RSA and ECC are allowed under FIPS regulations, but neither are expected to be safe in a post-quantum computer world. Asymmetric algorithms will evolve as post-quantum standards are adopted.

​Hybrid encryption systems are common today. Asymmetric encryption is used to establish a shared key, which is then used in symmetric encryption for the actual data. For example, TLS uses asymmetric encryption during the initial handshake, then uses symmetric encryption (AES) for data transfer.

Hashing and Integrity

​Encryption protects confidentiality by keeping data secret. Another part of a secure transfer is ensuring that data has not been changed, which is done with hashing.

​A hash function takes any input—a file, message, or stream—and produces a fixed-length output called a digest. A hash digest is the same length regardless of the size of the input data, and a tiny change in the data results in a completely different hash.

​A common use case of a hash is for data downloads. A sender computes a hash for the file and sends that to the receiver. The receiver downloads the file and computes the hash. If the file has not changed, the hash remains the same.

​Hashes are used in a variety of cases beyond data downloads. A hash can be used to ensure that a file has not changed on disk, so an application can import data from the file with confidence that the data hasn’t changed. A hash can verify a computer or OS configuration and block booting if anything has changed, preventing a malicious party from tampering with the computer.

​Hashing is combined with encryption to make systems more secure. TLS uses a hash to verify handshake information, to make sure the keys exchanged are not changed during the transaction.

​The most common hashing algorithm is SHA (usually SHA256). MD5 is also commonly used for file downloads to verify file integrity, but MD5 has known weaknesses for other uses. MD5 is not FIPS approved, but SHA256 is FIPS approved.

​Authenticated Encryption

​Encryption alone protects confidentiality but does not guarantee that data has not been modified. Modern cryptographic systems therefore use authenticated encryption, which combines encryption and integrity protection into a single operation.

​Authenticated encryption algorithms generate encrypted data along with an authentication tag. When the receiver decrypts the data, the authentication tag is verified. If any part of the message has been changed, decryption fails and the modified data is rejected.

​Common authenticated encryption algorithms include AES-GCM, AES-CCM, and ChaCha20-Poly1305. These algorithms provide both confidentiality and integrity and are widely used in modern protocols including TLS.

​When available, authenticated encryption modes should be preferred over older approaches that combine encryption and hashing separately, because they are simpler to implement correctly and reduce the risk of security vulnerabilities.

​Secure Protocols

​Using the previously mentioned encryption and hashing technologies, there are several secure protocols in use today.

​TLS is used for secure network communication. It is a protocol that provides secure communication over a network by combining encryption, authentication, and data integrity. It ensures that data sent between parties is private, unmodified, and sent to the correct recipient. TLS encrypts data, usually with AES, and detects tampering with hashing, and verifies identity with certificates.

​SSH is a protocol used to securely access remote systems over a network. SSH uses message authentication codes (MACs) based on hash functions like SHA to verify data integrity and verifies user/server identity on login. In an SSH transaction, the server presents a public key. The client typically stores the server public key after the initial connection and checks for changes on future connections. The client then exchanges keys with the server to encrypt data between the server and client with AES or ChaCha20 encryption.

​Hypertext transfer protocol secure (HTTPS) is a version of HTTP that uses TLS to encrypt and secure communication between a client and a server. HTTP is how the data is structured in a web request, and TLS is how that data is protected. HTTPS is commonly used in web browsers today and is also used in web APIs, cloud services, and industrial or test endpoints.

​Without HTTPS, data can be intercepted or modified while it is being transmitted between systems across any untrusted network. With HTTPS, data is encrypted, verified, and protected from tampering. HTTPS may be compliant with FIPS regulations, but it may not be—it depends on the TLS stack used to support the protocol.

​HTTPS operates at the application layer—the application performs the encryption. Internet protocol security (IPsec) is a suite of protocols that secure network communication at the network layer by encrypting and authenticating packets. IPsec handles traffic between systems transparently, without the application needing to handle encryption.

​An example of IPsec is the virtual private network (VPN). In a VPN, all network traffic is encrypted as it is sent, and is decrypted by the client as it is received. The application software is unaware that the data is ever encrypted.

​Use IPsec tools when you want to encrypt all data between two systems. Use TLS when you want to control the encryption directly from your application.

​FIPS Encryption

​With various encryption methods available, what encryption should you use? What level of encryption is good enough? To answer this question for US government applications, NIST developed the Federal Information Processing Standards (FIPS) publication, known as FIPS 140. This is currently in revision 3, so FIPS 140-3 is the latest guidance available.

​When a supplier creates a cryptographic module, that module can be tested by a FIPS testing lab to be FIPS validated. A module with this designation has been independently tested and validated to meet the requirements of FIPS 140. Validated modules are listed at the NIST Computer Science Resource Center on their Cryptographic Module Validation Program page.

​Modules may be a software cryptography library or a hardware security device. Most applications will delegate cryptographic operations to these FIPS-validated modules rather than implementing them directly in the application.

​The FIPS validation program is expensive and takes a long time. The FIPS program has not yet validated some modern, strong encryption algorithms like ChaCha20 and BLAKE2. For these reasons, many vendors building products with encryption do not create FIPS-validated modules because they can reuse FIPS validated components, or they may use algorithms that are known to be compliant with FIPS regulations. 

​The need for FIPS compliance most often comes up for users when their security teams require that they set their Windows computers to FIPS mode. In this mode, Windows can restrict applications from using non-FIPS approved algorithms through supported cryptographic APIs. Windows does not check for FIPS validation, it only checks that the encryption technique used is not non-approved under the FIPS 140 program. For example, if a program uses MD5 (an older hashing algorithm known to not be secure), Windows will block that program from running when FIPS mode is enabled.

​The CMMC program, which derives requirements from NIST SP 800-171, requires the protection of controlled unclassified information (CUI) using cryptography implemented through FIPS-validated modules. Remote access sessions are one common scenario where these requirements apply.

​LabVIEW developers will encounter encryption in two use cases: storage (data at rest) or transmission (data in transit).

​Encryption for Data at Rest

​Data at rest refers to information that is stored rather than actively being transmitted. Examples include configuration files, test results, databases, log files, calibration data, and cryptographic keys. If a malicious actor gains access to a storage device, removable media, or a copied backup file, unencrypted data may be read without needing access to the running application.

​Not all stored data requires encryption. Encryption should be considered when storing any of the following information:

• ​Customer or proprietary information
• ​Test data containing intellectual property
• ​Authentication credentials
• ​Cryptographic keys
• ​Controlled unclassified information (CUI)
• Information subject to regulatory requirements

​For many applications, operating system protections such as Windows BitLocker provide an effective first layer of defense by encrypting the entire storage device. Full-disk encryption protects data if a computer or drive is lost or stolen, but it does not prevent authorized users or applications from accessing files once the system is running. Encryption in transit does not protect data after it has been stored, and encryption at rest does not protect data while it is being transmitted. Many systems require both.

​For sensitive files, applications may need to encrypt the data itself before writing it to disk. Common approaches include the following types of encryption:

• ​Encrypting files using AES-256
• ​Encrypting database contents or database fields
• ​Encrypting exported reports and archives
• ​Encrypting backups before storing or transmitting them

​When encrypting application data, authenticated encryption algorithms such as AES-GCM should be preferred because they provide both confidentiality and integrity protection. If the encrypted file is modified, the application can detect the change when attempting to decrypt the data.

​LabVIEW Considerations for Data at Rest

​LabVIEW applications commonly store information in the following formats:

• ​TDMS files
• ​Configuration files (INI, JSON, XML)
• ​SQLite or other databases
• ​Log files
• ​Serialized data files

​These formats provide little or no native encryption. If protection is required, encrypt the data before writing it to disk or store it within an encrypted volume protected by operating system tools such as BitLocker.

​Avoid storing passwords, certificates, or cryptographic keys directly in configuration files. Use protected operating system key stores, symmetric and asymmetric, trusted platform modules (TPMs), or APIs such as CryptProtectData to protect sensitive secrets.

​Encryption for Data in Transit

​LabVIEW provides many network communication functions ranging from low-level to higher-level. Most of these functions do not currently provide encryption. Emerson engineers are currently working to add cryptography to some of these network functions, and this feature will be announced in future versions of LabVIEW.

​Table 2: LabVIEW Communication Functions

​While cryptography is not built into these functions, there are several ways to implement encryption in LabVIEW for data transmission.

Option 1: IPsec/VPN

​Enabling a VPN on both the server and client will encrypt all data transmitted between the two machines, including LabVIEW data. The LabVIEW application does not need to know anything about the VPN connection; all encryption is handled by the VPN software before delivering the data to the client.

​We recommend WireGuard as a VPN. WireGuard is free, fast, and secure. WireGuard is supported on both Windows and NI Linux RT, so it can be used to transmit data from a real-time device to a Windows system, as depicted in Figure 6. WireGuard is included in the NI Linux RT distribution.

​Figure 6: WireGuard Data Transfer

​In internal testing, we have found WireGuard to be fast and easy to configure. It requires no changes to the LabVIEW code or the rest of the system. It does require the WireGuard client to run on both the server and client, so be sure this is possible prior to designing it into your system.

​WireGuard is not FIPS validated. Other VPNs are available which are FIPS validated, if you must meet regulatory requirements that include FIPS validation.

​Option 2: Use LabVIEW functions with encryption

​Some LabVIEW functions include the ability to add encryption to data communication functions.

​If you are using gRPC to communicate data among devices or services, you can enable TLS encryption. You will need to configure TLS for the server and clients. You will need to generate an X.509 certificate for the server. For more information about using gRPC in LabVIEW, refer to How to use gRPC with NI Software and Hardware.

​If you are using the secure FTP (SFTP) function, you will need to set up a secure FTP server. The LabVIEW functions allow sending and receiving from that server. These transmissions use the SSH protocol which supports a number of encryption algorithms. The specific algorithm used depends on the configuration of the SFTP server, which you will need to install separately. For more information about using the SFTP in LabVIEW, refer to the the SFTP section of the LabVIEW Programming Reference Manual.

​None of the built-in LabVIEW functions are FIPS validated, but some of the algorithms use FIPS approved algorithms. Windows will not block these with FIPS mode enabled.

​The LabVIEW functions do not provide encryption of the data package being sent. For these cases, you will need to use one of the other options.

Option 3: Use a third-party cryptography toolkit

​Encryption Compendium for LabVIEW is available from LVS Tools and provides a full library of cryptography functions for LabVIEW. A screenshot is shown in Figure 7. This toolkit is available from the NI Tools Network or directly from LVS Tools.

​Encryption Compendium supports both symmetric and RSA asymmetric encryption. It also supports hashing and many secure protocols in LabVIEW such as TLS, DTLS, and SSH. It not only allows you to encrypt data and store it in an encrypted form, but also to transmit it securely in one of a number of protocols.

​Figure 7: Encryption Compendium Palette

​Encryption Compendium provides high-level functions to reduce the task of encryption to a single VI. For example, the symmetric encryption VI encrypts data using any encryption algorithm, as shown in Figure 8.

​Figure 8: Encryption Compendium Symmetric Encryption Function

​A single function supports decryption, as shown in the code in Figure 9.

​Figure 9: Encryption Compendium Symmetric Decryption Function

​Encryption Compendium supports a range of other cryptographic functions as well as secure protocols. The example in Figure 10 shows how to generate X.509 keys in LabVIEW.

​Figure 10: Encryption Compendium X.509 Certificate Generation

​The Encryption Compendium is not FIPS validated, but FIPS compatibility is planned for later in 2026.

​Learn more about the LVS Tools Encryption Compendium

​Option 4: Call non-LabVIEW encryption modules

​There are many cryptography modules available for general programming use that provide strong, modern cryptography. You can use these in LabVIEW with wrappers that have been made available by the LabVIEW community. They use encryption algorithms that have not been included in the FIPS 140 standards but provide as much—or more—security.

​Bouncy Castle is an open-source cryptography library that provides a range of cryptographic functions. You can generate hashes, create keys and certificates, and encrypt data, as shown in Figure 11. LabVIEW users have created open source wrappers for Bouncy Castle functions. Additionally, there is a tutorial for using these LabVIEW wrappers.

​Figure 11: Encryption and Decryption using the Cannon Controls Bouncy Castle wrappers

​Option 5: Call FIPS-validated encryption modules

​While you can’t do FIPS-validated encryption directly in LabVIEW, there are several options to use FIPS-validated modules. These modules comply with requirements to handle US government-controlled information, required for CMMC certification.

​CryptProtectData (and CryptUnprotectData) are found in the advapi32.dll. These functions can be used to store secrets such as passwords, keys, and configurations. Refer to Windows documentation for using these functions. You will need to pass your data in as a byte array. You will also need to define the DATA_BLOB structure in your LabVIEW application prior to sending the data to the function. Additionally, you will need to be familiar with passing data pointers in LabVIEW to call this function.

​BCrypt APIs are Windows APIs in bcrypt.dll. This is the primary modern cryptography API in Windows for general encryption tasks such as AES symmetrical encryption, hashing, and key derivation.

​When called correctly, these functions call into FIPS-validated algorithms for regulation compliance. 

​Keys are a critical element of a cryptographic system. If someone has keys, they have access to everything those keys protect. Sharing keys is a common method of allowing malicious actors into a protected system; losing keys is a common method of losing access to data.

​If your LabVIEW program needs to encrypt or decrypt information, you will need to handle keys. Avoid hard-coding keys into the LabVIEW VI; it is too easy for hackers to gain access. Do not store keys in a plaintext file on the PC. Never store cryptographic keys, passwords, or certificates in source code repositories—even private repositories.

​Manage Your Keys with Windows Tools

​Windows provides a way to store local keys in a secure environment. The Microsoft Secret Store is a way to securely store and retrieve keys on a local machine using PowerShell. An open source library to access the Microsoft Secret Store from LabVIEW is available at https://gitlab.com/cannontim/secret-store-api.

​You can also use the CryptProtectData function to store keys, using the call library node in LabVIEW.

​Hardware Security Module (HSM)

​In secure environments, you may need to consider an HSM. These hardware devices are dedicated, tamper-resistant devices that securely generate, store, and manage cryptographic keys while performing encryption, decryption, and digital signing operations. While HSMs may be overkill for smaller applications, these devices may be required for larger applications that need to meet regulatory requirements.

​HSMs will range from large, expensive network devices that support teams of developers to small, portable USB devices for single developers. Some may be installed internal to a computer. A trusted platform module (TPM) is a specific type of HSM used by PCs for key management for operations such as secure boot and network authentication.

​HSMs will typically have an API that allows applications like LabVIEW to access their key management functionality.

​Encryption is a foundational capability for protecting modern test and measurement systems, but it is only effective when implemented as part of a complete, well-designed security architecture. Throughout this document, we have covered not only how encryption works, but how it should be applied in real LabVIEW systems to protect data both in transit and at rest.

​At its core, encryption relies on a combination of algorithms, such as AES, RSA, and SHA, along with protocols such as TLS, SSH, and IPsec, keys, and key management practices. Each of these components plays a critical role, but the overall security of a system depends primarily on how they are combined and implemented, not on any single technology in isolation.

​LabVIEW provides engineers a graphical approach to visualize their code into functional measurement applications. With the guidance in this document, they can protect the data they generate in these applications to ensure the confidentiality and integrity of their test system.

• ​​​Simple XOR Cipher Encryption in LabVIEW
• ​FIPS 140-3: Security Requirements for Cryptographic Modules
• ​NIST Cryptographic Module Validation Program (CMVP)
• ​NIST SP 800-171 (CMMC-aligned requirements for protecting CUI)
• ​CMMC Program Overview (DoD)
• ​CryptProtectData (DPAPI)
• ​Cryptography API: Next Generation (CNG) Overview
• ​BCrypt API Reference
• ​​BCrypt API Reference (Video)
• ​Windows TLS (SChannel) Overview
• ​Encryption Compendium (NI Tools Network)
• ​Encryption Compendium (LVS Tools)
• ​Bouncy Castle LabVIEW Wrapper (community project)
• ​Microsoft Secret Store LabVIEW Wrapper (community project)
• ​WireGuard (official documentation)