Skip to content

Latest commit

 

History

History
58 lines (29 loc) · 4.43 KB

applications.md

File metadata and controls

58 lines (29 loc) · 4.43 KB
Raw

miniLock

miniLock is an encryption software that enables user to use only a passphrase and email as a portable basis for a persistent public key identity. It uses a Javascript port of TweetNaCl library. TweetNaCl is a tiny library which fits in 100 tweets, but supports all NaCl functions. NaCl is an easy-to-use crypto library, see crypto_libraries.md for more.

Deriving keys

miniLock forces you to choose a passphrase (as password, but longer) with at least 100 bits of entropy. The passphrase is then hashed using BLAKE2 and passed to scrypt (email is used as a salt, see crypto_libraries.md for slightly more info about scrypt). The 32-byte output of scrypt is used as a private key. The public key is then derived by TweetNaCl curve25519-xsalsa20-poly1305 contruction.

key derivation

Encryption / decryption of a file

This is actually only a simplified sketch about how a sender is anonymized.

For each file a random fileKey and fileNonce are generated and used to symmetrically encrypt the file (TweetNaCL's xsalsa20-poly1305 is used). Ephemeral key pair is created which is used to anonymize the sender's ID (public key).

A fileInfo (containing fileKey) is encrypted directly with persistent keys (sender's private key and receiver's public key). A decryptInfo is then prepared - it contains sender's ID, recipient's ID, and encrypted fileInfo.

A decryptInfo is encrypted using the ephemeral key (receiver's public key and ephemeral private key). Besides encrypted decryptInfo, sender sends also public part of ephemeral key in the clear.

fileKey encryption

ephemeral encryption

So, the sender's public key (sender's ID which is included in decryptInfo) is needed to decrypt fileInfo.

Sender is anonymous until the receiver decrypts decryptInfo with the ephemeral public key and his private key as depicted below:

ephemeral decryption

At this point the receiver has sender's ID (public key) and can decrypt the fileInfo using sender's public key and his private key:

fileKey decryption

However, later on the sender cannot decrypt the message because he does not store the ephemeral private key (while the ephemeral public key is always available in the header of the binary blob of encrypted file).

Crypton

Crypton uses Secure Remote Password (SRP) for proving that a user knows a password.

When a user registers an Account object is created on the client side which contains key material (more is described below), SRP verifier (derivated from the password) and SRP salt. An Account (keys are encrypted) is sent to the Crypton server and stored there (note that instead of storing the password or its equivalent like hash, the SRP verifier and salt are stored).

When a user logins a SRP authentication takes place - if successful the server sends an Account object to the Crypton client Javascript library. The client library prepares a Session object which stores the Account object.

When creating an Account three keys are generated with sjcl.misch.pbkdf2 (password based key derivation function) using password and three different salts (each salt is generated using sjcl.random.randomWords):

  • keypairKey: used to encrypt a key named keypair. Key keypair is a master key and is generated using sjcl.ecc.elGamal.generateKeys. Key keypair is used to encrypt session keys - each file (Container in Crypton) is encrypted with its own session key. When a user A wants to share a file (Container) with user B, A encrypts session key with B's public part of keypair.

  • Key keypairMacKey is used to verify the integrity of the keypair after it is retrieved from Crypton (via Account) and decrypted using keypairKey.

  • Key signKeyPrivateMacKey is used to verify signingKeys which is generated by sjcl.ecc.ecdsa.generateKeys and used to sign the Container ciphertexts.

The two keys keypair and signingKeys are encrypted using keypairKey.