1. 17
  1. 7
      1. 2

        This link is a real winner. Thanks for introducing it to me!

      2. 4

        Ok, I’m no PGP expert, so on the surface this looks really good. I look forward to seeing what other lobste.rs have to say.

        Secondly, why use messagepack, instead of cbor? It appears to me that cbor is gaining popularity in the cryptographic space as the structure medium because of its small size and concise spec…

        Finally, here https://saltpack.org/pgp-message-format-problems , it doesn’t explain how saltpack solves problem 1:

        PGP encryption doesn’t reliably authenticate the sender.

        I would really like to know. This is such a large issue in PGP.

        Reading https://saltpack.org/signcryption-format , it makes me wonder even more.

        I cannot see how this is unique to saltpack. They are still talking about encrypting and signing chunks of messages… But the end person can still re-encrypt and re-send?… And their solution is “you just give out long-lived secrets”. Like what the heck? ANY scheme can do this. And I think it’s the only solution too. You cannot share secrets between two parties without having something pre-shared.

        This seems to be a common factor among all these schemes. For the best security, you need pre-shared secrets.

        Oh there is a way to solve this - I remember someone figured it out awhile ago, but basically you nest your signatures, so that the recipient and message cannot change. If any changes occur, the signature will fail to be verified. So the new recipient will see the message was always intended for the original one. saltpack doesn’t do this from the looks of it.

        Edit: Ah yes, here http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#Repair - this is the same site keybase / saltpack links to also, FWIW.

        Specifically I’m referring to option 4: Sign again the signed-&-encrypted message