On 4 Nov 2015, at 05:00, "openpgp-request(_at_)ietf(_dot_)org"
<openpgp-request(_at_)ietf(_dot_)org> wrote:
Send openpgp mailing list submissions to
openpgp(_at_)ietf(_dot_)org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/openpgp
or, via email, send a message with subject or body 'help' to
openpgp-request(_at_)ietf(_dot_)org
You can reach the person managing the list at
openpgp-owner(_at_)ietf(_dot_)org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of openpgp digest..."
Today's Topics:
1. Re: Reducing the meta-data leak (Derek Atkins)
2. Re: Reducing the meta-data leak (Neal H. Walfield)
"Neal H. Walfield" <neal(_at_)walfield(_dot_)org> writes:
Hi,
At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly,
suggested that we should try and hide more meta-data. For instance,
instead of listing the recipients, someone decrypting a message would
try each of their available secret keys in turn. Werner pointed out
that these probes are a pain for people who use a passphrase protected
key and I mentioned that it is a pain for people who use a smartcard,
in paritcular, those who use more than one smartcard.
What about using a bloom filter for encoding the recipients? This, of
course, doesn't eliminate the meta-data leak and it can lead to false
positives (= gratuitious passphrase prompts / smartcard prompts), but
it should reduce the metadata leak a fair amount, I think. Thoughts?
There was an extension at one point where you use the string 0x00...00
for the keyID and that forced you to test all your secret keys. There
are certainly times where that is warranted; there are other times where
it is not.
Right. What struck me about the proposed approach was the difficulty of using
it in the other problematic use-case DKG described during the meeting - where
someone has sent you a 5Gb cipher text (or, worse, a stream) and you have to
decrypt some or all of it before you can tell whether you're using the right
key or not.
I suspect the answer is to recognise that not all metadata is equal, and that
it may be appropriate to have different levels of protection (including zero)
for different items of metadata.
For example: if "recipient" is sent in clear, it simplifies the task of
identifying the right key to use, but it would then be up to the communicating
parties to decide whether they should use other means to protect their
identities... The remaining metadata (such as algorithm identifier and
parameters) could potentially be protected by other means.
R
I wasn't at the meeting (in person or virtually) so I'm not sure I
completely understand what the use-case is where the above solution
doesn't work?
Thanks,
:) Neal
-derek
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
At Tue, 03 Nov 2015 09:30:48 -0500,
Derek Atkins wrote:
"Neal H. Walfield" <neal(_at_)walfield(_dot_)org> writes:
At the IETF 94 OpenPGP WG session, Bryan, if I recall correctly,
suggested that we should try and hide more meta-data. For instance,
instead of listing the recipients, someone decrypting a message would
try each of their available secret keys in turn. Werner pointed out
that these probes are a pain for people who use a passphrase protected
key and I mentioned that it is a pain for people who use a smartcard,
in paritcular, those who use more than one smartcard.
What about using a bloom filter for encoding the recipients? This, of
course, doesn't eliminate the meta-data leak and it can lead to false
positives (= gratuitious passphrase prompts / smartcard prompts), but
it should reduce the metadata leak a fair amount, I think. Thoughts?
There was an extension at one point where you use the string 0x00...00
for the keyID and that forced you to test all your secret keys. There
are certainly times where that is warranted; there are other times where
it is not.
I wasn't at the meeting (in person or virtually) so I'm not sure I
completely understand what the use-case is where the above solution
doesn't work?
Bryan Ford proposed getting rid of all unencrypted meta-data. In
particular, he wanted to get rid of the recipients / number of
recipients.
There are some practical difficulties with this approach,
which I mentioned above.
My proposal is a blue sky idea to avoid having to try to decrypt a
message with every secret key while (hopefully) making it more
difficult to get at the list of recipients.
Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp