Renewing expiring key - done correctly?

Hauke Laging mailinglisten at hauke-laging.de
Wed Dec 4 02:45:50 CET 2013


Am Di 03.12.2013, 20:20:07 schrieb Robert J. Hansen:

> By introducing offline primary key storage on an air-gapped system, your
> policy has become so complicated that no one, yourself included, is
> capable of always following it to the letter.

Oh, recently I involuntarily proved that I do: I "managed" to DoS myself (what 
a luck nobody uses crypto) by letting my certificate expire over two days 
because I was to lazy to do the effort of prolongig it "securely".


> A system so complex it cannot be used correctly, won't be used
> correctly.

Many people (not including you?) would be surprised where the "so complex" 
border is. When people attend to my courses and use their firmware-hacked 
systems to security pretendingly boot from ro media then I give them sheets of 
paper with the most important information. One of them is for writing their 
secure passphrase down (how about hacking keyboard firmware?). On that sheet 
it says: "This is NEVER to be entered on an insecure (te-hee) system."

Recently a computer science Ph.D. student attended to my course. Guess what he 
did first after he had imported the subkeys onto his normal system and 
something didn't work the way he expected it to...

But I am sure that this border does not have an absolute position. It depends 
on the security culture. If we manage to make crypto an everyday technology 
and most people around you are doing it right (te-hee) then you will probably 
do it right, too, even though you wouldn't today.

In such a culture systems with a firmware hardware combination which allows 
overwriting the firmware from the OS level could not be sold any more. A 
better world is possible.


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: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20131204/581384a3/attachment.sig>


More information about the Gnupg-users mailing list