In order to implement a plaintext password file safe (keyring), while adhering to best Crypto practices today, I came up with this scheme:

  • A user's master password is hashed with Argon2 (\$argon2id\$v=19\$m=65536,t=15,p=2)
  • Hash is used as key for encrypting auxiliary plain text passwords with AES 128 GCM
  • The public plaintext password values (called service and username) are authenticated (providing them as associated data for GCM)

The resulting data structure looks like this

(for breverity, the base64 encoded json value is decoded here):

username = {"nonce": "CusUx2wp0pHzPAqEaRsKAw==", 
            "mac": "kStM+2I4+L5Jy3fl13BVYQ==", 
            "data": "UK9Txr4aEY1Yd1FQKApbpK2aFzdbKLCfgffF", 
            "salt": "1ACl3k9CWQ9sXKdqVAQlew=="}


Somebody suggested to additionally authenticate nonce and salt? Does this make sense, since all values together constitute the input for a successful decryption anyway? (nonce is the GCM nonce, mac the GCM MAC, data the encrypted payload, salt is used for Argon2, mac contains service and username as associated public data)

In my humble believe, this adheres to todays best practices already. Am I missing something?

What are the downsides of NOT authenticating the number of records? For now, I like the fact, that these files can be edited manually (e.g. records can be added and removed, since each record is still tamper resistent in itself). Am I missing something?

  • $\begingroup$ The nonce is automatically authenticated with GCM. As for the salt: Generally you want as much context to your message as possible, so authenticating the salt certainly won't hurt. Do you consider it bad if an attacker can just insert a fake record (which will cause frustration at least on the user end)? $\endgroup$ – SEJPM Mar 14 '17 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.