4 ms·
> Where possible, and relevant, take control over that infomation and unlink it from data linked to you. For example, you can control the From field by creating
by mapgrep 11y ago
> Where possible, and relevant, take control over that infomation and unlink it from data linked to you. For example, you can control the From field by creating a new email account.
I genuinely wonder, what's the point of rotating different From: addresses?
If a message has been GPG signed, it is trivial to discover the corresponding public key. Thus, a form of identity — the public key, typically along with email, name, and/or other "user id" information publicly associated with the key — is available to an attacker rergardless of the content of the message.
The sender could refrain from signing the message, but then every time (s)he rotates a new address into the From: field, (s)he must communicate through some other trusted channel that the new address is associated with his/her identity and existing public key.
Then there's the practical concern that most gpg implementations are going to, by default, lookup in the keyring based on the To: address in the email and the user-ids of the keys in the keyring. This will fail, unless the new address is added as a user-id to the public key, which defeats the whole purpose of rotating the From: address.
- rinon 11y agoI think this is why the author recommends NOT publishing public key identity publicly. Additionally, signing may not actually be necessary or desirable (e.g. given out-of-band transmission of the receiver's public key and a desire to avoid attribution).
- mentat 11y agoIt's still trivial for any state level adversary.
- grugq 11y agoCorrect. There is a section that addresses signing. In short: don't do it. OP: From addresses are not to be rotated. Each communications channel should be in a compartment. Compartmentation requires minimizing the amount of information leaked, not maximizing it by contaminating a large number of addresses. For more information on compartmenting and unlinking relationships, see [1]. This guide is not a complete COMSEC plan. A complete plan would be tailored to match the circumstances and requirements of the actors involved. This is a collection of notes and best practices. They need to be adapted and actively applied for the situation. A complete COMSEC plan would include things like setting up dedicated email accounts for correspondence, creating the corresponding PGP keys. The confederates would exchange contact information, either out of band, or via another exist secure channel. Information exchanges would be via PGP email with fixed subject lines and only relevant information inside the content. All emails would be deleted in a rolling 7 day window. [1] http://grugq.github.io/blog/2013/03/18/the-paddy-factor/ http://grugq.github.io/blog/2013/03/18/the-paddy-factor/