encryption algorithm

[Daniel Kahn Gillmor]

On 12/17/2013 10:28 PM, Robert J. Hansen wrote:
> On 12/17/2013 9:20 PM, Daniel Kahn Gillmor wrote:
>> (i'm glad you still feel they're trustworthy, even in the context of
>> them having issued a deliberately bad RNG, and their keylength
>> recommendations being weaker than everyone else's!)
> 
> That's a naked slander against NIST.  You're better than that, Daniel.
> 
> No one, and I emphasize *no one*, has presented any evidence that NIST
> issued a deliberately bad PRNG, or for that matter whether Dual_EC_DRBG
> is even backdoored.  _Wired_ magazine wrote of it,

Dual_EC_DRBG was widely acknowledged as bad even when it was released.
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.

I happen to love what NIST stands for (i'm a standards nerd because i'm
a communications nerd, and i care that when i say "1 meter", you know
what i mean), and i want to be able to trust them.  But we do know that
a powerful agency who is *not* NIST has been deliberately attempting to
fiddle with the recommendations generated by this standards body.

I'm not slandering NIST to say that Dual_EC_DRBG is bad.  But it is
indeed bad.  It's bad because it's particularly slow, and it's bad
because it *could be* backdoored if someone knows a special key that the
rest of us don't know.  These are not mistakes that standards agencies
should make, though of course any organization of people is bound to
make mistakes, especially ones that have people deliberately trying to
make them make mistakes.  NIST has acknowledged that Dual_EC_DRBG was a
bad standard by withdrawing it.

> 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?

>> This is a terrible argument for not improving the default RSA key
>> length today.
> 
> I think it's a great one.  One of the best things about GnuPG has been
> its stability.  Changing the defaults is not something to be done
> lightly.  Doing so invalidates FAQs and tutorials, it forces people to
> edit their scripts, it causes uncertainty and doubt and "why did you
> change...?" on the mailing lists.  Changing to RSA-3072 now, and then to
> ECC in nine months or a year, is (IMO) unwise.  "Why are you changing
> the defaults again?  Did you make a mistake the last time?"

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

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.    So if gpg 2.1 releases in 6 months (i'm making
this date up, of course), how many months will it take for the default
algorithm to be changed to ECC?   What about for the old branches
(1.4.x, 2.0.x) that won't support ECC?

What i'm saying is: even if you believe that somehow it would be bad to
change defaults twice within a year of each other (which i don't), i
don't believe that we will have ECC as the default public key type
within a year, certainly not for the 1.4 branch.

>> It costs very little to change the default, and it signals the user
>> community that we take the existence of well-funded adversaries 
>> seriously.
> 
> I think GnuPG has already clearly established its reputation in that field.

It has; let's keep it up.

>> We're engineers talking about building safety and security 
>> infrastructure here.
> 
> Yes -- and part of that is recognizing when the additional expense to
> mitigate a risk is greater than the risk itself.  I'm sure we could
> reduce airplane crashes by 90% if we were to overengineer airplanes so
> much that a ticket cost a million dollars, but we don't do that.

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.  Do
you really think that's the equivalent of a million dollar airplane ticket?

> You want perfection.  You're not going to get it.  It's like trying to
> build a bridge that simply will not collapse, period, no matter how
> large a weight is moved over it.

Have i asked for perfection?  I feel like you're arguing with someone
else here. I even wrote (in the very paragraph to which you are
responding) "Of course we may not get it right".

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.

	--dkg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131217/869441e4/attachment-0001.sig>