encryption algorithm

[Robert J. Hansen]

> It's bad simply because it's far slower than other comparable RNGs 
> that were standardized at the same time.  I did *not* claim it was 
> deliberately backdoored, and i certainly didn't claim it was 
> backdoored by NIST.

Then why did you use it as a "I'm glad you can still trust them even
after they released a deliberately bad RNG?"

Good people and good institutions release bad things all the time.  Bad
things escape committees.  A lot of cryppies cringed when WEP was
announced because it used RC4 and RC4 is so difficult to use correctly.
(And true to form, WEP used it badly.) Does that mean we shouldn't
trust IEEE?

IPv4 is another great example: Vint Cerf has gone on the record saying
that he's a little ashamed of its success, since only having a 32-bit
address space has been sort of an ongoing professional embarrassment to
him, and he knew it all the while he was working for widespread IPv4
deployment.  Should we not trust Vint?

A flawed standard is just that, a flawed standard.  It's not a cause for
a crisis of trust in an outfit that has enjoyed the community's trust
for many decades.

>> Sure.  That's because we can't retroactively change keys that have 
>> already been made.  Even if we adopt your recommendation of moving
>> to RSA-3072 immediately, RSA-2048 will still be the dominant key
>> type for years.
> 
> All the more reason to change the default keylength now, no?

I don't understand.  If your argument against switching to ECC is "we
won't get rid of RSA-2048 for a long time anyway," then how can you use
the same logic to argue for switching to RSA-3072 right now, since
presumably we still won't get rid of RSA-2048 for a long time anyway?

> And if that comes up, we have an answer to that: "ECC is now 
> available, and it wasn't before."

Doesn't address the issues of forcing people to rewrite tutorials and
manuals, rewrite standard operating procedures for their businesses,
rewrite scripts to accommodate the new defaults... etc.  I think you are
vastly underestimating the infrastructure here.

> But honestly, when the first version with ECC support is released, i 
> strongly doubt gpg will switch to that as the default public key 
> algorithm immediately, for the same interoperability concerns you're 
> raising right now.

Only Werner knows his timetable.

> Come on now, what does this hyperbole do for your argument?  I'm not 
> asking for airplane tickets that cost a million dollars.  I'm asking
> for a minimum level of 128-bit-symmetric-equivalent security by
> default.

And you're not making a compelling argument that 112 bits, as it
currently stands, is inadequate.

Further, there's nothing preventing you from packaging your own GnuPG
build that has 3072-bit RSA as a default.  Speaking just for myself, I'd
welcome that -- I wouldn't use it, but I'm completely in favor of there
being a competitive marketplace of ideas and letting the users sort it out.

> Do you really think that's the equivalent of a million dollar 
> airplane ticket?

The point of the metaphor was to show that moving from "adequate for 99%
of the population" to "adequate for 100% of the population" has some
extreme costs involved.

> I'm asking for a strong baseline set of defaults with a reasonable 
> security margin based on current knowledge.  This isn't perfection, 
> it's (fallible, human) engineering.

And your belief is that 112 bits of keyspace is not a strong set of
defaults with a reasonable security margin based on current knowledge?
For crypto that's currently projected to be secure out until 2030?

There's nothing more to say except, I disagree.  At this point in time
112-bit keyspaces are reasonable defaults.  We should be looking towards
shifting towards larger keyspaces, but there's no immediately pressing
urgency.  Let's wait for ECC.



-------------- 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/20131218/6ccfcd8a/attachment.sig>