# HG changeset patch # User Alain Mazy # Date 1593774149 -7200 # Node ID aef5c8b743819742ca75a6075b3a5f0433f68981 # Parent 9382061104839ddda52f66f7b1c55d3e524eca7a fix + link to sample diff -r 938206110483 -r aef5c8b74381 Sphinx/source/plugins/object-storage.rst --- a/Sphinx/source/plugins/object-storage.rst Fri Jul 03 12:52:11 2020 +0200 +++ b/Sphinx/source/plugins/object-storage.rst Fri Jul 03 13:02:29 2020 +0200 @@ -134,6 +134,12 @@ } +Sample setups +------------- + +You'll find sample deployments and more info in the `Orthanc Setup Samples repository `__ . + + Client-side encryption ---------------------- @@ -177,16 +183,16 @@ Orthanc saves 2 kind of files: DICOM files and JSON summaries of DICOM files. Both files contain PHI. -When configuring the plugin, you'll have to provide a `Master Key` that we can also call the `Key Encryption Key` (KEK). +When configuring the plugin, you'll have to provide a **Master Key** that we can also call the **Key Encryption Key (KEK)**. -For each file being saved, the plugin will generate a new `Data Encryption Key` (DEK). This DEK, encrypted with the KEK will be pre-pended to the file. +For each file being saved, the plugin will generate a new **Data Encryption Key (DEK)**. This DEK, encrypted with the KEK will be pre-pended to the file. If, at any point, your KEK leaks or you want to rotate your KEKs, you'll be able to use a new one to encrypt new files that are being added and still use the old ones to decrypt data. You could then eventually start a side script to remove usages of the leaked/obsolete KEKs. To summarize: -- We use `Crypto++`__ to perform all encryptions. +- We use `Crypto++ `__ to perform all encryptions. - All keys (KEK and DEK) are AES-256 keys. - DEKs and IVs are encrypted by KEK using CTR block cipher using a null IV. - data is encrypted by DEK using GCM block cipher that will also perform integrity check on the whole file.