Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday November 08 2015, @02:06PM   Printer-friendly
from the Wbuaal-qbrf-abg-rira-haqrefgnaq-EBG13 dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 1, Interesting) by Anonymous Coward on Sunday November 08 2015, @02:51PM

    by Anonymous Coward on Sunday November 08 2015, @02:51PM (#260358)

    I find it weird that you can not sign with expired keys, yet can still change the expiry date on said key.

    My intuition says it should be the reverse: you should be able to force the client to sign with an expired key, but you should not be able to change the expiry date on the key.

    Starting Score:    0  points
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  

    Total Score:   1  
  • (Score: 2) by frojack on Sunday November 08 2015, @04:34PM

    by frojack (1554) on Sunday November 08 2015, @04:34PM (#260389) Journal

    I find it weird that you can not sign with expired keys, yet can still change the expiry date on said key.

    You can always change expiry because you have both sides of the key, the public and the private key. No one else can change the expiration date.

    All PGP mail clients will fail to decrypt mail when the sender's key has expired. Its a safety feature. Therefore the sender's mail package must not sign or encrypt with an expired key. It is sometimes possible to force decryption even when you receive it long after the key has expired, or it has been sitting in an inbox for a couple years.

    Expiry is NOT always used. You can generate keys that don't expire.

    Its really only intended to kill off keys you forgot you even generated, such as when you change jobs or something. Revoking your key is one of the things you should due when you move on.

         

    --
    No, you are mistaken. I've always had this sig.
    • (Score: 0) by Anonymous Coward on Monday November 09 2015, @02:57AM

      by Anonymous Coward on Monday November 09 2015, @02:57AM (#260629)

      You can always change expiry because you have both sides of the key, the public and the private key. No one else can change the expiration date.

      The point is that changing the expiry date does not change the key fingerprint. That implies that the key fingerprint is only a hash of the public key. To make the expiry date impossible to change, we need only include it in the hash with the private key.

      It is good that you have to prove that you have the private key to change the expiry date. However, the whole point of an expiry date is to put the key out of use before any third party can obtain it either through brute force or some other compromise.

      Twice now, I have missed some house-keeping tasks for rotating my key before the key expired. Essentially, to move to the new key, I have to prove possession of the old key. This would be much simpler if I did not absolutely have to change the expiry date to do so.

      PS: and yes, revocation is what I would do if I knew my key was compromised. :)

      • (Score: 2) by frojack on Monday November 09 2015, @04:12AM

        by frojack (1554) on Monday November 09 2015, @04:12AM (#260648) Journal

        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

          by Anonymous Coward on Monday November 09 2015, @07:09AM (#260672)

          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

            by Anonymous Coward on Monday November 09 2015, @04:18PM (#260808)

            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)

  • (Score: 2) by c0lo on Sunday November 08 2015, @06:46PM

    by c0lo (156) Subscriber Badge on Sunday November 08 2015, @06:46PM (#260433) Journal

    but you should not be able to change the expiry date on the key.

    What does your intuition says on what to do with compromised keys?

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
    • (Score: 2) by frojack on Sunday November 08 2015, @07:43PM

      by frojack (1554) on Sunday November 08 2015, @07:43PM (#260463) Journal

      REVOKE

      --
      No, you are mistaken. I've always had this sig.
    • (Score: 2) by kurenai.tsubasa on Sunday November 08 2015, @07:56PM

      by kurenai.tsubasa (5227) on Sunday November 08 2015, @07:56PM (#260471) Journal

      Publish a revocation as soon as you become aware the key has been compromised. I typically don't bother with setting an expiry date. I think expiry dates are a bit paranoid albeit it's one of those usability vs. absolute cryptonerd security trade offs.