RSA keys for encryption and in general DSA/RSA/ElGamal-keypairs

Neil Williams linux at
Wed Jun 16 10:12:25 CEST 2004

On Wednesday 16 June 2004 6:53, Ulrich Schneider wrote:
> Why are DSA-Keys always generated with only 1024 bits even when I tell
> gpg that the key has to be generated with 2048 bits. 

You answered this question yourself in the quote from the The GNU Privacy 

> The size of a DSA key must be between
> 512 and 1024 bits, and an ElGamal key may be of any size. GnuPG,
> however, requires that keys be no smaller than 768 bits. Therefore, if
> Option 1 was chosen and you choose a keysize larger than 1024 bits, the
> ElGamal key will have the requested size, but the DSA key will be 1024
> bits.

Others here can explain why DSA has a maximum size, but the handbook is clear 
- no matter what you ask gpg to do for the Elgamal key, no DSA key will be 
created larger than 1024 bits (or smaller than 512). Different algorithms 
have different strengths, different potential weaknesses and limitations.

GnuPG defaults to the strongest and most suitable algorithm for each use of 
the most commonly generated keys. When signing this message, I don't really 
want a signature MIME part that is larger than the message, as some large bit 
length keys may produce. When encrypting a message, final size is less 
important than the strength of the algorithm/encryption. Using the same 
algorithm for both signing and encrypting requires an algorithm that is good 
at both - sometimes this is too much of a compromise and the best option is 
to use different algorithms for each purpose within the key.

So DSA is good for signatures but the limitation on key size (and probably 
other features that I don't get into) make it unsuitable for encryption. 
Conversely, Elgamal is good for encryption but there was an issue with 
Elgamal when used for signatures, so Elgamal is no longer recommended for 

> If there is alway two public keys -one for signing and one for
> encryption- the question arise for which key is the fingerprint
> computed? I guess for the main-key. But what`s going on with the subkey?

Nothing. If you ask gpg for the fingerprint of the subkey, the same 
fingerprint is produced:

neil at garfield:~$ gpg --fingerprint 0xA897FD02
pub  1024D/A897FD02 2002-01-27 Neil Williams (laptop) 
     Key fingerprint = 744C 978D 7AB8 F27B 3BA6  C101 93B0 D5AF A897 FD02
sub  1024g/4D6D2952 2002-01-27

neil at garfield:~$ gpg --fingerprint 0x4D6D2952
pub  1024D/A897FD02 2002-01-27 Neil Williams (laptop)
     Key fingerprint = 744C 978D 7AB8 F27B 3BA6  C101 93B0 D5AF A897 FD02
sub  1024g/4D6D2952 2002-01-27

> Is there no need to check the fingerprint of the subkey? Or is it

gpg takes care of that on your behalf.

> checked indirectly with the fingerprint of the main key? How does this
> work?
> I also have another question. Is there a possibility to show a key in
> human readable form. Best output I produced is a gpg --export --armor
> <EMAILADRESS>. A key consists of an exponent and a modulus. Is there a
> way to show these values?

Why? If it was possible to obtain the two figures directly, instead of having 
to compute them, cracking gpg encryption becomes simple. I don't expect that 
this is what you intend!

> Another problem:
> I created a 2048 bit RSA keypair with gpg. When I try to encrypt a file
> for this key, gnupg tells me:
> gpg: 0x149881408FAB041C: skipped: unusable public key
> gpg: <FILE>: encryption failed: unusable public key

What does --list-key show? Is there an encryption subkey?
> I also have another 2048 bit RSA key in my keyring. 

It's best to quote the KEYID when comparing a working key with a non-working 
key - it allows others to compare the keys directly, instead of constantly 
asking you to run certain options and re-post the output. If your test key 
isn't for 'real' use, put the keyblock in the message (just the once) rather 
than using keyservers.

> Encryption for this 
> key works. How could that be? Sometimes it works, sometimes not? It
> probably has something to to, by which program the key was generated.
> Here are the comments taken from the public key block.
> 1. key (encryption doesn`t work)
> Version: GnuPG v1.2.4 (MingW32) - GPGshell v3.10
> 2. key (encryption works)
> Version: PGPfreeware 5.5.3i for non-commercial use <>


Neil Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url : /pipermail/attachments/20040616/20fb0789/attachment.bin

More information about the Gnupg-users mailing list