updated crypto details to reflect changes and additional details

1 files changed, 23 insertions, 10 deletions

diff --git a/pages/features/cryptography/en.text b/pages/features/cryptography/en.text
index f2500fb..5c077c6 100644
--- a/pages/features/cryptography/en.text
+++ b/pages/features/cryptography/en.text
@@ -9,6 +9,8 @@ Bitmask uses Secure Remote Password (SRP) to authenticate with a service provide
 
 One additional benefit of SRP is that both parties authenticate each other. With traditional hashed passwords, the server can say that the password was correct, even if it has no idea what the real password is. With SRP, the user authenticates with the server, but the server also authenticates with the user.
 
+Currently we use 1024-bit discrete-log parameters. We are exploring increasing this to 2048-bit.
+
 There are some limitations with SRP. A compromised or nefarious provider can attempt to brute force crack a password by trying millions of combinations, just like with normal hashed passwords. For this reason, it is still important to pick a strong password. In practice, however, users are horrible at picking strong passwords.
 
 A second limitation is with the web application. It also uses SRP, but the SRP javascript code is loaded from the provider. If the provider is compromised or nefarious, they could load some javascript to capture the user's password.
@@ -37,7 +39,7 @@ All subsequent connections with that provider use the provider-specific CA to au
 
 If a provider has been pre-seeded with the Bitmask application, then the fingerprint of the provider-specific CA certificate is known in advance. In these cases, the x.509 CA system is never relied upon.
 
-The provider-specific CA certificates use 4096 bit RSA with SHA256 digest, by default. The server certificates use 2048 bit RSA with SHA256 digest, by default. These defaults are easily changed.
+The provider-specific CA certificates use 4096 bit RSA with SHA256 digest, by default. The server certificates use 4096 bit RSA with SHA256 digest, by default. These defaults are easily changed.
 
 All TLS connections use PFS ciphers.
 
@@ -47,17 +49,29 @@ The Bitmask application stores its data in [[Soledad => https://leap.se/soledad]
 
 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).
 
-*Local storage*
+Currently, our scrypt parameters are:
 
-p((. The block-encrypted local SQLite database uses @AES-256-CBC@. See https://github.com/kalikaneko/python-u1dbcipher and http://sqlcipher.net.
+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
 
-<!-- p((. The key size is ??? -->
+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 a AES-256-CTR cipher. The library pycryptopp is used for this.
+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:
+
+bc. 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)
 
-<!-- p((. The key for each document is X bits in length, and is derived from X. -->
+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.
 
@@ -82,7 +96,7 @@ Another New AES Attack => https://www.schneier.com/blog/archives/2009/07/another
 
 p((. We would prefer to use ECC over RSA, and plan to eventually. It is a bit more complicated and involves changes to our TLS code in many places (recompiling openvpn, and changing certificate generation libraries used by sysadmins and the provider API).
 
-p((. The current default for client and server x.509 certificates used by OpenVPN is 2048 RSA with SHA256 digest. At this time, we feel there is no evidence to support the use of larger key sizes, which would dramatically slow down the connection time. This is also easily configurable by the provider (to see all the options, run @leap inspect provider.json@).
+p((. The current default for client and server x.509 certificates used by OpenVPN is 2048 bit RSA and 4096 bit RSA (respectively) with SHA256 digest. This is also easily configurable by the provider (to see all the options, run @leap inspect provider.json@).
 
 *auth*
 
@@ -104,7 +118,7 @@ We have chosen the Scramblesuit pluggable transport that uses Uniform Diffie-Hel
 
 h2. Encrypted Email - OpenPGP
 
-The user's autogenerated key pair uses 4096 RSA for the master signing key.
+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.
 
@@ -126,7 +140,7 @@ h2. Other
 
 h3. OpenSSH
 
-Servers use ecdsa keys.
+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
 
@@ -135,4 +149,3 @@ To be written
 h3. StartTLS + DANE
 
 To be written
-