> 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 lo

> 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...