On 3/01/13 10:18 AM, Andrey Jivsov wrote:
As a remedy to the problem note that the collision resistance only
arises when the original "document" is not available. Fortunately, keys
are small, and therefore, the suggested enhancement to the RFC4880 to
remedy the collision dependence of fingerprints on SHA-1 is to store the
original key. Continuing the above example with non-repudiation, the
non-repudiation claims will be made against the application logs (i.e.
audit trails), thus it will be necessary to include complete keys in
addition to fingerprints in logs that record protocol exchanges that are
dependent on public key identification.
This concern will need to be communicated somehow to developers that are
relying on RFC4880.
I agree with this approach. It means no change to the tech in the short
term, just a note that is distributed (perhaps added in any next
revision or additional ID): to insure against future key collision
possibilities in high-security application, store the full key with any
fingerprint.
An alternative method is outlined next. We introduce a new hardwired
fingerprint, for example, based on SHA-3. The above-mentioned
application logs can simply state that "SHA-3 fingerprint is XXX" and
not bother with storing the whole key (which is unfortunately allowed to
change, for example, by acquiring new userIDs, making it hard to compare
the revisions). Any subpacket that currently takes the fingerprint will
be able to take the new SHA-3 fingerprint as well. Applications will be
expected to calculate two fingeprints in parallel and perform a match
with either of them. In addition, we might consider a features packet
forcing or preferring SHA-3 fingeprint (similar to the MDC feature).
KeyIDs in messages can also use 8 bytes of the new fingerprint.
Now that SHA-3 is settled, it seems reasonable to clean out all of the
SHA-1s.
It would be nice if this were to take place within an overall
refurbishment of the entire suite, e.g., OpenPGP 5 or whatever one calls
it. Any change is going to be disruptive, and confusion out in userland
with different feature/time/brand sets leads to loss of users, which
isn't really any good compensation for the illusory security advantage
of replacing SHA1.
...
I will appreciate your comments on this feature. I don't expect this to
be a task that needs an urgent resolution. In my mind this is something
that we agree on, have a simple spec, and then take a few years to
implement and deploy it in a least disruptive way.
+1 It would be ideal if we could select a single small fixed suite of
everything that would last for the next 2 decades.
If there is a more elegant/simpler solution? I would like to hear about it.
On another related point - have the MD numbers been allocated for SHA3
in its various guises?
iang
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp