Virtru’s encryption complies with FIPS 140-2, but not always by default. Customers should make sure to request Virtru with FIPS mode enabled to ensure FIPS 140-2 compliance across all Virtru platforms.
We use 3rd party AES-256 encryption libraries that have been certified by or for companies such as Google, Apple and Microsoft (more details below). As such, Virtru has not been required to go through a validation directly.
The Certificates for the certified Cryptographic Libraries are all listed here. The certificate numbers in question depend on platform and are listed below:
– # 1329 – Outlook for Desktop – Windows 7
– # 2357 – Outlook for Desktop – Windows 8
– # 2021 – iOS
– # 1747 – Android, Chrome*
*Upon request, we can enable FIPS mode in Virtru’s Chrome extension, but that platform does not use a FIPS module by default today.
The strength of an encryption tool depends on the length of the keys used to encrypt the data being shared. Encryption keys are measured commonly used computing units called bits. The more bits in a key, the more difficult it is to guess, and thus the safer the encrypted data is from hackers.
AES 256-bit encryption refers to the length of Virtru’s keys, which meets or exceeds most requirements.
Perfect Forward Secrecy (PFS) provides stronger security by ensuring that the session’s establishment keys are ephemeral. In other words, PFS ensures that an attacker cannot decrypt past messages if the user’s private key is lost.
Customers manage their own keys, which are stored in IBM facilities in Virginia and Oregon. Authentication services are run in AWS data centers in both East and West Coast of the US.
For customers who want to host encryption keys on on their own premises or in the cloud environment of their choice, contact email@example.com about the Virtru Customer Key Server.
Client-side encryption protects a message the moment someone composes it, and it ensures that only the sender and recipient can decrypt the message to view the plain-text content.
Point-to-point encryption, or transport level security (TLS), provides an encrypted pipe through which messages can be transmitted. Unlike client-side encryption, TLS does not encrypt the actual message at rest. Instead, it ensures that unencrypted content is secure when travelling between mail servers. As a result, mail providers typically have access to the unencrypted messages that reach them throughout this process.
In order for TLS to work, both the sender and recipient’s email system must have TLS enabled. If the recipient’s server does not support TLS, the communication will not be allowed. This means the email will not reach its intended recipient.
Given these circumstances, and the fact that some on-premise email platforms do not support TLS, client-side encryption is the only way to ensure that content will be secure no matter where it travels.
Activation emails contain an authentication code that allows the key server to ensure only those users with authenticated access to the inbox may read the encrypted message. The activation emails do not contain encrypted content or encryption keys.