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
Dieser Beitrag wurde bearbeitet. (4 Tage her)
OCTADE
Als Antwort auf Guy • • •Off the top of my head I can think of one alternative if metadata confidentiality or anonymity matter:
Bitmessage: github.com/Bitmessage/PyBitmes…
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
GitHub - Bitmessage/PyBitmessage: Reference client for Bitmessage: a P2P encrypted decentralised communication protocol:
GitHubOCTADE
Unbekannter Ursprungsbeitrag • • •@wiktor@metacode.biz
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 go
... mehr anzeigen@wiktor@metacode.biz
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.
Guy
Unbekannter Ursprungsbeitrag • • •@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?