Conversation

Notices

1. Embed this notice
   Guy (phlogiston@mastodon.nz)'s status on Friday, 17-Jan-2025 23:18:52 JST Guy

   I was wondering ... as #email encryption via PGP/GnuPG is not suitable for true and ongoing end-to-end confidentiality. But what about authenticity of mails? I dislike S/MIME for its corporate nature, and #PGP via PGP/MIME is well enough supported by many (free) mail clients.

   What's the #cryptography or #security community's view on PGP for signing emails? Or what would a suitable alternative be? I haven't come across any, though.

   1/2

   • Embed this notice
     OCTADE (octade@soc.octade.net)'s status on Friday, 17-Jan-2025 23:18:51 JST OCTADE

     in reply to
     Off the top of my head I can think of one alternative if metadata confidentiality or anonymity matter:
     
     Bitmessage: https://github.com/Bitmessage/PyBitmessage
     
     Bitmessage hides non-content metadata and uses a flood mixnet to unlink sender and receiver from eavesdropper view.
     
     There is no alternative for email. Email clients support PGP and that's it. PGP does guarantee authenticity of a message due to digital signatures. PGP does not hide metadata about sender and receiver.
     
     If you want truly confidential communication you have to set up a private pipeline. If you are using a public paid or free email service, you have zero confidentiality. Even if your message is encrypted, the email operators know who you are talking to.
     
     #PGP #Email #Encryption #Privacy
     
   • Embed this notice
     OCTADE (octade@soc.octade.net)'s status on Saturday, 18-Jan-2025 06:06:11 JST OCTADE

     in reply to

     • Soatok Dreamseeker
     • Wiktor Kwapisiewicz
     @wiktor@metacode.biz @soatok@furry.engineer
     
     You will need to design your own email client that works with encrypted attachment blobs instead of using the standard headers and body. This way you can send a hash, cipher, or blank line for the Subject, then let the client decode attachments to get the plaintext subject.
     
     What you are seeking will not happen without re-designing how the mail client software interacts with the messages.
     
     View it this way. Email is just data following a certain format and scheme. You can create a client that formats and interprets encrypted attachments without revealing any metadata about the attachments. Except for the MIME attachment markers, the rest of the body and subject can be blank. Then your client can perform whatever logic it wants to display the attachment as actual message.
     
     With current email clients not having some custom interface, you can send encrypted attachments, and always use the same generic subject line and body. You are never going to stop idiots from forwarding plaintext, unless the client software is specially programmed to prohibit this. And then someone creates a plugin to circumvent it and we're back where we started.
     
     This is one reason why in a corporate or business environment all installable software should be whitelisted only and require signatures from the administrator keys.
     
     
   • Embed this notice
     Guy (phlogiston@mastodon.nz)'s status on Saturday, 18-Jan-2025 06:06:12 JST Guy

     in reply to

     • Soatok Dreamseeker
     • Wiktor Kwapisiewicz
     • OCTADE

     @wiktor
     @octade
     I *really* appreciate your input here. The purpose of this thread is to venture into opportunities to improve traditional email in a way that doesn't suck (as @soatok also states in depth in his blog post that #email for socially working end-to-end confidentiality sucks). It is also not about other tools (like Signal, Bitmessage, Briar, ...).

     This is about potential #cryptography for #authenticity or mon-repudiation use cases of email. PGP flavours, S/MIME or something else?

   • Embed this notice
     Wiktor Kwapisiewicz (wiktor@metacode.biz)'s status on Saturday, 18-Jan-2025 06:06:13 JST Wiktor Kwapisiewicz

     in reply to

     Just for the record: it’s still possible to get a free S/MIME cert nowadays e.g. https://www.actalis.com/s-mime-certificates — not affiliated, but checked it today and got a valid one, it’s still a bit of a hassle clicking through the forms there :-/

     If it would be more convenient I guess regular people wouldn’t mind it being centralized. The same way as domain TLS certificate authorities operate now.

     As for PGP, the current “schism” where GnuPG forked OpenPGP into their own, proprietary https://librepgp.org/ won’t help the interoperability, I’m afraid :(

   • Embed this notice
     Guy (phlogiston@mastodon.nz)'s status on Saturday, 18-Jan-2025 06:06:14 JST Guy

     in reply to

     • Wiktor Kwapisiewicz

     @wiktor
     Yes. Centralisation and the strong corporate flavour are my main issues with S/MIME. And for those reasons there's not been much of an urge to make free/low-cost certs available.

     #email #authentication

   • Embed this notice
     Wiktor Kwapisiewicz (wiktor@metacode.biz)'s status on Saturday, 18-Jan-2025 06:06:15 JST Wiktor Kwapisiewicz

     in reply to

     S/MIME has two problems: it’s harder to get a free certificate (Let’s Encrypt for S/MIME could really help here) and, AFAIK, it still technically is not using modern cryptographic cipher suites (e.g. no AEAD).

     It would be cool to know these problems are being resolved.

     FWIW in my experience S/MIME is also quite well supported in e-mail clients. Additionally due to centralized CA nature there are no questions whether the certificate is good or not.