Where exactly does NCache perform encryption and decryption?

NCache performs encryption and decryption strictly on the client-side within your application process. This ensures that data is already encrypted before it travels over the network and remains encrypted while at-rest on the cache server, resulting in zero server-side CPU overhead.

Is there a performance overhead when enabling encryption in NCache?

While encryption adds a minor processing layer, using AES algorithms (AES-128/192) results in minimal latency. AES-256 may introduce a negligible 10-20% throughput difference on modern CPUs, whereas legacy 3DES is significantly slower and should be avoided for performance-critical apps.

Which encryption algorithm should I choose for regulatory compliance?

For government or financial sectors requiring FIPS 140-2 validation, choose AES-FIPS 256. For standard enterprise requirements such as GDPR or PCI-DSS, standard AES-256 provides a robust 'Gold Standard' for data protection.

Can I change the encryption algorithm on an existing NCache cache?

Yes. You must stop the cache, update the provider settings in the Management Center (Advanced Settings -> Encryption), and restart. Note that existing data remains in its previous state until re-written; for a full transition, a bulk export/import is recommended.

Does NCache encryption support features like SQL queries and Tags?

Yes, NCache encryption is transparent. It supports all core features including SQL-like queries, tagging, groups, and expiration. The client-side API handles decryption automatically during retrieval, allowing these features to function seamlessly on the secured data.

Data Encryption in NCache

NCache provides an end-to-end data encryption framework that automatically encrypts sensitive data on the client side before it is transmitted and keeps it encrypted while stored in the distributed cache. This ensures data is protected both in-transit and at-rest, allowing only authorized clients with the correct cryptographic keys to decrypt and access the original information. With zero code changes and support for strong industry-standard algorithms such as AES-256, AES-FIPS, 3DES, and RSA, NCache helps secure sensitive data and meet compliance requirements like PCI-DSS, HIPAA, and GDPR.

In a distributed environment, caching systems frequently communicate over network channels to transfer data between client applications and remote cache servers. This data travels across the network and resides in the cache in a serialized form, making it vulnerable to interception and eavesdropping, man-in-the-middle, and unauthorized access attacks if it is not encrypted.

Data encryption is a core data-security mechanism in which readable plaintext information is converted into unreadable ciphertext. Only authorized clients possessing the correct cryptographic keys can decrypt the data and access the original information. In simple terms, encryption ensures that even if data is intercepted or accessed illegally, it remains unusable to unauthorized parties.

Data Encryption Workflow

When you add data to the cache, it is encrypted on the client-side using the configured Encryption algorithm and Encryption key. The encrypted data is stored in the cache, ensuring that data remains secure. Now when the encrypted data is fetched, it is retrieved from the cache and decrypted on the client-side before usage. This end-to-end Encryption approach ensures that data remains protected, both in transit and at rest, making NCache a secure solution for caching sensitive information.

Data Encryption Algorithms

An encryption algorithm is the method used to transform data into ciphertext. An algorithm uses the encryption key to alter the data in a predictable way so that, even though the encrypted data appears random, it can be turned back into plaintext by using the decryption key.

NCache supports a rich set of standardized encryption algorithms that are nearly impossible to break. This ensures that your sensitive data is really well protected.Cache supports both symmetric and asymmetric encryption algorithms that you can choose from depending on your architectural and security needs:

Triple Data Encryption Standard (3DES)
Advanced Encryption Standard (AES)
Advanced Encryption Standard - Federal Information Processing Standards (AES-FIPS)
Rivest-Shamir-Adleman (RSA)

Below are details of each algorithm and its supported variations:

Triple Data Encryption Standard (3DES)

Triple Data Encryption Standard (3DES) is a symmetric-key block cipher algorithm, which applies the DES cipher algorithm three times to each data block. Different variations of the 3DES algorithm supported by NCache are:

3DES-128: 128-bit encryption
3DES-192: 192-bit encryption

Advanced Encryption Standard (AES)

Advanced Encryption Standard (AES) is a symmetric block cipher algorithm with a block/chunk size of 128 bits. It converts these individual blocks using keys of 128, 192, and 256 bits. Once it encrypts these blocks, it joins them together to form the ciphertext. Different variations of the AES algorithm supported by NCache are:

AES-128: 128-bit encryption
AES-192: 192-bit encryption
AES-256: 256-bit encryption

Advanced Encryption Standard - Federal Information Processing Standards (AES-FIPS)

The AES specifies a FIPS-approved cryptographic algorithm that can be used to protect electronic data called Advanced Encryption Standard - Federal Information Processing Standards (AES-FIPS). Different variations of the AES-FIPS algorithm supported by NCache are:

AES-FIPS 128: 128-bit encryption
AES-FIPS 192: 192-bit encryption
AES-FIPS 256: 256-bit encryption

Security Strength Comparison between 3DES and AES

Triple Data Encryption Standard Algorithm (3DES) is a way of using DES encryption three times. But even Triple DES was proven ineffective against brute force attacks (in addition to slowing down the process substantially).

AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit, or 256-bit key, making it exponentially stronger than the 56-bit key of DES. The larger the key length, the harder it is to break.

Algorithm	Key Length (bytes)
3DES-128	16
3DES-192	24
AES-128	16
AES-192	24
AES-256	32
AES-FIPS 128	16
AES-FIPS 192	24
AES-FIPS 256	32

Asymmetric Encryption Foundations: The RSA Handshake

While symmetric encryption algorithms (like AES) use a single shared key for rapid bulk data processing, the Rivest-Shamir-Adleman (RSA) algorithm is an asymmetric cryptographic framework implemented in C#. It relies on a mathematically linked key pair:

