encryption algorithm

[Robert J. Hansen]

> I never attributed RSA-1024 to you: i'm merely pointing out that
> good enough for "virtually all users" and "virtually all purposes" is
> the wrong way to select choices that we want to cover the most
> vulnerable targets.

Perhaps: but that's not what I was responding to.  The original poster
was asking why "people" (unspecified people) said to never use anything
less than 2048-bit asymmetric crypto.  My answer was that "people" were
wrong, and that what is needed for a particular environment needs to be
evaluated on a case-by-case basis.

I agree that RSA-2048 is a sensible default, but I don't see how that's
relevant to the thing I was discussing.  Did I miss a topic shift somewhere?

> ECRYPT has some pretty decent conceptual frameworks, engineering,
> and mathematics to explain how they arrived at their strength
> equivalences.

As do NIST, RSADSI, ENISA and others.  I agree they are a highly
professional outfit, but this makes them just one of many.

> Arguably, it's probably also worth being more skeptical about
> guidance coming from NIST specifically, since they are known to have
> taken advice from the NSA...

I have mixed feelings on this.  On the one hand, I fully concur that
there are some troubling possibilities there; on the other hand, it's
too easy to fall down the hole of paranoia and wind up mistrusting
everything and completely wreck your life.  For myself (and this is
purely my opinion), I believe NIST is still reliable.  If there's
evidence of tampering with a particular standard I think that standard
should be revisited and distrusted, but I think it's a stretch to say we
should distrust all things NIST for no other reason than it's
conceptually possible that a given specification, recommendation, etc.,
has been tampered with.

> This is a bad situation...

Agreed.

> Regardless of which group is "right", none of these authorities
> believe that 2048-bit RSA is in the range of a 128-bit symmetric
> cipher, just 112-bits at most.  Do we care about the idea that a
> cryptosystem is as secure as its weakest link?

Yes -- but no one is claiming that 112-bit keyspaces are vulnerable
today, or at any time within the near future.  Further, moving to a
128-bit keyspace is not, IMO, any sort of a real win: you're only
gaining 16 bits of keyspace.  At most you're pushing things back for a
few years; it is not any kind of a long-term solution.

> I note that we don't generally support any symmetric ciphers with
> less than a 128-bit key (3DES with keying option 2 would use 112-bits
> -- but GnuPG uses keying option 1: 168 bits, derived from 192 bits).

Still a 112-bit keyspace, assuming the attacker has effectively
unlimited computational resources.

> If we want to "even out" the crypto so that no one part is clearly
> weaker to attack than the others, we ought to to increase our RSA
> keylengths by default.

Whoa there a second!  You might want to backspace and overstrike that,
because you just shifted to arguing that "since GnuPG defaults to
AES-256, we need to use RSA-15000 by default otherwise the asymmetric
portion will clearly be weaker to attack than the others."

We don't want to even out the cryptosystem.  We want to ensure that each
component of the cryptosystem meets or exceeds our minimum standards for
cryptanalytic resistance -- but the notion of "evening out" the system
is, as near as I can tell, fashionable nonsense.

> way around.  A reasonable hybrid cryptosystem like OpenPGP should
> make the asymmetric part *stronger* than the symmetric part, since
> it presumably is a more valuable target anyway.

So, RSA-30000, then?

> The next day, Schneier announced his new 4096-bit RSA key:

A good bit prior to his death, I asked Len Sassaman why he had a
4096-bit RSA key when he privately mocked them as being key-length
fetishism.  "Because it isn't just about what I think of them," he told
me: "it's because of what *other people* think of them.  There are a lot
of people in the world who mistakenly think anything less is insecure.
They might have something to say which I'd like to hear, and I can't if
I only have a 2048-bit key."

Or something like that, something similar -- it's been a few years.

I understand Len's point of view.  I just think it's bad policy.  I
think we should not cater to key-length fetishism.

> Do we want the asymmetric key length to be the weakest link for users
> of GPG's default choices?

Unless we move to RSA-15000, it will be.

> As gcrypt's speed improves, maybe we can take advantage of the faster
> speeds to switch to stronger asymmetric keys and message digests by
> default as well?

So far in this thread I have not been giving my own opinion on things:
I've been trying to explain the reasoning that has gone into the current
state of things.  Permit me to share my own opinion for a moment.  :)

I agree that a stronger asymmetric component would be nice, but I don't
believe RSA is the way to go.  We're already on the brink of introducing
ECC support into GnuPG.  I think that once ECC support is introduced in
the mainline, it will then be an appropriate time to revisit the
question.  I would support shifting to stronger asymmetric component(s)
at that time, but I don't think it's worth the headache of changing the
defaults if we're just going to change them *again* in under a year.



-------------- 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/20131217/5098774c/attachment-0001.sig>