public-key-directory-specification

se.) As this project matures, it will be increasingly easy to do this: // @var pkdClient -- A thin client-side library that queries the Public Key Directory // @var age -- An implementation of age async function forwardSecureEncrypt(file, identity) { const agePKs = await pkdClient.FetchAuxData(identity, "age"); if (agePKs.length === 0) { throw new Error("No age public keys found"); } return age.Encrypt(file, agePKs[0]); } And then you can send the encrypted file in an email without a meaningful subject line and you'll have met your stated requirements. (The degree of "forward secure" here depends on how often your recipient adds a new age key and revokes their old one. Revocation is also published through the transparency log.) However, email encryption is such a mess that most people don't quite appreciate, so I'm blogging about that right now. :) Also, Filippo just created a transparency-based keyserver for age, fwiw: https://words.filippo.io/keyserver-tlog/

ct here: https://soatok.blog/category/technology/open-source/fedivers...

e/public-key-directory-specificat... If a non-conformant replica persists copies of the plaintext indefinitely, then you can now use the same legal process to request erasure from the replica. If they do not comply, then you have the same amount of legal recourse you had to begin with. This becomes a lawyer problem, not a technology problem. > How can the replicas verify a query result without having access to the redactable data? The thing you can continue to verify, after a record has been forgotten, is all of the other records in the ledger. Before erasure, that includes the record in question. After erasure, you shouldn't have anything to verify, except that history hasn't been altered beyond the decryption key being zeroed out. If you assert your right to be forgotten, the system should forget. You can no longer be verified, because as far as the system is concerned, the record in scope does not exist. But either way, history remains intact. You don't break the Merkle proofs. You can erase records by zeroing out the key, but you cannot alter them in any other way. The plaintext commitment prevents a server that's committed to a ciphertext, Enc(k1, Alice), from responding with a plaintext for Bob. The commitment is a slow hash that's included in the calculation of the authentication tag over the ciphertext (which is what's committed to the Merkle tree). The tree survives. If this still doesn't make sense, check the docs on GitHub. > OP if you're reading, clarification would be most welcome :) Here's a short and oversimplified workflow to help illustrate it: Alice -> Directory: [Encrypted Data], [Keys] Directory -> SigSum: [Encrypted Data] Bob -> Directory: [Alice]? Directory -> Bob: [Encrypted Data], [Plaintext], [Merkle Proofs over Encrypted Data] Is that easier to follow? If Alice later requests her keys deleted, then you end up with: Bob -> Directory: [Alice]? Directory -> Bob: [Encrypted Data], nil, [Merkle Proofs over Encrypted Data]

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

dmins to behave, because the directory keeps them honest. You also don't have to trust as single directory to behave, since its primary purpose is to be transparent and independently auditable. If a user wants to revoke their key, they can, but it's an additional protocol message appended to the directory's transparency log. If a user loses all their secret keys, one of two things can happen: 1. Their instance admin issues a BurnDown, which allows the user to enroll a new public key as if they were a new user. 2. If the user has issued a Fireproof message, the instance admin cannot issue a BurnDown, and the user is locked out of the protocol. This is a trade-off. Users can move hosts. Users can publish auxiliary data (e.g., SSH public keys), if the extension for that key type is defined and enabled by the directory. Even an attacker with root access to the host cannot arbitrarily or selectively replace a user's public key with their own. With your suggestion, this substitution is trivial. And that's basically how the system works. But that's not the focus of this blog post. This blog post is how to solve the seemingly incompatible design goals of: 1. Offer userbase consistency verification for users' public keys. 2. Don't cryptographically inhibit an EU citizen's rights under Article 17 of the GDPR. 3. Don't introduce backdoors to the transparency log that allow them to perform the same trivial attack that your suggestion enables.