Defaults

[Robert J. Hansen]

> As long as we're considering "legacy" algorithms like RSA and DSA,
> is there any particular reason for preferring RSA over DSA at such
> key lengths?

I have reasons to prefer RSA, yes, but whether they'll convince you is a
different matter.  :)

Where signature size matters most is in email.  An RSA-3072 signature's
size is significant (says the sophist, surreptitiously suggesting
alliteration on several syllables) on a 512-byte message; there, the
overhead is huge.  On a 5MiB file, the signature's insignificant.

In email, the way of the future is PGP/MIME.  For years I've advocated
inline PGP and said PGP/MIME wasn't ready for prime time, but I'm now at
the point where I believe PGP/MIME is ready to be the default.  And in
PGP/MIME messages, the end-user never sees the signature block, so
there's very little for users to get upset over.  The size difference
between a DSA-3072 signature and an RSA-3072 signature is unlikely to
make a dent in anyone's mobile data plan, either.

So the main advantage DSA has over RSA -- smaller signature size -- is
irrelevant.

And although it genuinely pains me to say this, I can understand why
some OpenPGP users mistrust DSA.  I don't mistrust it and I think people
who do mistrust it are doing so erroneously, but I understand.  NIST's
reputation has taken a pounding in the last few years.

Frankly, people trust RSA more.  I personally think that's foolish:
they're both rock-solid algorithms.  But I understand it, at the same
time, and a decent respect for the concerns of others causes me to
recommend RSA.  I frankly have no preference between RSA and DSA; some
other people in the community trust RSA more; so, okay, let's go for RSA.

> - The Brainpool curves are similar in structure to the NIST curves, 
> though their curve parameters are chosen in a clear, open manner.
> While that leads to increased trust that the parameters aren't chosen
> for nefarious purposes, if one is already making a major change to
> ECC, why not use some other, more modern curve that's designed at a
> high-security level?

Because at present GnuPG supports the following curves:

	* NIST
		o P-256
		o P-384
		o P-521
	* Brainpool
		o P-256
		o P-384
		o P-512

I cannot in good conscience recommend changing the defaults to an
algorithm not yet supported by GnuPG.  :)

> Do you have a link to this discussion on the IETF list? I suspect
> the community here would be very interested.

https://www.cse-cst.gc.ca/en/node/227/html/15164

Looking over it again, it turns out the Canadians are distrustful of
128-bit crypto *in general*.  None of them are approved for periods
longer than seven days.

> Is there something particular about IDEA that concerns you?

About fifteen years ago I learned about a miss-in-the-middle attack on
IDEA that broke 4.5 of 8.5 rounds (by ... Biham, I think).  That made my
eyebrows go up.  It wasn't a full break, but it sure as hell was
interesting, and attacks only ever get better over time.  That was when
IDEA started giving me the heebie-jeebies.

Khovratovich presented a break against full (8.5-round) IDEA in 2012.
This attack isn't huge -- it reduces 128 shannons of uncertainty to 126,
more or less -- but, at the same time, it's freaking enormous.  From
here on out, every improvement is going to reduce the effective strength
of IDEA.  We're no longer playing games of trying to extend things to
the full cipher: for the last three years we've been watching the full
IDEA be subjected to real attacks.

So far those attacks haven't been successful.  Like I said, a
two-shannon reduction isn't much.

But imagine what it's going to be like in another five years.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20150317/91dadcbc/attachment.sig>