removing SHA1 from digest preference list

[Daniel Kahn Gillmor]

On 05/02/2009 11:26 PM, John W. Moore III wrote:
> It falls under the heading of Compatibility; particularly with regards
> to backward compatibility.

Right, understood.

> Until such time as OpenPGP implementations completely abandon backwards
> compatibility SHA1 will be recognized & 'accepted'; just as MD5 is at
> present.  Removing it from Your Preference List will only mean that
> everyone who Imports Your Key after You make the change will recognize
> that You prefer _not_ to use SHA1; but everyone who already has Your Key
> on their Keyring will still be encrypting to a Key that states SHA1 in
> it's Preferences.

I understand that this process of preference propagation may be
imperfect and incomplete, and may take a long time.  This is precisely
why i wish to start it as soon as possible.

> Even the Key Servers will be propagating Your Key
> with SHA1 'advertised'.

Can you explain this?  If i look at my current key on the keyservers, it
appears that the latest self-signature says "(pref-hash-algos: 10 9 8
11)".  This does not include hash algorithm 2, which is sha1, and since
the latest signature is presumed to supercede the previous ones, it
looks to me like the keyservers are already *not* propagating my key
with SHA1 "advertised".  What am i misinterpreting?

I got this information with the following pipeline:

wget -O- "http://keys.gnupg.net:11371/pks/lookup?op=get&search=$KEYID" |
awk '/^$/{KEY=1}; /^-/{KEY=0} { if (KEY) { print $0 ; } }' |
base64 -d |
gpg --list-packets

> Generating a New Key at the present time will not erase this as every
> OpenPGP Application I am aware of at present includes SHA1 by default.
> SHA1, at present, is the de facto Standard hash to ensure that
> Encryption to multiple Keys using various OpenPGP engines will /always/
> have a compatible Hash.

I understand this.  However, at one point, the one hash algorithm that
everyone would /always/ have available was probably MD2 or something
else that is currently demonstrably broken today.  This is not a good
reason for us to use MD2 today, and it will not be a good reason for us
to use SHA1 several years from now.

> Also to consider is that, at present, the
> Default Key for GPG & PGP is a 1024 DSA Key.  Should You be successful
> in implementing an installation that cannot or refuses to recognize SHA1
> You will be cutting Yourself off from being able to verify the
> overwhelming majority of Signatures that You encounter.  :-\

Yes, i'm aware.  I'm not talking about completely rejecting all SHA1
signatures right now.  I'm talking about signalling my intent to
deprecate SHA1, so that those with whom i correspond have a signal to
begin transitioning to a better hash *before* i decide to abandon it.

> Exclude?  Even if MD5 isn't listed in the Preferences it is still
> recognized and accepted by all OpenPGP Applications.

If this is true (i haven't tested it), i'd like to see that change.  i'd
like at least to be able to tell gpg "please consider as invalid any
credentials dependent upon an MD5 digest" and have it respect that.
I'll try to test this out today.

> discarding SHA1 is not going to be as simple as throwing a
> switch.  This is what folks are alluding to when they say Move in an
> orderly fashion toward the theater exits.  To promptly abandon SHA1
> immediately is akin to shouting Fire in a crowded theater.  <SIGH>
> Ostracizing SHA1 will be no simple task.

Sigh.  I totally agree.  This is exactly why we need to be having this
discussion now, so that the theater exits will have lighted signs and
arrows with clear directions as people start to get out of their seats.
 I want to make sure the mechanisms are all in place and properly
documented *before* a practical demonstration of the described
vulnerabilities exists in the wild.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 890 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090503/5dd0af3d/attachment.pgp>