On Apr 7, 2016, at 6:12 PM, Bryan Ford <brynosaurus(_at_)gmail(_dot_)com>
wrote:
* PGP - S/MIME Signed by an unverified key: 04/07/2016 at 06:12:06 PM
On Apr 7, 2016, at 8:36 PM, Jon Callas <jon(_at_)callas(_dot_)org
<mailto:jon(_at_)callas(_dot_)org>> wrote:
On Apr 7, 2016, at 7:55 AM, Bryan Ford <brynosaurus(_at_)gmail(_dot_)com
<mailto:brynosaurus(_at_)gmail(_dot_)com>> wrote:
The whole idea of providing some form of “mining-resistance” in a
fingerprint scheme is to enable the key-owner to invest some effort at
key-creation time, to ensure that any attacker who wants to try to mine for
a key with a similar-looking fingerprint will have to invest a *lot* more
time and effort, not just a little.
Does this make sense?
I believe I understand you.
You're complexifying key creation for a hypothetical, movie-plot attack.
This attitude, that IETF-standardized protocols should not attempt to address
known or foreseeable weaknesses unless there are documented cases of those
specific attacks happening in the wild *right now*, is one key reason
Internet security is in such a horrific state. When protocol designs only
ever attempt to address attacks that have already been documented in the wild
- and calling all other attacks “movie-plot” scenarios - by definition you’re
always playing catch-up and attackers will always be ahead. The
pervasiveness of this attitude, while understandable, makes me sad.
The first rule of security is that you can't protect against all threats. This
is why you do things like threat modeling.
I'm really sorry you're sad, but you said "although I don’t know if it’s
actually happened in practice" -- which means that it's a hypothetical attack.
But now, below, you're saying it's not. Look, if you were in error and now know
documented cases, when you didn't yesterday, that's cool. We can always revise.
In the case of fingerprint-mining, we actually do have documented evidence of
that occurring, the most obvious and well-known being Facebook’s vanity
.onion address. The fact that Facebook was not maliciously attacking anyone
else - in effect they were only “attacking” their own brand-name by mining
for a public-key whose .onion address would look like it - does not change
the fact that their action demonstrated that both the capability and the
incentives exist in the real-world to mine for fingerprints that look similar
to something-or-other. If it so happened that the “real” Facebook was
mounting this attack against its own brand, the next time it might be a fake
Facebook imposter mounting the same attack against Facebook by creating a
similar-looking vanity name and hoping users will fall for it. The issue is
not who or what the fingerprint-miner is trying to make their mined
fingerprint look like; the issue is that such attacks are clearly practical.
Documented fingerprint-mining attacks have occurred in other domains too: for
example, not too long ago I remember that it was found that the Ripple ledger
was vulnerable to “Transaction ID” fingerprint-mining attacks that were
actually being exploited, in which an attacker mined for low-numbered
transaction IDs which would cause their transactions to get processed first
and provide arbitrage opportunities. Obviously the fingerprint-mining was
for a fairly different purpose in this case, but still it’s another
documented example of the same general class of weakness: i.e., an attacker
mining for a hash-based fingerprint that looks kinda like something that will
help him get what he wants in some way.
Let me go on a small rant of my own.
There is a problem in OpenPGP that it is notoriously too hard to use.
I use OpenPGP through a PGP Universal server, but I also use S/MIME. S/MIME is
in my mailer darned easy to use! Heck, your email itself was signed with
S/MIME, not OpenPGP.
If you make key creation harder, people will create fewer keys.
If you make database lookup from fingerprint to key harder (or more costly)
that makes it harder and more costly.
What's the *benefit* we derive from this added complexity and time?
Moreover, can this problem be solved in a higher-level system?
We need to have a quick way to turn a cryptographic key into a fixed lookup
(database key). The naive solution is a hash of that key, with or without
something else.
If we turn the "fingerprint" into something complex, then we need to have a new
thing that does what the old fingerprint does -- a quick transformation of key
into lookup. What should that be?
Let me give a proposal of a generic scheme:
One of the ideas we had a long time ago was that the "fingerprint" actually has
two fields in it. A tag and a value. I'm still fond myself of the fingerprint
that is
<algorithm-id>:<algorithm-value>
but I'm not wedded to the syntax. I like the idea; I don't care about the
syntax.
If that gets adopted, then we *could* have a high-compute fingerprint and
encourage people to put them on their business cards.
Does that help?
Jon
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp