Confidencial utilizes multi-receiver hybrid-encryption to (selectively) encrypt data in documents and other content forms. In hybrid encryption, one encrypts the data with a symmetric encryption scheme (e.g., AES) using a randomly generated key. One then encrypts this random symmetric-key with the receivers’ public-key. Confidencial utilizes AES-256-GCM (as the symmetric encryption scheme) to encrypt the actual data. The randomly generated AES key is then encrypted via the public-key of the receivers. We are currently utilizing RSA-OAEP with 2048 bits, but this is a configurable parameter and will be upgraded in 2023. The use of the RSA-OAEP is just as a public key encryption scheme and does not depend on any specifics of the internals of the RSA algorithm (what is called black-box use of the encryption scheme). Any other suitable public-key encryption scheme can be used instead of RSA.

Confidencial utilizes patented multi-receiver hybrid-encryption to (selectively) encrypt data in documents and other content forms. In hybrid encryption, one encrypts the data with a symmetric encryption scheme (e.g., AES) using a randomly generated key. One then encrypts this random symmetric-key with the receivers’ public-key. Confidencial utilizes AES-256-GCM (as the symmetric encryption scheme) to encrypt the actual data; AES-256 is considered post-quantum secure. The randomly generated AES key is then encrypted via the public-key of the receivers. We are currently utilizing RSA-OAEP with 2048 bits, but this is a configurable parameter and will be upgraded in 2023. The use of the RSA-OAEP is just as a public key encryption scheme and does not depend on any specifics of the internals of the RSA algorithm (what is called black-box use of the encryption scheme). Any other suitable public-key encryption scheme can be used instead of RSA. Once the NIST PQC standards are finalized, one would be able to replace RSA with post-quantum encryption schemes.

No. Confidencial does not store nor receive any user documents. Users encrypt the documents and store them as they normally would. They then send them to their intended recipients via email, web upload, (S)FTP, Slack, cloud storage, or any other communication or storage method of choice.

Yes. Confidencial is planning to apply for SOC2 (System and Organization Controls) compliance by end of 2023.

No, there is no need to install one add-in for Word then install the add-in again for Excel. Simply install one add-in and start using Confidencial's document protection capabilities in both Word and Excel.

No. If an enterprise administrator creates an enterprise/organization account on Confidencial, they can enroll users in their enterprise using its Active Directory (AD) accounts into Confidencial. This is accomplished by creating a connection between Confidencial and the organization's AD to redirect signup requests to AD. However, this option is not available if users are enrolled in the public space via individual accounts.

Yes. The encryption experience is the same for users inside and outside your organization. This is assuming that your organization's administrator allows users inside it to encrypt to users outside the organization (whether to users registered in other organizations or registered in the public space using individual accounts).

Yes. You can utilize Confidencial’s escrowed key service and generate one-time-use keys that are utilized to encrypt documents to unregistered users. This happens automatically when you encrypt to an unregistered user. You can then send the encrypted documents to the users via email, Slack, cloud storage, or any other method of choice. Confidencial does not obtain the encrypted documents. When the intended user receives the document (or email) they are redirected to Confidencial to register and install the add-ins and the documents will then be decrypted automatically. In the future any encryption to the new users will use their long-term privately generated keys which will be generated when they complete their registration.

The Confidencial platform is flexible and can accommodate multiple secure key storage options depending on customer needs. In all cases, user’s decryption/private keys are always stored in a secure distributed manner and never stored in the clear in a single database or server. The most common key storage options are: Organizational Accounts: In an organizational account, the private keys can be stored in a local or cloud-based database or Key Management Server (KMS) managed by the organization. Another option is to deploy a Key Share Server (KSS) supplied by Confidencial which stored secret share (shard) of a user’s key. The other secret share (shard) of a user’s key is stored in another KSS hosted in Confidencial’s cloud. In this setting, even if an organization’s KSS is compromised or breached, no user keys are leaked. The same applies if Confidencial’s infrastructure or backend is compromised. This setup mathematically guarantees that no information about the private keys is revealed is breaches occur. This deployment setup provides a high-level of protection and is recommended by Confidencial. Individual Accounts: If desired, users can locally generate and store private keys. In this case, the user must load the key when they log into the Confidencial add-ins, or desktop or mobile apps. If users prefer simplicity, they can store their keys in a secure distributed form, namely password protected and secret shared form in Confidencial’s cloud platform. The keys are automatically retrieved when the user logs into the add-ins, or desktop or mobile apps with their correct username and password. The keys are then deleted from local memory and storage once the user logs out. We stress that Confidencial does not obtain any documents encrypted by the users, and because of this the keys stored in Confidencial will not be useful. And, again, if the user does not trust Confidencial with their private key, they can always store it locally.