encrypted-updates: Add encryption parameters

Target devices with limited computing power(such as a single core, or just
a little bit of RAM) may fail or need a long time to open encrypted files
that were not created for small devices. This patch adds documentation
that explain how to create encrypted files that are suitable for small
devices.

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

content/architecture/encrypted-updates.md

@@ -117,3 +117,13 @@ New keys should be generated:
 ## How to handle the leak of a key to the public and how that impacts future updates
   - If the keys are stored on the filesystem, the leak of one key implies the leak of the others
   - If the keys are stored using the secure-boot-verified key storage system, the next update should be signed with a key that hasn't been leaked and the update should revoke the leaked key
+
+# Encryption Parameters
+
+In a classical usage, the encryption is setup through a benchmark on the computer/board which will use it, allowing a good balance between password strength and unlocking time. This could end-up by encrypted file not usable due to out of memory error or slow unlocking time.
+
+LUKS key strength is managed through 3 `cryptsetup` parameters: `--pbkdf-memory`, `--pbkdf-force-iterations` and `--pbkdf-parallel`.
+
+`--pbkdf-parallel` configures the maximun number of threads used to unlock the encrypted file. This is automatically decreased on hardware devices that have only one of just a few cores.
+
+As encrypted update file is created during image build on computer with more CPU power and memory, and that it is important to find a balance between password strength and usability, the `--pbkdf-memory` and `--pbkdf-force-iterations` should be forced to appropriate values for the target board.