@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?
Comments
Displaying 0 of 1 comments
OCTADE
@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.
Mentions: @phlogiston@mastodon.nz @@wiktor@metacode.biz @soatok@furry.engineer
Likes: 0
Replies: 0
Boosts: 0