-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CipherSeed
MAC is keyed directly with low-entropy passphrase
#4182
Comments
Wow, the pitfalls... |
I tried to tackle this issue, the PR can be found here. |
Another recommendation that came up recently in a discussion with @jorgeantonio21 was to use separate hash operations for turning the primary salt into the |
Description --- The following is an attempt to improve `CipherSeed` mnemonic generation by tackling MAC being keyed directly with a low entropy passphrase. We use proper domain separation to attain this. Motivation and Context --- The generation of MAC, within the context of a `CipherSeed` instance, is obtained through keying a (low) entropy passphrase. In order to reduce the chances of success of an attack involving offline key pre-computation, it is desirable to hash the passphrase, before MAC keying, using proper domain separation. The current PR is an attempt in this direction. How Has This Been Tested? --- With previous unit tests.
The MAC used in the
CipherSeed
construction is keyed (viaBlake2b
input concatenation) with the user-supplied passphrase, which should be assumed to be of low entropy.A straightforward improvement is to extend the associated
Argon2
output and split it to generate two keys: one for theChaCha20
encryption, and the other for the MAC. While the MAC is very short (only 5 bytes in the current design), this approach can take some advantage of any key stretching provided byArgon2
, in addition to preventing an attacker from performing any kind of precomputation on the MAC prior to deriving the key.Additionally, the use of
Blake2b
for this MAC construction should use proper domain separation. Any future hashing API should be strongly considered for this.The text was updated successfully, but these errors were encountered: