On Tuesday 05 July 2005 00:59, Hal Finney wrote:
I'm not familiar with this term "throw-keyid". We don't use it in
RFC2440-bis as far as I know. I think however that you are referring
to this feature discussed in section 5.1:
An implementation MAY accept or use a Key ID of zero as a "wild
card" or "speculative" Key ID. In this case, the receiving
implementation would try all available private keys, checking for a
valid decrypted session key. This format helps reduce traffic
analysis of messages.
...
That does seem to be a valid attack against the anonymity. However
you should be aware that OpenPGP is not trying to provide very strong
anonymity here. No effort is made to obfuscate the key size, for example,
so unusually sized keys tend to reveal themselves. All the RFC phrasing
suggests or claims is that it can "help reduce" traffic analysis.
If we really wanted to guarantee strong anonymity I think we would have
to do quite a bit more work here. Your attack is definitely something
to consider. However, strong anonymity is not something we have aimed
to provide.
Yes. This has never been a direction the project
that I've known, and has always been something
thrust up to the human layer as a "maybe".
Given the weak level of anonymity it affords, perhaps the zero keyid
feature is misleading to users? If so, should we consider deprecating
it until we are willing to do the work necessary to do the job right?
Or we could at least put a note in the RFC emphasizing that this feature
does not provide strong anonymity and should not be relied upon for
that purpose.
I think the paragraph covers all that adequately,
in that it is already a MAY, and the purpose says
that it "helps" to reduce TA.
We can't expect the RFC to teach basic crypto
or basic security. This group and other resources
exist to fill in the gap.
OTOH, I must admit to being mildly conflicted about
the feature. I think it was I who suggested it, and I
was somewhat surprised when it was accepted. I
personally would have shot it down as an uneccessary
complication, myself ;-) But it is only a MAY and I
can't quite put my finger on where it would cause a
problem to a developer.
iang
--
Advances in Financial Cryptography, Issue 2:
https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting