Why create offline main key without encryption capabilities

[Hauke Laging]

Am So 01.06.2014, 12:54:30 schrieb Suspekt:

> But I yet have to find someone recommending to use the offline mainkey
> also for encryption/decryption of files, that are so important that
> subkey encryption/decryption is not secure enough.

I do :-)

http://www.openpgp-schulungen.de/kurzinfo/schluesselqualitaet/#offline
http://www.openpgp-schulungen.de/scripte/keygeneration/key-generation.sh


> Is there a reason for that? Am I missing something?

There are certain risks using the same RSA key for encryption and 
signing. If you make a blind signature over data someone supplied then 
you unintentionally decrypt the data (and send it back).

There are legal and organizational arguments, too:

1) If you are forced to give a decryption key to the authorities then it 
is an advantage if they cannot use this key to forge signatures.

2) If a signature key has expired then you may delete the private part. 
You should usually never throw away a decryption key, though, as it can 
happen that you have to decrypt data long after the public part has 
expired.

I say: Everyone needs keys at different security levels (German):
http://www.crypto-fuer-alle.de/wishlist/securitylevel/

E.g. the key which is going to sign this email is not suitable for 
handling really important data. But as long as hardly anybody has a 
complete high-security key it seems useful to have at least the mainkey 
as a last resort.

Technically you could use other subkeys for higher security levels – but 
who would understand that? Seems very dangerous to me, more dangerous 
than using the mainkey.


Hauke
-- 
Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/
http://userbase.kde.org/Concepts/OpenPGP_Help_Spread
OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20140601/48c616a0/attachment.sig>