On 2018-03-07, petern_AT_riseup.net <petern_AT_riseup.net> wrote:
> On 2018-03-07 00:23, Michael Forney wrote:
>> Another related project I've been following is https://monocypher.org/
>>
>> It has a quite permissive license and encourages inlining the source
>> like you want.
>
> Hi Michael,
>
> thanks, this looks really nice and small. I'm doing my homework reading
> crypto 101 and getting to know what do I actually need for proper
> encryption. It would seem that I'll be fine with a symmetric-key algo
> and I'll have to encrypt the secret key using a master password. I see
> xchacha20 in monocypher but I have to yet read up if it is safe to use
> with a single key, i.e. encrypting n passwords with the same secret key.
I'm no expert either (so follow this at your own risk), but I also did
some investigation, and I think either of the following schemes would
work:
(1)
Setup:
- Generate a random salt and store somewhere safe.
Encryption:
- Read the salt from its location and the master password from the
console. Use those to generate a key with crypto_argon2i.
- Read password from the console (or generate randomly) and encrypt it
with the key and a randomly generated nonce using crypto_lock.
- Write the mac, nonce, and encrypted password to a file.
Decryption:
- Read the salt from its location and the master password from the
console. Use those to generate a key with crypto_argon2i.
- Read the mac, nonce, and encrypted password from the file.
- Decrypt the password using the mac, nonce, and key using crypto_unlock.
It's not clear to me if it's okay to use the plain crypto_argon2i with
just a fixed secret salt. A related scheme might be to use
crypto_argon2i_general with a salt generated for each encryption and a
single saved key. Then, the salts could be stored as plain text the
output file (and probably authenticated with crypto_lock_aead).
Perhaps one benefit is if someone somehow figured out the encryption
key for one password, they still wouldn't be able to decrypt the
others.
(2)
Setup:
- Generate a random salt.
- Read a master password from the console and generate a master key
from it and the salt using crypto_argon2i.
- Use crypto_key_exchange_public_key to compute the master public key
from the secret key.
- Save the salt and the master public key somewhere safe.
Encryption:
- Read the master public key from its location.
- Randomly generate a single-use key, and compute a shared key from it
and the master public key using crypto_key_exchange.
- Compute the single-use public key using crypto_key_exchange_public_key.
- Read password from the console (or generate randomly) and encrypt it
with this shared key, a randomly generated nonce, and the single-use
public key as additional data using crypto_lock_aead.
- Write the mac, nonce, single-use public key, and encrypted password to a file.
Decryption:
- Read the salt from its location.
- Read a master password from the console and compute the master key
from it and the salt using crypto_argon2i.
- Read the mac, nonce, single-use public key, and encrypted password
from the file.
- Compute the shared key from the single-use public key and the master key.
- Decrypt the password using the mac, nonce, single-use public key,
and shared key using crypto_unlock_aead.
For (2) I'm not sure if the nonce is necessary or not, since passwords
are encrypted with randomly generated single-use keys (so maybe a
fixed value is sufficient; it is still only used once per key).
The main differences are that (1) requires the master password for
every encryption, but not setup, and (2) requires the master password
only for setup. I think (2) is more similar to how gpg works.
Perhaps somebody who knows more about these crypto primitives could
point out any flaws with these schemes.
Received on Thu Mar 08 2018 - 20:10:09 CET