Public Key: Distributed openly and is used exclusively to encrypt data.
Private Key: Kept strictly confidential by the generating process and is used exclusively to decrypt data.

Connection Mechanics:

Key Generation: Each independent process generates its own dynamic RSA public/private key pair during its lifecycle.
Public Key Exchange: The client process requests the server’s public key, and the server simultaneously records the client's public key.

RSA Encryption Use Cases:

Client-to-Server Authentication (Application Login): The client obtains unencrypted credentials from the application and encrypts them via the server's RSA public key. If credentials are already encrypted with a local Credential Encryption Key (CEK), the client still encrypts them using RSA and notifies the server that credentials are also CEK-encrypted.
Administrative Management (PowerShell): When PowerShell Cmdlet connects to servers for management, it uses RSA to send credentials to the server. PowerShell obtains unencrypted credentials from the user and encrypts through RSA before wire transmission.
Server-to-Server Cluster Join: When a new cache server attempts to join a cluster, it must authenticate. It uses RSA encryption to securely transmit its credentials to the receiving cluster node.
Symmetric Security Key Distribution (KEK & CEK): At connection time, the server securely distributes the Key Encryption Key (KEK) and Credential Encryption Key (CEK) to the client by encrypting them with the client's RSA public key.

Performance-wise Comparison between 3DES, AES, and RSA

Encryption/Decryption time taken by AES is relatively less than 3DES, while both algorithms consume almost the same amount of memory.
The 3DES encryption process is much slower than AES because repeating the same encryption process three times in 3DES takes some time when compared to the AES encryption process, which is much faster. RSA introduces the highest computational overhead due to complex mathematical transformations, making it best suited for secure configuration setup phases rather than continuous payload operations.
Processing Time: AES is much faster than 3DES. RSA is computationally the slowest and most resource-intensive of the group.
Memory Usage: AES and 3DES take nearly the same amount of memory. RSA requires a higher memory allocation overhead exclusively during the cryptographic key-exchange phase to handle larger key structures.

Encryption Key Management

Encryption key management in NCache involves securely handling all Encryption keys, including the Key Encryption Key (KEK), Data Encryption Key (DEK), and Credentials Encryption Key (CEK), as discussed below.

Key Encryption Key (KEK): The Key Encryption Key (KEK), based on AES 256 Encryption, secures the Data Encryption Key (DEK) by encrypting it. This key must be configured in the NCache Service configuration file on the server. To ensure consistency and security across all cache servers in a distributed environment, the same Key Encryption Key (KEK) must be used on each server.
Data Encryption Key (DEK): The Data Encryption Key (DEK) is responsible for encrypting user data before it is stored in the cache. This DEK is itself encrypted using the KEK. This approach ensures that only authorized tools or processes can retrieve and use Encryption keys.
Credentials Encryption Key (CEK): NCache encrypts the user credentials stored in the client configuration file (client.ncconf) using a Credential Encryption Key (CEK). This key must be configured in the NCache Service configuration file. Similar to KEK, the same Credentials Encryption Key (CEK) must be used on each server. This ensures consistency and secures client credentials effectively in distributed environments. RSA encryption uses the CEK whenever client credential data travels over the network.

User Credential Authentication

By utilizing RSA-based cryptographic techniques, NCache secures user credential transmission during authentication. When a management tool or client needs to authenticate these credentials, it requests the server’s RSA-256 public key. The server generates a fresh public/private key pair for each process's lifecycle. Tools and clients encrypt user credentials (like username and password) with the server’s public key before transmitting them. The server decrypts these credentials using its private key to validate the user. This process ensures that credentials remain secure during transmission and are not vulnerable to interception or misuse.

Key Exchange and Authentication Mechanisms for Management Tools

NCache employs advanced cryptographic techniques for secure key exchange and authentication for management tools, like NCache Management Center, PowerShell, etc., as discussed below.

Key Encryption Key Management

For management tools, the key exchange process involves generating an RSA-256 public/private key pair during the process's lifecycle. The tool shares its public key with the server. The server then encrypts the KEK using this public key and shares the encrypted KEK with the tool. The management tool decrypts the KEK using its private key. This RSA key pair remains valid only for the duration of the tool’s lifecycle, ensuring short-lived and secure exchanges. When User Access Control (UAC) is enabled, only authorized tools and clients are permitted to fetch the KEK from the server.

Credentials Encryption Key Management

The management tools fetch the CEK from the cache server using RSA-based secure key exchange. Similar to KEK management, the tool generates an RSA-based 256 public/private based key pair during its lifecycle. The public key is shared with the server, which encrypts the CEK using the tool’s public key and shares the encrypted CEK with the tool. The management tool then decrypts the CEK using its private key and uses it to encrypt user credentials in the client.ncconf file.

Key Exchange for Clients

Similarly, clients connect to the server and request the CEK using RSA-based secure key exchange. The server encrypts the CEK with the client’s public key, and the client decrypts it using its private key, enabling it to decrypt stored credentials in client.ncconf.

Where Encryption Occurs in NCache

NCache data encryption and decryption mostly occur inside your application process. If encryption is enabled for a cache, NCache stores data in the cache in encrypted form.

Once encryption is enabled, the NCache client automatically encrypts your objects before sending them to the cache. And it automatically decrypts objects fetched from the cache, before delivering them to your application. When encryption is enabled, data being added using Cache API, Cache Startup Loader, and Read-through provider is encrypted.

You can enable encryption through the NCache Management Center without any programming effort on your part. To learn how to enable encryption, see Configure Encryption.