Paul Rubin wrote:
Henrick Hellström <henrick.hellstrm@telia.com> writes:
Unusual, perhaps, but I don't think it is bizarre. By generating new
system parameters each time you will (or might, depending on the
algorithm I guess) make it harder to calculate the discrete logarithm
of several public keys in parallel.

If you have a real concern that somebody's going to do that, then use
a bigger field.

That might not give you an optimal security/performance trade off, e.g.
if you are using the keys in TLS handshakes.

Furthermore, DSA keys cannot be larger than 1024 bits.

daw@taverner.cs.berkeley.edu (David Wagner) writes:
Furthermore, DSA keys cannot be larger than 1024 bits.

Oh, don't be silly. Of course they can.

I thought FIPS pub whatever said 512-1024 bits.

Although you could
make the big field larger anyway, the small field is still normally
160 bits, so you might not gain from making the big field bigger.

That is probably correct, but it was my post he replied to, and I was
talking about DSS.

David Wagner wrote:
Henrick Hellström wrote:
That might not give you an optimal security/performance trade off, e.g.
if you are using the keys in TLS handshakes.

Really? That somehow seems hard to believe. I would have expected
the exact opposite. Do you have any calculations to back this claim up?

Why do you find that hard to believe?

David Wagner wrote:
Henrick Hellström wrote:
Furthermore, DSA keys cannot be larger than 1024 bits.

Oh, don't be silly. Of course they can.

No:

http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

Of course 1024 is not a theoretical or a computational limit, but if you
toss together a X.509 certificate with a DSA-3072/256 key and a
DSA-SHA256 signature you will become painfully aware that there isn't
any software that will recognize neither the key nor the signature. The
standard is in this sense setting a practical limit.

daw@taverner.cs.berkeley.edu (David Wagner) writes:
I don't recall what the FIPS says, but why should we care?
DSA is a perfectly good algorithm at key sizes above 1024 bits,
whatever the FIPS might or might not say.

Well, sure, but then it's not standards-conformant and won't
interoperate with a lot of the real-world software that's out there,
as Hendrik pointed out.

As I understand it, PGP supports two public key systems: RSA and
Diffie-Hellman. Are they completely unrelated? Which is better (e.g.
ignoring brute-force, is a 1024bit DH keypair harder to break than 1024bit
RSA keypair?)

They're related but not identical. DH (actually El-Gamal) is
marginally harder to break at the same key size, but if you're really
worried about that, go to 2048 bits either way. EG is somewhat slower
for decryption, quite a bit slower for encryption, but much faster for
key generation.

I guess this means that PGP does not generate new DH system parameters
for each key pair, but only a random private key and the corresponding
public key in some predefined field.

RSA-2048 key generation is faster than DH-2048 key generation if you
include the time it takes to generate the system parameters. (It is
just a matter of at most a few seconds computation time on modern
computers in either case anyway.)

They're related but not identical. DH (actually El-Gamal) is
marginally harder to break at the same key size, but if you're really
worried about that, go to 2048 bits either way. EG is somewhat slower
for decryption, quite a bit slower for encryption, but much faster for
key generation. The main reason for switching over, however, was
hassles in the 1990's about the RSA patent. The patent expired in
2000 so both algorithms are public domain now.

Henrick Hellström <henrick.hellstrm@telia.com> writes:

RSA-2048 key generation is faster than DH-2048 key generation if you
include the time it takes to generate the system parameters. (It is
just a matter of at most a few seconds computation time on modern
computers in either case anyway.)

But it's unusual if not downright bizarre to generate new system
parameters every time you want to generate a DH key.

DH(EG) encryption is very much slower than RSA encryption.
DH(EG) decryption is about twice as fast as RSA decryption.
Unless you use canned primes (the default for PGP) for DH key generation,
RSA key generation is very much faster that DH(EG) key generation.

Unusual, perhaps, but I don't think it is bizarre. By generating new
system parameters each time you will (or might, depending on the
algorithm I guess) make it harder to calculate the discrete logarithm
of several public keys in parallel.

Henrick Hellström <henrick.hellstrm@telia.com> writes:

Unusual, perhaps, but I don't think it is bizarre. By generating new
system parameters each time you will (or might, depending on the
algorithm I guess) make it harder to calculate the discrete logarithm
of several public keys in parallel.


If you have a real concern that somebody's going to do that, then use
a bigger field.