On Thu 2015-07-30 10:44:48 -0400, Phillip Hallam-Baker wrote:
That does not mean we have to support those applications. But it does
mean that we have to write a security consideration telling people we
have (1) considered the issue and that (2) either it isn't a problem
or you should do stuff that is going to be affected.
Completely agreed that the security considerations should make a point
of calling out what we think are legitimate and illegitimate uses of a
fingerprint.
The concern here is that Mallet generates two keys that have the
fingerprints
Mxxxx-xxxxx-xxxxx-xxxxx-xxxx1 'M1' and .
Mxxxx-xxxxx-xxxxx-xxxxx-xxxx2 'M2'
Mallet joins an open source project which only takes the first 100 bits for
the fingerprint. He uploads the key for M1 to a keyserver.
He then commits a large number of malicious patches using M2 for
authentication. These are all authenticated against his public key M2 when
he does the commit but the repository uses the key sent in band and does
not keep the key for later verification.
At this point, any attempt to hold Mallet accountable is going to have to
rely on a human examining the logs and working out that Mallet must have
generated the malicious pair of keys. There is going to be no way to unwind
the thing automatically.
In either scenario, the committed code is done by Mallet, who was
explicitly authorized by the system to commit code. So the failure here
is one of auditing, right?
And i think the implementation recommendation that would solve the
auditing problem here is "do not store fingerprints when you could be
storing keys" -- right?
Are there any other attacks we should be aware of due to failures of
collision resistance in the fingerprint?
The connection is that each blockchain output can be used as an axiom of
trust.
I don't know what an "axiom of trust" is, or why i would believe that
anything coming out of the blockchain would be one. The properties i
think you're asking for are those of a global, append-only log. whether
that's implemented by a blockchain or not seems like an implementation
detail.
Since the purpose of fingerprints is to represent roots of trust, this
is a possible use case that the spec should be capable of
accommodating without opening up the question of how precisely that
would be achieved.
Sure, so i think we're saying that fingerprints should be well-defined
enough to be entered into a global append-only log. Do we need more
than that?
The other bit I left out is the idea of compression. The idea here being
that the person generating the key looks for a fingerprint that has 0s for
the first n bits. Then the fingerprint starts with a version number that
says 'the first 32 bits are 0s' or whatever.
[...]
My preference is to just truncate and use the inferred length. That
allows
us to minimize the amount of data we need to put in front of the user
without compromising security.
These two proposals seem incompatible to me. If you give me a
fingerprint that is shorter than the expected length, and both
mechanisms are available, how am i supposed to know whether you've given
me a truncated fingerprint or a "compressed" fingerprint?
Well, the fingerprint version tag would have to flag that encryption is
being used. So instead of the fingerprint being Mxxxx-.... (SHA2-512) or
Sxxxx-... (SHA3-512), it might be Xxxxx-...
By "encryption" do you mean truncation or "leading-zero compression"?
it seems like we're starting to come up with multidimensional
representations of fingerprint formats. I'm already uneasy with the
idea of having multiple forms of fingerprint -- if i'm given form M on
my peer's business card, and then i'm shown a key by my software that
uses form S (or form XS or form XM or whatever) how am i supposed to
compare them?
Wouldn't the phone just store the key itself instead of the
fingerprint? Why does the fingerprint matter in this scenario after
the initial introduction?
OK, 'at least the 512 bit fingerprint'...
Which you do probably depends on if you are using ECC or RSA. With RSA,
those 2048 bit keys start to bulk up...
[...]
It might sound a bit extreme, but since I started in the business, machines
have gotten roughly a million times faster and have a million times the
memory. 30 keypairs instead of one does not seem like a big deal.
Following this logic, i think the answer is still that the endpoints
should store the keys that they think are currently valid and not the
fingerprints. Fingerprints aren't for storage, they're either for
discovery or for verification.
--dkg
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp