Resource: Transparent Encryption¶
Note
Transparent Encryption will be released in v2.5.0 of StoredSafe
Transparent Encryption
StoredSafe Transparent Encryption handles cryptographic functions on data-in-transit. StoredSafe doesn’t store the data sent to the endpoint, so it could be viewed as encryption as a service (EaaS).
Its primary use case is to encrypt data. This relieves the burden of proper encryption/decryption from application developers and pushes the burden onto the operators of StoredSafe.
Also due to StoredSafe dynamic nature of assigning Users to Vaults, the user Alice could be assigned to vault day 1, use Transparent Encryption on arbitrary data stored outside of StoredSafe. On day 2, Alice can be removed from the Vault, and now Alice have no way of decrypting the data from step 1 even if she has access to its storage area.
Another user, Bob, can be assigned to the vault on day 3, he now can pick up the encrypted data from Alice and decrypt it using StoredSafe, without even knowing the encryption key used.
For a detailed example, see the annotated example on transparent encryption.
Data key encryption
The second way of using the transparent encryption in StoredSafe is to utilize the endpoint to create data keys.
Say that you have a 10Gb file that you want encrypt, but you don’t want to send all the data to StoredSafe for encryption.
In this case you can create a data key which can be used to locally encrypt data and you can use the same key to decrypt the data when needed.
The data key is randomly generated using StoredSafe high quality entropy, and returned in both plaintext (to be used for the encryption) and wrapped (encrypted) by a named key from a specific vault in StoredSafe.
When the local encryption is complete, the ciphertext version of the key can safely be stored on disk together with the newly encrypted data, since the cipher version of the key is wrapped (encrypted) with another (named) key that only resides in StoredSafe.
And finally, the local plaintext key used for the local encryption, can be disposed of (destroyed).
Whenever the local data needs to be decrypted, the stored ciphertext version of the key, is sent to StoredSafe for unwrapping (decryption) and the returned plaintext key can be used to decrypt the locally stored data.
With this technique, the owner of the vault where the named key exists, is in full control of who will be able to decrypt the data.
For a detailed example, see the annotated example on using datakey.
Index