Defaults
Pete Stephenson
pete at heypete.com
Tue Mar 17 23:46:36 CET 2015
On 3/17/2015 11:25 PM, Robert J. Hansen wrote:
>> 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.
[snip]
Agreed. It's always a bit tedious to see large in-line signatures with
short messages. PGP/MIME, as you say, alleviates this issue somewhat by
hiding the signature, but it also tends to be somewhat fragile when
mailing lists are involved...but that's a different story altogether.
> 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.
Yeah. I'm skeptical of non-RFC6979 DSA simply because it can fail
catastrophically if insufficient entropy is not available when making a
signature. RSA only requires entropy when generating a new key, while
DSA needs it for key and signature generation.
If DSA uses RFC6979 I have no issues with it.
>> - 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. :)
*laughs* Indeed!
I hope that everyone understood my point to be "Since GnuPG is already
making a major change by implementing ECC, it'd probably be a good idea
to Do Things Right The First Time(tm), implement strong curves, and make
them the default."
Of course, it'd be a good thing to work with developers of other
OpenPGP-compatible software to ensure that such algorithms would be
widely supported even though the standards don't yet include such
algorithms.
>> 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.
True, but that's not uncommon: OpenVPN in TLS mode renegotiates a new
session key ever hour by default. GnuPG generates new session keys with
each message. Are there any common cryptographic implementations that
would use the same symmetric key for long periods of time?
>> 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.
Interesting, thanks.
Cheers!
-Pete
More information about the Gnupg-users
mailing list