summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authordrebs <drebs@riseup.net>2017-11-03 11:11:28 -0200
committerdrebs <drebs@riseup.net>2017-11-03 11:11:28 -0200
commit2aced0817393b1ed26e0704b0a50f6de41c76d6a (patch)
tree5489fdef96b865a8f6f6369f496c5fd3ba98602d
parentc3c1721b8e0f614a7333dc1ce8a8f5a5c196480e (diff)
[doc] move blobs data structure info to blobs sync section
-rw-r--r--docs/reference/blobs/client.rst29
-rw-r--r--docs/reference/blobs/sync.rst33
2 files changed, 28 insertions, 34 deletions
diff --git a/docs/reference/blobs/client.rst b/docs/reference/blobs/client.rst
index 5d9369f3..8c1e4154 100644
--- a/docs/reference/blobs/client.rst
+++ b/docs/reference/blobs/client.rst
@@ -14,35 +14,6 @@ called ``{uuid}_blobs.db`` that lies in the same directory as the Soledad
Client's JSON documents database (see :ref:`client-databases`). All actions
performed locally are mirrored remotelly using the :ref:`blobs-http-api`.
-Client-side encryption and authentication
------------------------------------------
-
-When uploading, the content of the blob is encrypted with a symmetric secret
-prior to being sent to the server. When downloading, the content of the blob is
-decrypted accordingly. See :ref:`client-encryption` for more details.
-
-When a blob is uploaded by a client, a preamble is created and prepended to the
-encrypted content. The preamble is an encoded struct that contains the
-following metadata:
-
-- A 2 character **magic hexadecimal number** for easy identification of a Blob
- data type. Currently, the value used for the magic number is: ``\x13\x37``.
-- The **cryptographic scheme** used for encryption. Currently, the only valid
- schemes are ``symkey`` and ``external``.
-- The **encryption method** used. Currently, the only valid methods are
- ``aes_256_gcm`` and ``pgp``.
-- The **initialization vector**.
-- The **blob_id**.
-- The **revision**, which is a fixed value (``ImmutableRev``) in the case of
- blobs.
-- The **size** of the blob.
-
-The final format of a blob that is uploaded to the server is the following:
-
-- The URL-safe base64-encoded **preamble** (see above).
-- A space to act as a **separator**.
-- The URL-safe base64-encoded concatenated **encrypted data and MAC tag**.
-
Namespaces
----------
diff --git a/docs/reference/blobs/sync.rst b/docs/reference/blobs/sync.rst
index 93fb7cb0..6c80c8f7 100644
--- a/docs/reference/blobs/sync.rst
+++ b/docs/reference/blobs/sync.rst
@@ -15,12 +15,35 @@ Immutability brings some characteristics to the blobs system:
- There's no need for storage of versions or revisions.
- Updating is not possible (you would need to delete and recreate a blob).
-Client-side encryption
-----------------------
+Client-side encryption and authentication
+-----------------------------------------
+
+When uploading, the content of the blob is encrypted with a symmetric secret
+prior to being sent to the server. When downloading, the content of the blob is
+decrypted accordingly. See :ref:`client-encryption` for more details.
+
+When a blob is uploaded by a client, a preamble is created and prepended to the
+encrypted content. The preamble is an encoded struct that contains the
+following metadata:
+
+- A 2 character **magic hexadecimal number** for easy identification of a Blob
+ data type. Currently, the value used for the magic number is: ``\x13\x37``.
+- The **cryptographic scheme** used for encryption. Currently, the only valid
+ schemes are ``symkey`` and ``external``.
+- The **encryption method** used. Currently, the only valid methods are
+ ``aes_256_gcm`` and ``pgp``.
+- The **initialization vector**.
+- The **blob_id**.
+- The **revision**, which is a fixed value (``ImmutableRev``) in the case of
+ blobs.
+- The **size** of the blob.
+
+The final format of a blob that is uploaded to the server is the following:
+
+- The URL-safe base64-encoded **preamble** (see above).
+- A space to act as a **separator**.
+- The URL-safe base64-encoded concatenated **encrypted data and MAC tag**.
-Blobs are encrypted before being sent to the server and decrypted after being
-received. A MAC is also calculated to authenticate the contents of each blob.
-See :ref:`client-encryption` for more details of how this is done.
Synchronization status
----------------------