Create accountLogin

Recent searches

No recent searches

Search options

Only available when logged in.
techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

5.2K
active users

techhub.social: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

#openpgp

4 posts3 participants0 posts today
Replied in thread
Public
Delta Chat

@triskelion
Proton Mail uses #OpenPGP standard and it is possible to send and receive encrypted messages between Delta Chat and Proton Mail. It is not straightforward currently but we work on making it easier by allowing to share the keys in vCards. Delta Chat cannot be used as a client for Proton Mail because Proton Mail does not allow the clients to use SMTP and IMAP to directly access mailboxes.

Tuta cannot be used to send and receive encrypted e-mail because it does not support OpenPGP.

Public
🔗 David Sommerseth

So I've given @mailfence a very quick test on their Free tier.

That seems to be quite reasonable alternative for e-mail services. In som parts it's what I would expect @mailbox_org being. Except of one thing: Unencrypted incoming e-mails will not be stored encrypted.

Since I'm on the free tier currently, I've not tested the IMAP integration.

The weakness of #Mailfence and #Mailbox are that the PGP setup requires some efforts to happen. The "settings" panel on Mailfence is cleaner and better organized than mailbox.org, but the latter one is capable of ensuring all received e-mails are stored encrypted - regardless if it was encrypted at arrival or not.

PGP key management is still not as easy as it should be for non-tech users. "It should just happen automatically", is my stance here. It's close to being good, but you need to explicitly enable encryption on each mail you send - unless you reply to an already encrypted mail. This will confuse users and it will result in more unencrypted mails sent than intended.

Neither Mailfence nor mailbox.org will decrypt encrypted Subject fields.

I've briefly tested the WebDAV integration, which seems to work. But WebDAV is not end-to-end-encrypted, so uploaded data will not be stored in so-called "zero access" mode. This means the Mailfence people managing their servers can access and read your data. This will be the same for CalDAV/CardDAV too (calendar and contacts synching)

Mailbox.org recently announced they will upgrade their login system - which is long overdue. Their OTP setup is currently just confusing and very far from user friendly. Here Mailfence is very straight forward.

Both Mailfence and #mailbox_org still got quite a long way to provide a properly privacy enabled service. They're on a good path, but currently far from the capabilities of @protonprivacy, even on the most basic features in e-mail.

#privacy#email#pgp
Continued thread
Public *
Delta Chat

Some of you may have heard of #simplex which likes to elevate itself as "the first messenger without user-ids" ... a goal, similar to ours, of not letting the transport layer know about who talks. Only we are doing it in the email system, fully interoperable with tens of thousands of existing email servers and other #openpgp endpoints. The email system is much more than SMTP/IMAP or even openpgp btw ... there is plenty of room for radical shifts and new takes. We are just starting :)

Public
Delta Chat

#openpgp traditions and #signal both bind a cleartext identifier, phone number or email address, to a cryptographic key. It opens up attack vectors as the servers/orgs controlling this binding can interfere.

#deltachat avoids such cleartext identity bindings by creating random #chatmail addresses, as transport only. The cryptographic key becomes the identifier and we want it hidden from the transport layer. Only people being in end-to-end encrypted chat need to identify each other, after all.

Public *
Dimly Lit Corners

Email is an open standard! Yet corporate USA has stole it from us. Let's all reclaim our #Email

We need to run our own email servers again and make email a community thing!

Enable running a server from home! Add email servers on .alt, .i2p, & .onion! Support people unable to rent a VPS or get a global domain name! Not everyone has access to a credit card or bank account.

Let's make email open & social again!

Support #OpenPGP!!

#SMTP#IMAP#POP3
Replied in thread
Public
Preston Maness ☭

@Xeniax Totally nerdsniped :D I'd love to be a part of the study.

I don't think that #KeyServers are dead. I think they evolved into Verifying Key Servers (VKS), like the one run by a few folks from the OpenPGP ecosystem at keys.openpgp.org/about . More generally, I believe that #PGP / #GPG / #OpenPGP retains important use-cases where accountability is prioritized, as contrasted with ecosystems (like #Matrix, #SignalMessenger) where deniability (and Perfect Forward Secrecy generally) is prioritized. Further, PGP can still serve to bootstrap those other ecosystems by way of signature notations (see the #KeyOxide project).

