At Tue, 12 Jan 2016 00:24:07 +0100,
Rick van Rein wrote:
Thus, even though I realize it is not
possible to completely protect the email addresses, I don't want to
make it too easy to get them.
OK, so your target is to protect from passive observers. That is clear
enough.
I want to protect the subscriber list from passive observers, but the
message contents from active attackers (i.e., the same assurances that
OpenPGP can provide).
Likewise, I want to make it possible to protect the key ids as much as
possible, which can be done using hidden recipients (i.e., using 0x0
for the key id in the PK-ESK packet).
I think that makes a lot of sense, the key ID being very similar to the
email address.
On a side-note though :- it is trivial to use your existing key and
construct another ID for it; you can use the same key material and make
a self-signature with another timestamp. The result is a different
fingerprint and so another key ID. That might be helpful with your
obfuscation plans (blinding all but the last two bytes of the key
ID).
I'm not sure how this helps. AIUI, the key id is used in the PK-ESK
packet so that the OpenPGP implementation doesn't need to try to
decrypt all PK-ESK packets with all available secret keys. This is
not only potentially slow, but also annoying if the user has multiple
passphrase-protected secret keys or secret keys on smartcards. In
other words, including the key id in the PK-ESK packet improves
usability for the *message recipient*. If the message recipient wants
to hide the key id, then the message recipient can use your trick
locally; there is no need to add this to a standard or the mailing
list software implementation.
Note that it should also possible to take the subkey and hang it under
another public signing key.
That was one of my concrete proposals for saving the subscribers in my
mail from a few days ago:
http://mailarchive.ietf.org/arch/msg/openpgp/UuWVSrMu8LEdChEBQgEpBtQR3-Y
You said you lack experience in RFC authoring; if you want to take that
route you probably don't want to overload a given key ID field with
other meaning but instead want to define a new one which simply has two
bytes only or which has a variable size, perhaps prefixed with up to 8
bits "0" and 1 bit "1" to mark the start of a variable-sized ending of
the key ID.
Again, a driving concern is backwards compatibility and, if I
understand your suggestion correctly, you are suggesting a
non-backwards compatible change. Perhaps this extension is useful to
consider for 4880bis.
There are two types of re-encryption that I think are inappropriate:
- when the mailing list software decrypts and reencrypts each
message before forwarding it on to the list of subscriber, and,
You specified below that this is because you consider the system running
your mailing list to be part of the passive observation infrastructure.
If I did, then I misstated my position. I consider the system running
the mailing list software to be a potentially active adversary.
The problem with the mailing list software having access to the
cleartext is that the mailing list server becomes part of the trusted
computing base (TCB), which is often undesirable, because we'd like to
have some untrusted party provide and manage our infrastructure.
Note: this has nothing to do with the list owner, who, I assume, is
part of the TCB.
OK, you are mistrusting the hosting provider. This will be virtually
impossible to do really well, but if it is possible then crypto is the
answer. A non-technical answer to that is "pay them enough so they will
want to behave". Another might be to spread the power over a number of
partial providers. And this quickly brings you to a distributed scheme,
such as a p2p network.
For the purposes of this exercise, I want to trust the mail server as
much as a normal OpenPGP user trusts an SMTP server. Namely, an
OpenPGP user reveals the list of recipients to the SMTP server and
relies on the server to forward the encrypted message.
I realize that there are other approaches that reveal less meta-data,
but insofar as they exist today, they are not widely adopted. I don't
want to say that those fights are not worth fighting, but I am looking
for a short-term solution that provides similar security guarantees
that OpenPGP provides for normal encrypted email.
The problem with reencryption algorithms is that a subscriber can't
reuse her own secret key. Instead, she gets a new secret key (sent
via email, which she has to import) for each mailing list
subscription.
If you know your crypto algorithms well enough, you might be able to
cook up something different... RSA, DH, ECDH are all more potent than
their everyday applications make you believe.
Unfortunately, I'm not that good of a cryptographer. But if you have
some concrete suggestions of things to look at or keywords to search
for, I'd appreciate it.
These are good suggestions and I appreciate the tips! You're probably
right that a good solution can more easily be found by disregarding
backwards compatibility. But, in this project, I'm trying to
determine the best mechanism that doesn't require users to change
their habits or upgrade their software (other than their OpenPGP
implementation and then, only for posters, not list subscribers).
I think you are targeting an audience that, if it is to wisely use the
list and not leak to "interested extra subscribers" by letting them in
on the list (had you thought of the signup procedure yet? key management
is always the culprit) will be quite able to change habits.
I'm trying to target all OpenPGP users. I'm not just interested in
helping those who the subject of a targeted attack, but also those who
are unsophisticated, but are interested in inhibiting mass
surveillance.
Thanks,
:) Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp