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.
It didn't occur to me that anyone generates a new field at keygen
time, or that the key format even included a way to specify the field.
.... There's really no reason to do it.

Furthermore, DSA keys cannot be larger than 1024 bits.

Furthermore, DSA keys cannot be larger than 1024 bits.

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

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.

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.

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?

Furthermore, DSA keys cannot be larger than 1024 bits.


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

"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message
news:7x3cbi4uw0.fsf@ruckus.brouhaha.com...

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.


I think what David meant was the DS algorithm can work for larger
fields/groups just as easily. True that DSS specifies upto 1kbit fields
with 160-bit groups...

"Henrick Hellström" <henrick.hellstrm@telia.com> wrote

Furthermore, DSA keys cannot be larger than 1024 bits.


DSA keys can be as large as you like, according to IEEE-1363
and other standards.

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.

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.

Well, of course you'd increase the size of q along with p. The idea is
to make the workfactor of generic attacks on the subgroup (about sqrt(q)
steps) roughly matches the workfactor of number-theoretic attacks on Z/pZ
(subexponential in p steps). It's just like Diffie-Hellman with short
exponents.

Furthermore, DSA keys cannot be larger than 1024 bits.

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

David Wagner wrote:
It's when you generate a new key for every transaction that it makes
a difference whether you generate new parameters or not. In this
case, it is much better not to generate new parameters; the optimal
security/performance trade off (I would expect) will be to re-use
parameters and just generate a new key.

Depends. The parameters can be generated and stacked in idle time. Very
few (or rather no) servers use 100% of the CPU all of the time.

Also, if you gen your own DP, the other guy needs to ensure they are kosher,

It didn't occur to me that anyone generates a new field at keygen
time, or that the key format even included a way to specify the field.
GPG doesn't present the option of generating a new field when you
generate an EG key the normal way, though there might be some advanced
command that does it. There's really no reason to do it. If you're
paranoid enough to think that an attacker can break DLP over the
canned field, you ought to expect they can also break it over a newly
generated field.

It's when you generate a new key for every transaction that it makes
a difference whether you generate new parameters or not. In this
case, it is much better not to generate new parameters; the optimal
security/performance trade off (I would expect) will be to re-use
parameters and just generate a new key.