Ultimately, the needs of asynchronous and synchronous cryptographic systems are, at certain design points, mutually exclusive (in my amateur estimation, anyway). I don't think that implies that email encryption is somehow a dead-end or pointless. Email merely, by virtue of being an asynchronous protocol, cannot meaningfully offer PFS (or can it? Some smart people over at crypto.stackexchange.com seem to think there might be papers floating around that can get at it: crypto.stackexchange.com/quest).

To me, the killer feature of PGP is actually not encryption per se. It's certification, signatures, and authentication/authorization. I'm more concerned with "so-and-so definitely said/attested to this" than "i need to keep what so-and-so said strictly private/confidential forever and ever." What smaller countries like Croatia have done with #PKI leaves me green with envy.

keys.openpgp.orgkeys.openpgp.org
Replied in thread
Public *
l

@eff @evacide
GnuPG is not the only way to encrypt email, I use #OpenPGP with Thunderbird and @delta, both don't use GPG.

Also pages
ssd.eff.org/module/how-use-pgp
and
ssd.eff.org/module/how-use-pgp
are outdated, Thunderbird now has built-in OpenPGP implementation and Enigmail does not work with the latest versions.

ssd.eff.orgHow to: Use PGP for LinuxNOTE: This guide is not being actively reviewed or updated, and is currently retired. If you would like to use PGP via GnuPG, or Thunderbird with Enigmail, please refer to those services’ websites and documentation for information on how to install and use them. To use PGP to exchange secure emails you have to bring together three programs: GnuPG, Mozilla Thunderbird and Enigmail. GnuPG is the program that actually encrypts and decrypts the content of your mail, Mozilla Thunderbird is an email client that allows you to read and write emails without using a browser, and Enigmail is an add-on to Mozilla Thunderbird that ties it all together. What this guide teaches is how to use PGP with Mozilla Thunderbird, an email client program that performs a similar function to Outlook. You may have your own favorite email software program (or use a web mail service like Gmail or Outlook.com). This guide won't tell you how to use PGP with these programs. You can choose either to install Thunderbird and experiment with PGP with a new email client, or you can investigate other solutions to use PGP with your customary software. We have still not found a satisfactory solution for these other programs. Using PGP doesn't completely encrypt all aspects of your email: the sender and receiver information is unencrypted. Encrypting the sender and receiver information would break email. For similar reasons, PGP does not encrypt the subject line of your emails so you may want to use a generic subject line when sending encrypted emails. What using Mozilla Thunderbird with the Enigmail add-on gives you is an easy way to encrypt the body of your email. You will first download all the software needed, install it, and then end with configuration and how to use the result.
Public
Delta Chat

We are not aware of other FOSS development teams that have as extensive knowledge, both theoretical and practical, about #email and #openpgp and regularly release across all platforms for users world wide ... except for #protonmail with whose technical and security experts we discuss regularly. They are the other major game in town doing pervasive email encryption after all. Did you know that Proton's and delta's VCards are compatible across ecosystems and establish immediate encryption?

Public
Delta Chat

@mathilde #chatmail server users don't have these problems because they don't even need to know their password or email address. Messages in delta chat are stored locally and the server only stores them for a limited time, up to 20 days by default, so all devices have a chance to download the message. Blocklists are also not used, the only requirements are #DKIM signature and #OpenPGP encryption.

Public
Keith Nasman

Remember the old days with key signing parties? I never really got into that but I think with all the "AI" bots we are going to get to a place where we need to have trust networks built on cryptographic keys to filter out the crap.

Note to self: Set up public key and share it.

#OpenPGP#OpenSSL
Public
Delta Chat

The downside of our project approach was that we often got experts being very dismissive on re-using email and #OpenPGP ... and there still is some opposition which often subsides when actually trying #deltachat and #chatmail, looking at security audits and our strong usable security focus.

There may also be surprising upsides. The UK "Online Safety Bill" which attacks end-to-end encryption integrity seems to not apply for ... e-mail. Because everyone knows, e-mail is unencrypted, right? :)

screenshot of page 7 of https://www.legislation.gov.uk/ukpga/2023/50/enacted CHAPTER 7Interpretation of Part 3 55“Regulated user-generated content”, “user-generated content”, “news publisher content” (1)This section applies for the purposes of this Part. (2)“Regulated user-generated content”, in relation to a regulated user-to-user service, means user-generated content, except— (a)emails, (b)SMS messages, (c)MMS messages, (d)one-to-one live aural communications (see subsection (5)), (e)comments and reviews on provider content (see subsection (6)), (f)identifying content that accompanies content within any of paragraphs (a) to (e), and (g)news publisher content (see subsection (8)).
ExploreLive feeds
About