Guy

phlogiston's pfp

Contacting Guy

Federation handle:

@phlogiston@mastodon.nz

Guy's Information

Guy's Bio

Geek, computer scientist, engineer, blockchain/crypto enthusiast, freediver, baseball nut, father, husband, odd ball, traveller, ...

Guy's Posts

Guy has 3 posts.


Guy

In response to this post

@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 for socially working end-to-end confidentiality sucks). It is also not about other tools (like Signal, Bitmessage, Briar, ...).

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


@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.

by OCTADE ;

Tags: #email #cryptography #authenticity

Mentions: @@wiktor@metacode.biz @octade@soc.octade.net @soatok@furry.engineer


Likes: 0

Replies: 1

Boosts: 0

Guy

In response to this post

@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.


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 :(

by Wiktor Kwapisiewicz ;

Tags: #email #authentication

Mentions: @@wiktor@metacode.biz


Likes: 0

Replies: 1

Boosts: 0

Guy

I was wondering ... as 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 via PGP/MIME is well enough supported by many (free) mail clients.

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

1/2


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.


by OCTADE ;

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.

by Wiktor Kwapisiewicz ;

Tags: #email #pgp #cryptography #security


Likes: 0

Replies: 2

Boosts: 0