4 ms·
I’m confused about the purpose of truncating the salt. How does the attacker learn anything about the salt without breaking Argon2id first? It’s not like the
by comex 2y ago
I’m confused about the purpose of truncating the salt.
How does the attacker learn anything about the salt without breaking Argon2id first? It’s not like the salt is included in the Sigsum ledger.
If the attacker did somehow learn the salt (truncated HMAC), it seems like that would immediately break security, regardless of truncation. Suppose the attacker starts with a dictionary of all possible Actor IDs, which seems reasonable, and that they calculate the truncated HMAC for every possibility until it matches. Due to the truncation, the attacker may get one or more false username matches in addition to the true username match. But if the attacker has narrowed down the username to two or three possibilities, they’ve already basically won. And they could just check the possibilities against Argon2id to learn which one it is.
On the other hand, if the attacker doesn’t know anything about the salt, then why would it matter if the salt did uniquely identify a user? How would they “observe that the recent-merkle-root is the same for two messages, but their salts differ”?
It’s quite possible that I’m misunderstanding something. I am not a cryptography expert.
But more broadly, it just seems wrong to use a salted password hash but have the salt be based on the same password that’s being hashed. I don’t think it’s _insecure_, because the salt also includes a high-entropy part (the recent-merkle-root). But I don’t see how it increases security at all. The security should be the same as if the salt only included the high-entropy part.
In other words, the entire “HMAC -> truncate -> Argon2id” process can be seen as a password hash in its own right, where the input consists of the secret username, plus various bits of public information such as the recent-merkle-root. But that’s essentially a form of rolling your own crypto, and it’s unnecessary. Argon2id is already a secure password hash by itself, so you can just feed that data directly to it.
- some_furry 2y ago> How does the attacker learn anything about the salt without breaking Argon2id first? It’s not like the salt is included in the Sigsum ledger. Take a close look at https://github.com/fedi-e2ee/public-key-directory-specification/blob/main/Specification.md#message-attribute-encryption-algorithm https://github.com/fedi-e2ee/public-key-directory-specificat... The commitment (Argon2 salt || Argon2 output) is included in the ciphertext blob. The format of each encrypted attribute is: h || r || Q || t || c Where "h" is the version ID (0x01 currently), "r" is a 256-bit random value for key derivation, "Q" is the plaintext commitment, and "t" is the authentication tag. All of these values are fixed-length. Then "c" is the ciphertext, which is variable length. > If the attacker did somehow learn the salt (truncated HMAC), it seems like that would immediately break security, regardless of truncation. > Due to the truncation, the attacker may get one or more false username matches in addition to the true username match. But if the attacker has narrowed down the username to two or three possibilities, they’ve already basically won. And they could just check the possibilities against Argon2id to learn which one it is. That's an interesting point. It might be beneficial to exclude the plaintext, then, given that we already have a high-entropy value (the previous Merkle root). We could also just use "r" to calculate the salt, since that's right there. Thank you for this feedback. My primary motivation in writing this blog post (and the ones that follow it which will focus on different design decisions and trade-offs) was to elicit better feedback for the current draft of my proposal. EDIT: https://github.com/fedi-e2ee/public-key-directory-specification/pull/55 https://github.com/fedi-e2ee/public-key-directory-specificat...
- csense 2y agoI was super confused about this as well. Also, the way OP picked the length of the truncated salt was troubling to me: "Too small, and we improve the economics of precomputation. Too large, and we risk creating a reliably crib for distinct plaintext values" -- then went on to do a tricky computation to find the balance. The inputs of this computation seem to be some assumptions about the number of users on the network and the computing power available to adversaries -- both of which could be wrong, and/or conceivably change by orders of magnitude over a few years. Past tense, because OP has changed the post (perhaps in response to your comment) and now says "In my earlier design, we needed to truncate the salt and rely on understanding the birthday bound to reason about its security. This is no longer the case, since each salt is randomized by the same random value used in key derivation." I haven't read the changes in enough detail to say anything about the new design.
- some_furry 2y ago> (perhaps in response to your comment) Yes. > I was super confused about this as well. > I haven't read the changes in enough detail to say anything about the new design. Sorry about that, but the entire reason I decided to write these blog posts was to get feedback about different aspects of my proposal before I tag a release. In one bite, it's too easy to get distracted and miss details.