From c6ce6d162dd105c94b64bafe9ddbfb7d57760615 Mon Sep 17 00:00:00 2001 From: ho-oto <22756928+ho-oto@users.noreply.github.com> Date: Wed, 10 Jan 2024 19:08:29 +0900 Subject: [PATCH 1/2] Update architecture.rst --- source/security/architecture.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/source/security/architecture.rst b/source/security/architecture.rst index b56b023..7d5e788 100644 --- a/source/security/architecture.rst +++ b/source/security/architecture.rst @@ -26,7 +26,7 @@ Vault Configuration Every vault must have a vault configuration file named ``vault.cryptomator`` in the root directory of the vault. It is a JWT containing basic information about the vault and specification what key to use. -The JWT is signed using the 512 bit raw masterkey. +The JWT is signed using the 512 bit raw masterkey (). This is an example of an encoded vault configuration file: @@ -59,7 +59,7 @@ When opening a vault, the following steps have to be followed: #. Decode ``vault.cryptomator`` without verification. #. Read ``kid`` header and, depending on its value, retrieve the masterkey from the specified location. -#. Verify the JWT signature using the masterkey. +#. Verify the JWT signature using the concatenation of encryption masterkey and MAC masterkey. #. Make sure ``format`` and ``cipherCombo`` are supported. @@ -73,7 +73,7 @@ Each vault has its own 256 bit encryption as well as MAC masterkey used for encr These keys are random sequences generated by a :abbr:`CSPRNG (Cryptographically secure pseudorandom number generator)`. We use `SecureRandom `_ with SHA1PRNG, seeded with 440 bits from ``SecureRandom.getInstanceStrong()``. -Both keys are encrypted using `RFC 3394 `_ key wrapping with a :abbr:`KEK (Key-encryption key)` derived from the user's password using `scrypt `_. +Both keys are encrypted using `RFC 3394 `_ key wrapping with 32 bytes :abbr:`KEK (Key-encryption key)` derived from the user's password using `scrypt `_ (non-parallel). .. code-block:: console @@ -158,7 +158,7 @@ The cleartext is broken down into multiple chunks, each up to 32 KiB + 28 bytes * up to 32 KiB encrypted payload using AES-GCM with the file content key, and * 16 bytes tag computed by GCM with the following AAD: - * chunk number as 32 bit big endian integer (to prevent undetected reordering), + * chunk number as 64 bit big endian integer (to prevent undetected reordering), * file header nonce (to bind this chunk to the file header), Afterwards, the encrypted chunks are joined preserving the order of the cleartext chunks. @@ -169,7 +169,7 @@ The payload of the last chunk may be smaller than 32 KiB. cleartextChunks[] := split(cleartext, 32KiB) for (int i = 0; i < length(cleartextChunks); i++) { chunkNonce := createRandomBytes(12) - aad := [bigEndian(i), headerNonce] + aad := bigEndian(i) . headerNonce ciphertextPayload, tag := aesGcm(cleartextChunks[i], contentKey, chunkNonce, aad) ciphertextChunks[i] := chunkNonce . ciphertextPayload . tag } From a69b2218b46a4270c0be08d16642eed5552144cf Mon Sep 17 00:00:00 2001 From: ho-oto <22756928+ho-oto@users.noreply.github.com> Date: Wed, 10 Jan 2024 19:11:31 +0900 Subject: [PATCH 2/2] Update architecture.rst --- source/security/architecture.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/security/architecture.rst b/source/security/architecture.rst index 7d5e788..6770d90 100644 --- a/source/security/architecture.rst +++ b/source/security/architecture.rst @@ -26,7 +26,7 @@ Vault Configuration Every vault must have a vault configuration file named ``vault.cryptomator`` in the root directory of the vault. It is a JWT containing basic information about the vault and specification what key to use. -The JWT is signed using the 512 bit raw masterkey (). +The JWT is signed using the 512 bit raw masterkey. This is an example of an encoded vault configuration file: