Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update architecture.rst #50

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update architecture.rst #50

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c6ce6d1
Update architecture.rst
ho-oto Jan 10, 2024
a69b221
Update architecture.rst
ho-oto Jan 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions source/security/architecture.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.


Expand All @@ -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 <https://docs.oracle.com/javase/8/docs/api/java/security/SecureRandom.html>`_ with SHA1PRNG, seeded with 440 bits from ``SecureRandom.getInstanceStrong()``.

Both keys are encrypted using `RFC 3394 <https://tools.ietf.org/html/rfc3394>`_ key wrapping with a :abbr:`KEK (Key-encryption key)` derived from the user's password using `scrypt <https://tools.ietf.org/html/rfc7914>`_.
Both keys are encrypted using `RFC 3394 <https://tools.ietf.org/html/rfc3394>`_ key wrapping with 32 bytes :abbr:`KEK (Key-encryption key)` derived from the user's password using `scrypt <https://tools.ietf.org/html/rfc7914>`_ (non-parallel).

.. code-block:: console

Expand Down Expand Up @@ -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.
Expand All @@ -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
}
Expand Down