On 12/07/14 22:33, Michael Anders wrote:
> I think we are in danger of working with different concepts of what
> "not being able to" means.
The scenario painted is this:
The primary key is used for creating new UIDs and certifying other
people's keys.
The subkeys are used for signing data and messages, and for encryption.
The "authorized people" who can do decryption and signatures simply do
not have access to the key material of the primary secret key; they have
only been given the secret subkeys.
They are cryptographically prevented from adding UIDs or certifying
other people's keys because they only have the public key for the
primary key.
For example, in the case of RSA, there is no copy of the two large
primes of the primary key on their computer; not even an encrypted copy.
The data is simply absent.
> My gut feeling makes me believe this protection is impossible with
> cryptographically independent keys
The primary key and the subkeys are independent from a cryptographic
standpoint; it is only by (signed) data that they are linked, not by
math. This is precisely the reason why this works, so I suspect you've
accidentally left out a negation in that sentence or put one in too many.
> and that you could always at least embed the exported subkey into a
> newly created parent key structure and newly design whatever
> sub/super-key structure you like around the exported key.
GnuPG uses a "dummy-S2K" for this purpose, which signals that what
follows is not actually private key material, but an omission of that.
It looks like this when using --list-packets:
:secret key packet:
version 4, algo 1, created 1331982780, expires 0
skey[0]: [1024 bits]
skey[1]: [17 bits]
gnu-dummy S2K, algo: 3, SHA1 protection, hash: 2
protect IV:
keyid: 98B67DE4DCDFDFA4
:user ID packet: "Test Teststra (Koning van Wezel) <test@example.invalid>"
:signature packet: algo 1, keyid 98B67DE4DCDFDFA4
version 4, created 1405363401, md5len 0, sigclass 0x13
[...]
:secret sub key packet:
version 4, algo 1, created 1331982780, expires 0
skey[0]: [1024 bits]
skey[1]: [17 bits]
iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt:
263ca1c908ec3b00
protect count: 1966080 (174)
protect IV: ad 80 21 8a a8 71 0f 7a
encrypted stuff follows
keyid: 211601B877A3395A
:signature packet: algo 1, keyid 98B67DE4DCDFDFA4
version 4, created 1331982780, md5len 0, sigclass 0x18
[...]
Note how for the subkey it says "encrypted stuff follows" whereas for
the primary key it just says "dummy".
skey[0] and skey[1] are, in spite of their names, public key components
which correspond to pkey[0] and pkey[1] in public key packets,
HTH,
Peter.
--
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
