long-term GPG signing key

[Ian G]

Amir Herzberg wrote:
> Ian G wrote:
> 
>> Travis H. wrote:
>>
>>> I'd like to make a long-term key for signing communication keys using
>>> GPG and I'm wondering what the current recommendation is for such.  I
>>> remember a problem with Elgamal signing keys and I'm under the
>>> impression that the 1024 bit strength provided by p in the DSA is not
>>> sufficiently strong when compared to my encryption keys, which are
>>> typically at least 4096-bit D/H, which I typically use for a year.
>>
>>
>> 1. Signing keys face a different set of
>> non-crypto threats than to encryption
>> keys.  
> 
> Agreed.
> 
>> In practice, the attack envelope
>> is much smaller, less likely.  
> 
> Huh? It depends on the application. Many applications care only (or 
> mostly) on authentication, e.g. secure DNS (or CA). Or secure payment 
> protocols (not based on sending `secrets` such as credit card numbers...).

Well, yes, depends on the application of course!

With this particular application - signing
people's keys for WoT - that's generally true.
If I was to crack your signing key for example,
then wander around impersonating you, this is
unlikely to do anything useful except confuse
people a lot until you all figure it out.

If we limit our discussion to actual extent
and popular protocols, it is easier to see.
Take for example this *extreme* case of the CA
application.  If I was to publish Verisign's
private key on usenet, what difference would
that make?

Other than a lot
of red faces, not as much as one would think;
they would simply roll another key, then re-sign
everyone's certs and post them out with a free
year for the nuisance factor.  Then a CERT
advisory would tell every "merchant" to roll
over their certs, and browsers would ship new
roots.

(Actually it's probably worse than that.  We
stand at the cusp of SSL attacks, 450 seen
last year, so this would spur a bunch of forged
cert attacks.  Compare this to a couple of years
back when someone noticed that IE had a cert
bug in it, and nobody noticed.  And nobody ever
bothered to attack it.)

But that's the *extreme* case, more or less like
Microsoft faces every month.

For the regular case of say Amazon's private key,
well, Amazon would have a lot of nuisance to
deal with, but in practice it would just be in
up-tick in normal phishing against them for a
few months.

Various random posts:
Netcraft - 450 phishing cases using SSL / HTTPS certs
https://www.financialcryptography.com/mt/archives/000624.html
RSA comes clean: MITM on the rise, Hardware Tokens don't cut it, Certificate Model to be Replaced!
https://www.financialcryptography.com/mt/archives/000633.html
GP4.3 - Growth and Fraud - Case #3 - Phishing
https://www.financialcryptography.com/mt/archives/000609.html

>  > 3. The RSA patent expired, which means that
> 
>> RSA no longer has everyone over a barrel.
>> For various reasons, many projects are
>> drifting back to RSA for signing and for
>> encryption.
> 
> Yes, but depending on how many years you need, the length of key can 
> become substantial/a concern. In which case, you may consider some of 
> the EC signatures or other short signatures. Be careful regarding the 
> hashing, though.

I don't think EC is available for OpenPGP although
GPG may have some experimental product in it?

On the whole - another complete generalisation -
open projects tend to shy away from EC as there
is no clear patent situation, and putting all
the work in only to discover some claim later on
is not effective use of time.  Our Cryptix project
to do EC in Java (Paulo in Brazil) stalled when he
discovered that the so-called "unencumbered" set
was actually quite slow...

iang



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com