When it comes to DEB packages and repositories, we're talking about explicitly creating a signature. This is different to encrypting and signing a message for a known recipient key. In that case, gpg uses the receiver's key preferences, in combination with your own local preferences to work out a suitable algorithm choice
Unfortunately, there are not much options available for stand-alone signing right now. Even in GPG-2, there is only an option to disallow a cipher algo, but no option to disallow a digest (signing) algo.
Thus, the only thing you can do is explicitly to define a fixed digest (signing) algo in your preferences. Because that is what will be used, when the debian tooling invokes your local GPG installation to make the signatures.
Obviously, this has the downside to interfere with the automatic choice of a signing algo; which means, after setting that option, a receiver only capable of SHA1 will no longer be able to verify your signatures.
Anyway, set the following to your ~/.gnupg/gpg.conf
digest-algo SHA256
Probably you should also place a personal preference list there, which influences the default when creating new keys (but as such does not immediately solve the problem at hand -- it won't hurt either)
personal-digest-preferences SHA512,SHA384,SHA256,SHA224
default-preference-list SHA512,SHA384,SHA256,SHA224,AES256,AES192,AES,CAST5,3DES,BZIP2,ZIP,ZLIB,Uncompressed
Regarding SHA1 and 3DES, these are the lowest common denominator for the PGP protocol, and thus hardwired into the software. They are automatically added at the end of your preference list, in order to ensure interoperability with other (weak) implementations of the protocol.
See Section 13.2 of RfC4880
Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end.
Moreover, SHA1 is still the only algorithm used/allowed to generate a V4 Fingerprint (See Section 12.2)
Well, it might be time to move on, but there is not much we (users) can do, as long as the standard is not upgraded...
Best Answer
What I've managed to find out. Correct me if I'm wrong.
There are public and private keys, they go in pairs. There are primary keys and each primary key can have one or more subkeys. By default, when you generate a key, you get four keys (
(1) RSA and RSA (default)
). One keypair for signing and certification (primary keys) and one keypair for encryption (subkeys). Also, there are two keyrings, for private and for public keys.And now to the tricky part. I was experimenting with importing/exporting keys. For that I created a key with 2 subkeys. Then I exported it in different ways:
And started exporting keys, and see what happens:
Here are my conclusions, which somewhat contradict what is in the manual pages:
gpg --export-secret-subkeys
is likegpg --export-secret-keys
, but doesn't export private primary key (or makes it useless as they say,sec#
). Generally,PRI_ID
,SUB_ID
s are interchangeable, unless you put exclamation mark after them. But for--delete-key
,--delete-secret-key
they are interchangeable even with exclamation key.UPD According to
gpg --list-packets
I seem to be wrong and there is no contradiction with man pages.--export-secret-keys
must be exporting secret keys after all. It's just that a public key may be inferred from a private one.However, there's one thing left after all. What kind of connection between primary keys and subkeys? Why when I export a subkey, I get primary key as well?
UPD Oh, and each keypair shares one and the same id.