This paper presents the results of a laboratory study involving Mailvelope, a modern PGP client that integrates tightly with existing webmail providers. In our study, we brought in pairs of participants and had them attempt to use Mailvelope to communicate with each other. Our results shown that more than a decade and a half after "Why Johnny Can't Encrypt," modern PGP tools are still unusable for the masses. We finish with a discussion of pain points encountered using Mailvelope, and discuss what might be done to address them in future PGP systems.
The PDF of the study can be found here.
(Score: 2) by frojack on Monday November 09 2015, @04:12AM
But again, you are worrying about stuff that the designers already thought out, and planned for.
Updating a key's expiration time
The expiration time of a key may be updated with the command expire from the key edit menu. If no key is selected the expiration time of the primary key is updated. Otherwise the expiration time of the selected subordinate key is updated.
A key's expiration time is associated with the key's self-signature. The expiration time is updated by deleting the old self-signature and adding a new self-signature. Since correspondents will not have deleted the old self-signature, they will see an additional self-signature on the key when they update their copy of your key. The latest self-signature takes precedence, however, so all correspondents will unambiguously know the expiration times of your keys.
https://www.gnupg.org/gph/en/manual/c235.html [gnupg.org]
See also:
https://www.gnupg.org/gph/en/manual/c481.html#AEN519 [gnupg.org]
The fingerprint of a key is not controlling. Its not part of the encryption or decryption process. Its just a convenient handle. That it doesn't change makes it possible to refresh all the keys in your key ring from the key-servers.
And with each refresh you get the latest keys and their expiration dates etc.
Look, I'm not an expert in this area. If you think you can make an argument for a change in the handling of expiration dates, by all means take it up with the designers and point out the folly of their ways. It seems pretty clear your idea will break a lot of things, and add zero extra security.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Monday November 09 2015, @07:09AM
The part you are missing is that I don't think changing the expiry is necessary if the software will allow you to do operations on expired keys (with dire warnings of course).
I am not sure if the designer of PGP had a specific reason for doing it the way he did other than elegant design.
Essentially, if you make the expiry date tied to the key, such that the fingerprint changes: the expiry field the becomes mandatory rather than optional. I agree that most fields should be optional; allowing changes without changing the fingerprint. I think that the expiry date is pointless if it can be changed later.
(Score: 0) by Anonymous Coward on Monday November 09 2015, @04:18PM
OK, I think I figured out why changing the expiry date does not change the hash (fingerprint).
Generating a keypair is an expensive operation, while generating an expiry date is not.
If the date is used as a nonce, it would make generating partial hash collisions easy. Since short keys only have 8 hex-digits, that means you need only match 64 bits to catch the unwary. (Bitcoin requires 32 hex digits to match at difficulty 0)