> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users