Update links in Apertis Release Process

As currently the infrastructure repository uses only a master branch update the links accordingly.

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.