summaryrefslogtreecommitdiff
path: root/pages/features/cryptography/en.text
diff options
context:
space:
mode:
Diffstat (limited to 'pages/features/cryptography/en.text')
-rw-r--r--pages/features/cryptography/en.text66
1 files changed, 0 insertions, 66 deletions
diff --git a/pages/features/cryptography/en.text b/pages/features/cryptography/en.text
index 7cc32f4..c1c89f5 100644
--- a/pages/features/cryptography/en.text
+++ b/pages/features/cryptography/en.text
@@ -41,44 +41,6 @@ The provider-specific CA certificates use 4096 bit RSA with SHA256 digest, by de
All TLS connections use PFS ciphers.
-h2. Storage - Soledad
-
-The Bitmask application stores its data in [[Soledad => https://leap.se/soledad]], which handles encrypting this data, securely backing it up, and synchronizing it among a user's devices. In Soledad, local storage uses symmetric block encryption of the entire database using a single key. For data stored remotely, each individual document is separately encrypted using a key unique to that document.
-
-Both local storage and remote storage keys are derived from a master "storage secret." This long random storage secret is stored locally on disk, protected by symmetric encryption using a key derived from the user's password (scrypt is used as the key derivation function).
-
-Currently, our scrypt parameters are:
-
-bc. N (CPU/memory cost parameter) = 2^14 = 16384
-p (paralelization parameter) = 1
-r (length of block mixed by SMix()) = 8
-dkLen (length of derived key) = 32 bytes = 256 bits
-
-We are considering using a larger N.
-
-*Local storage*
-
-p((. The block-encrypted local SQLite database uses @AES-256-CBC@ using the first 256 bits of [@storage_secret@]. See https://github.com/kalikaneko/python-u1dbcipher and http://sqlcipher.net.
-
-*Remote storage*
-
-p((. Per-document encryption of documents stored remotely uses symmetric encryption with AES-256-CTR or XSalsa20 cipher using 256 bit keys. The library pycryptopp is used for this. The key and MAC used to encrypt each individual document are derived as follows:
-
-<pre style="margin-left: 2em">
-storage_secret_a = first 256 bits of storage secret
-storage_secret_b = everything after first 256 bits of storage secret
-document_key = hmac(document_id, storage_secret_b)
-document_mac = hmac(document_id | document_revision | iv | ciphertext, hmac(document_id, storage_secret_a)
-</pre>
-
-p((. Every document has its own key. The [@document_revision@] in the document MAC prevents a rollback to an old version of the document. HMAC uses SHA256.
-
-p((. Some documents in a user's remote data store are added by the provider, such as in the case of new incoming email. These documents use asymmetric encryption, with each document encrypted using the user's OpenPGP public key. The library we use for this is [[Isis's fork of python-gnupg => https://github.com/isislovecruft/python-gnupg]]. These documents are only temporarily stored this way: as soon as the client sees them, they get unencrypted and re-encrypted using the other methods.
-
-*Transport*
-
-p((. TLS, as above. Soon to be CurveZMQ.
-
h2. Encrypted Tunnel - OpenVPN
OpenVPN has three settings that control what ciphers it uses (there is a fourth, @--tls-auth@, but we cannot use this in a public multi-user environment). Every provider can easily choose whatever options they want for these. Below are the current defaults that come with the leap_platform.
@@ -116,36 +78,8 @@ Obfsproxy is optionally used to make VPN traffic not appear as VPN traffic to so
We have chosen the Scramblesuit pluggable transport that uses Uniform Diffie-Hellman for the initial handshake and AES-CTR 256 for application data.
-h2. Encrypted Email - OpenPGP
-
-The user's autogenerated key pair uses 4096 bit RSA for the master signing key.
-
-Bitmask will refuse to encrypt to a recipient's public key if the length is 1024 or less.
-
-All keys are stored in Soledad.
-
-Bitmask does not yet support ECC keys.
-
-Bitmask uses GnuPG. The python library we use is [[Isis's fork of python-gnupg => https://github.com/isislovecruft/python-gnupg]].
-
-h2. Secure Updates - TUF
-
-The secure updates are done using [[TUF => http://theupdateframework.com/]], they use OpenSSL 4096 RSA keys with pyCrypto. There is three keys involved in the update process (root, targets and timestamp).
-
-* The root key is used to certify the rest of the keys that lives in an offline storage and only gets used once per year to update the certification or in case of rotation of another other key.
-* The targets key is used to sign all the updates. This key is in the hands of the release manager and used on every release.
-* The timestamp key is used to sing a timestamp file every day, this file is used by the client to prevent an adversary from replaying an out-of-date updates. This key lives online in the platform servers.
-
h2. Other
h3. OpenSSH
By default, all servers use RSA key host keys instead of ECDSA. If a host has a ECDSA key, the platform will prompt the sysadmin to switch to RSA. In the future, when Curve255219 is better supported, the platform will encourage switching to 25519.
-
-h3. DNSSec
-
-To be written
-
-h3. StartTLS + DANE
-
-To be written