Mastodon: end-to-end encryption with Mailvelope

[mdik]

Hi,

I'm considering applying for this round of Prototypefund with the project of making Mailvelope compatible with Mastodon and Diaspora.

Mailvelope is conceived as a browser plugin for pgp encryption of emails, but it is very easily applicable to any text input on websites.

The first step would be to make Mailvelope recognize the textarea as a text to be potentially encrypted, and to extend the character limit for pgp messages and auto-cw them.

A second and third step would be to implement support for the Mailvelope-API in Mastodon, and setting up automatic key management (this could be done with a dedicated key server, or via Mastodon federation itself).

My intention is to keep the complexity as low as possible, and if in doubt only go as far as to make it possible at all to encrypt messages with Mailvelope, but the farther the better :-D

Would that be something others would be supportive of?

Thank you for considering and sincerely,

Malte

[albjeremias]

any news on this? how hard would be to implement this?

[Hasimir]

This proposal takes the wrong approach. A focus on security is good, but to do so by tying every Mastodon instance and user in the world to one very specific piece of software (i.e. Mailvelope and OpenPGP.js) is dangerous to people living with a different threat model to you.

Since JavaScript powered encryption is fundamentally weak (due to lack of a decent PRNG), everything that uses it is undermined. It might be okay if your sole concern is whether the teacher is looking at random messages, but it's less okay if the server is run for citizen journalists in, say, Mexico and trying to avoid cartels.

[albjeremias]

@Hasimir do you have any guide or more documentation on this?

[mdik]

@albjeremias Basic functionality probably isn't too hard, but I need some sort of funding to find the headspace between jobs (or then, not so many jobs), and other things. I applied for Prototypefund again, so let's cross our fingers :grin:

[Hasimir]

@albjeremias Yep, plenty, though there's still a fair bit more work to do.

The first draft of an extension to Activity Streams 2.0 and ActivityPub is written and discussion with the original ActivityPub design team began last week. The (optional) extension integrates those two protocols with OpenPGP itself rather than any specific implementation of it. That said, the design is modular and it would be possible to adapt (some) alternative cryptographic protocols or systems to the task.

The reason why OpenPGP was selected essentially boiled down to these three points:

1. Cryptography which left the control of keys and user data being left in the hands of end users themselves is preferable in order to address most threat models (not counting the gov't is miffed because you won't let them spy on you — that doesn't count).
2. Many of the security issues with ActivityPub are simply a function of it being a transport protocol. OpenPGP has already solved the vast majority of those same issues or types of issues except when it did so the transport protocol was SMTP. Thus it could readily be applied to this newer transport protocol to provide the same benefits.
3. The protocol extension author is a member of the GNU Privacy Guard developer team and former member of the (recently closed) IETF OpenPGP WG. So there was a preference to utilise a cryptographic protocol with which said author was already familiar. The GnuPG Project supports two such protocols: OpenPGP and S/MIME. Of those two; OpenPGP is stronger, provides end user key control and is the engine for which that dev has the most experience.

As for in browser supporting solutions to the end user crypto implementations. There are a number of possible solutions and they don't all rely on JavaScript. Those that don't, however, generally end up relyng on some means of sneaking past the sandbox in order to interact with native programs and libraries.

When I've needed to use OpenPGP via a browser what I usually end up doing is editing any given textarea with my preferred editor and either the Chrome or Firefox versions of this extension or add-on. Indeed, I'm using it now. Since my text editor supports GPG, then I can easily use it that way. The only JS involved there is to load the editing buffer and connect to the edit server. The rest is handled by GPG itself (C code) and Elisp wrappers.

I have, however, made a proof-of-concept alternative, but been too busy to develop it further. That used GPGME, the GPGME Python Bindings and Flask to provide a local web based interface to any given function and then it's just a matter of getting the browser to connect to the local web service. Since that just accesses the local GPGME, it behaves as any standard invocation of GPG itself, including the use of gpg-agent and pinentry. It's a cute trick, but there are a number of other issues vying for attention and some of them have far greater application and scope than yet another method of trying to offset the inherent flaws in JavaScript.

[wiktor-k]

@Hasimir is there any public info / mailing list where one can track this OpenPGP+ActivityStreams/Pub?

I've been experimenting with keeping user keys on user device with the current design of ActivityPub as it is used in Mastodon. Unfortunately that means the user would have to sign activities that are exchanged between servers (like Create), and HTTP Signatures would have to omit some important headers (e.g. Host) so it just doesn't look nice.

Exchanging signed OpenPGP messages would be a lot cleaner but I'm curious about that design's details (base64 OpenPGP messages inside a JSON property? using fingerprints as user identity?).

[Hasimir]

@wiktor-k Not yet, when it's opened up for public comment it'll be on the gnupg-devel mailing list. One thing I did leave out of my previous comment in point no. 3 is that I was referring to myself there.

The first draft was completed immediately prior to the Efail whitepaper release and we've all been a bit distracted by putting out brushfires and trying to counter the unnecessary fearmongering from a large organisation which should've known better, but didn't. There's no set timeframe for the completion of the second draft which will tighten up some things and replace the quick & dirty examples which used my key with a somewhat smaller example user key (mine exports a bit large, even with "export-minimal" set), possibly with some additions from the AS2 and AP authors.

Even so, I expect that moving to the first public review and discussion to be relatively soon (weeks, not months), even with other things interrupting periodically. Don't worry, I'm well aware that people have been after something like this for ages. That's how I found this issue and several others; while checking past feature requests to see whether I'd missed things or what to expand on.

Briefly, though: I addressed the signature issue by creating a new Signed Note object type for it and what is signed is not the entire object, just the most essential parts with the signature made as a detached signature of those parts and included as an additional item (technically the Signed Note is closer to a Collection); and the same for encryption, though there are still aspects to address there, particularly where the encrypted content also contains a Signed Note and also with handling sanitising content by the client interface when that content is first encrypted. There's even more with the Actor information too, but I did want to keep this brief.

It's intended as an optional extension so that if another instance doesn't use it at all, either by choice or their software just can't at that point, it shouldn't fail horribly when encountering unexpected data (hence moving as much as possible out to new objects). Most of the rest of the work was just applying the lessons learned from SMTP and other OpenPGP usage to this new transport protocol (mind you, that's not exactly a small thing).

I'll try to remember to add a note to this issue when the second or third (not sure which it will be yet) draft is announced publicly on the gnupg-devel mailing list and in addition to those AS2 and AP geeks interested enough to sign up, up to approx. 1,000 security and cryptography geeks also run it through the grinder. Which is another reason for not going straight to public review on the first draft.

Anyway, gnupg-devel isn't really a high volume list (though with a bit of a spike recently due to the other distractions); so signing up in advance of the discussion shouldn't be a burden on one's mail filters and it's a Mailman list so it's very easy to filter. If you want to skip that until announcement time, however, drop me a line with your email address and I'll ping you when it's reached that point. For this, definitely use my work email (GPG key: DB4724E6FA4286C92B4E55C4321E4E2373590E5D and the last and most obvious UID for this topic).

[wiktor-k]

Thanks for the update @Hasimir, I didn't immediately recognize you from gnupg-devel.

The current design used by Mastodon (serializing JSON into RDF quads and signing that) is something that could definitely be improved. Happy to see OpenPGP jump on the scene and tackle the problem.

I'll be looking forward to your draft on the ML, have a nice day!

[albjeremias]

Is there a place specifically to donate to this issue? I'd love to support it!

[Gargron]

A few months ago I tried my hand at adding e2e to Mastodon but got a lackluster reaction from the folks close to development updates. Anyway, the way I tried doing it is adopting the OMEMO way: Devices generate pre-keys, the server lists them on the actor object under each listed device. Sender picks a random pre-key for the device(s) it wants to deliver to, and that is used for establishing a session. Have you considered that approach? How will you handle multiple devices?

[Hasimir]

@albjeremias Just the main donations page, but there's a little message box included which will go to Werner, so feel free to include which bit specifically drew you there. Cheers! 😀 👍

@wiktor-k My GitHub account pre-dates my signing on with GnuPG. I signed up here around 2011 or 2012, I think (too slack to check). Whereas I started contributing there about three years ago, give or take a month or so. That was the original port of PyME from Python 2 to 3 and which Justus subsequently reworked into their current form.

Now that I've resumed maintaining that (and whatever documenting I happen to come across), it'll be a fair bit more consistent from me. That's one reason I started that with the HOWTO for the bindings, to be sure I was up to speed on what Justus did (and it's rather cool). It's actually easier to use and more Pythonic than the more popular CLI wrappers (e.g. Vinay Sajip's python-gnupg module). The irony is that all this work is far more important than the reason I ported PyME in the first place (to securely store OAuth data for a bunch of Twitter scripts).

@Gargon oh dear … the first mistake there was selecting OMemo for the task. 😉

It's been a few years since I looked at their spec, but if I recall correctly, they made some claims which were somewhat disengenuous regarding what they were actually doing. I can't recall the specifics, but I do remember discussing it with Werner and Bernhard on one of the mailing lists, probably gnupg-devel, but maybe -users.

Regarding device specific keys, there are a few ways to handle it and no limit to the number of keys which could be used with an account. Though I expect most people would settle on one or two (e.g. a main key and a remote or mobile device key. In this case the users will actually limit themselves so that they don't have too many passphrases to remember, while still reaping the rewards.

In addition to the discussion that was started with the AS2 and AP designers, which you've seen part of, you'll be receiving a more in depth email from me as soon as I finish drafting it. Actually it's addressed to you and Lain, for reasons which will be really obvious once you read it.

In brief, though, you're not going to have a complex crypto spec to implement entirely on your own. Especially given what we've seen with MUA development and which came to a head a fortnight ago. Though I had intended this before the EFFail situation commandeered so much attention. My plan has always been in roughly two parts:

1. Write a good, solid specification which covers a lot more than just e2e crypto and signing toots/statuses. Though obviously it's an essential part of the whole thing.
2. Provide a JSON-friendly interface to GPGME which any AP implementation can interact with to get the data needed to do the job. This should neatly address the needs of most, if not all, of the client developers too.

That way you can concentrate on the aspects you know best and so can Lain, while knowing that that aspect isn't going to do stupid things. Though there's a secondary reason for keeping it slightly apart as an interface, rather than trying to contribute code directly to either project and that is basically a licensing issue. Since my GnuPG work needs to be part of that project it can't be AGPL, it has to remain under the same licenses as GPGME (GPLv2+ and LGPLv2.1+); by remaining a stand alone thing that Mastodon or Pleroma would communicate with (via HTTP calls or a UNIX socket or whatever) on the same server, all the advantages can still be reaped without rking either project.

Meanwhile, the end users get to see it go from protocol proposal to implemented a lot quicker than would otherwise be the case. As well as having an assurance that said implementation will be completely interoperable between both stacks.

You see, I'm a sneaky bastard, but I (mostly) use my powers for good. More or less. 😉

[wiktor-k]

Regarding device specific keys, there are a few ways to handle it and no limit to the number of keys which could be used with an account. Though I expect most people would settle on one or two (e.g. a main key and a remote or mobile device key. In this case the users will actually limit themselves so that they don't have too many passphrases to remember, while still reaping the rewards.

One way could be having several encryption keys tied to the same master key and using all of them to encrypt the message. OpenKeychain does that, GnuPG only uses the most recent one, the RFC does not specify what to do with multiple valid encryption keys IIRC.

Note that OMEMO also provides forward-secrecy while OpenPGP does not. Whether this is important in case of ActivityPub is another question but I just wanted to highlight this difference.

From what I gather from Ben's messages here his design will be quite simple, that's good, simple is better than complex :)

[mdik]

In case end-to-end encryption would get baked into the actual protocol, I would also rather like to see a more modern approach like OMEMO or Signal.

My original idea was to keep Mastodon, or whichever web application, as little bothered as possible. Maybe presenting OpenPGP messages a little differently in the user interface, maybe exposing public keys as a hidden, but machine-readable part of the user profile/bio, and maybe adding support for the Mailvelope API. The only hard requirement would be extending the default character limit of 500 for OpenPGP messages. And then making use of that through Mailvelope in the browser, or OpenKeychain in the various Android apps. I unfortunately don't know how easy it is to add OpenPGP functionality to iOS apps.

[Hasimir]

@wiktor-k:

One way could be having several encryption keys tied to the same master key and using all of them to encrypt the message. OpenKeychain does that, GnuPG only uses the most recent one, the RFC does not specify what to do with multiple valid encryption keys IIRC.

Actually that can be overridden by specifying a specific subkey ID (or fingerprint) and ending it with an exclamation mark or bang sign (i.e. this thing: !).

Note that OMEMO also provides forward-secrecy while OpenPGP does not.

There are implementations which can provide it for all practical purposes using hidden recipients and/or via a secondary encryption method in the transport.

OpenPGP, however, is not a transport protocol and is designed to protect data when it is mostly at rest. Forward secrecy in that context is fairly moot, but it may be enhanced by utilising the hidden recipients feature (which probably doesn't exist in those web based implementations).

From what I gather from Ben's messages here his design will be quite simple, that's good, simple is better than complex

Yes, but complex is better than complicated. 😉

@mdik:

In case end-to-end encryption would get baked into the actual protocol,

Yes and no; while this is, by necessity, being defined at the protocol level; it is being done in such a way that it won't lock out other cryptography systems just by being the first . The possibility of future development supplanting all current systems has been factored in.

I would also rather like to see a more modern approach like OMEMO or Signal.

When I last looked at OMEMO its authors were making claims which skirted the edges of deceptive claims of its capabilities. I haven't looked back since.

As for Signal; DJB's curves are very nice, indeed OpenPGP supports them too, but Signal is not and cannot be a solution here. The reason for that is that end-to-end encryption is not the only problem which needed solving. There are a few others, including a number relating to verification that an unencrypted status or object has not been modified in transit. That requires a digital signature linked to an identity (including pseudonymous) and a public key.

Then there's the little matter of enabling key exchange. Signal takes care of this by keeping all the users on the one, privately managed network with copies of all the public keys, hashes of all the contact numbers and then matches numbers to contacts in the background with each new connection. It's all nice and simple, but at the cost of end user control of when, how and under what circumstances they access the system.

As for Signal's forward secrecy; yes, technically in the transport phase it does have that, but in a more practical way it fails entirely. For people in countries like mine, where the concept of a “burner phone” is a pipe dream and a government which wants to declare war on maths (the PM is an idiot sometimes, but not as big an idiot as his predecessor was), all it takes is a federal police officer with a list of activists, their contact numbers and a new (undercover) installation of Signal and there's one great big data leak right there (i.e. who has at least installed Signal).

On top of which, it still wouldn't solve all the other problems needed for AS2 and AP issues (this wasn't the only issue number I checked when researching the userbase's requests).

As for the visibility or lack of it of the keys themselves, as with all of AP and AS2, it's only as hidden as people want. It certainly won't be intrusive.

Now, for my own curiosity; why the fixation on Mailvelope and its API specifically rather than the cryptographic protocol it attempts to implement? Is it just that that's how you first encountered OpenPGP messaging? Or is there some specific aspect of their API you use for something else and you're concerned about getting whatever it is in the way you imagined? Or is it that you're not quite sure, but you do know that RESTful APIs are easy to work with and so you want that potential available? Or is it simply that whatever is used, you want to be sure it's accessible via your browser? Or something else?

Because if it's just a specific feature request, chances are it's either already in GPGME or already planned and I know for sure that GPGME can do plenty of things most, if not all, of the other implementations can't. As for REST; some of it can never be genuinely RESTful, but REST-like is already planned. Lot's more JSON style data types for people to interact with via their favourite languages.

Besides, there are specific requirements of at least Mailvelope's key server implementation which would introduce unnecessary constraints on end users. Specifically their arbitrary one key per UID or whatever. There are legitimate reasons for having more than one key associated with a UID, just as there are legitimate reasons for more than one person to have control of a particular key (e.g. software team keys for signing code releases or security advisories.

Finally, regarding support for iOS, I'm unsure of the current state of development there, but I can think of one or two people who might know. I might have to pester them a bit later.

[wiktor-k]

Forward secrecy in that context is fairly moot, but it may be enhanced by utilising the hidden recipients feature (which probably doesn't exist in those web based implementations).

For the record openpgp.js has hidden recipients feature, I've tested it and it works (the parameter is named wildcard, docs).

Besides, there are specific requirements of at least Mailvelope's key server implementation which would introduce unnecessary constraints on end users.

Mailvelope will implement support for WKD that also can be used to discover keys associated with an e-mail address. That'd be an additional method of discovering keys.

Maybe the OP wants Mailvelope because it's super-simple to install for non-technical users and has API that can be used from a web browser? Just guessing...

[mdik]

Yes, exactly. I like it because all the necessary components are already there. For personal messages in Diaspora it already works out of the box. And while WKS/WKD is a well thought-out concept, the Mailvelope keyserver and automatic key-retrieval is functional and operational for over two years now, so even if it wouldn't support WKD, I would choose it in case the keys would not be provided by the Mastodon service itself.

And one key per user id is a very reasonable constraint in my eye, even if not necessary in the strictest sense of the word ¯\_(ツ)_/¯

Or is it simply that whatever is used, you want to be sure it's accessible via your browser?

Excuse me? Yes, of course? I mean, I guess it would be possible to ship all the necessary javascript from the server like OpenXchange Guard, or Protonmail do it, but that would mean that this would have to be integrated with the Mastodon source code, and I personally like the separation of where the web application comes from, and where my OpenPGP.js comes from, although I also see how this is a burden on the user.

Regarding my use of the word "Signal" I have to apologize, I meant it more in the sense of the crypto protocol, with the double ratchet, and so on, not the whole app and message transport business of it.

Still, I don't understand the following statement

There are a few others, including a number relating to verification that an unencrypted status or object has not been modified in transit. That requires a digital signature linked to an identity (including pseudonymous) and a public key.

as both, OMEMO and Signal, make use of persistent identity key pairs?

[Hasimir]

For the record openpgp.js has hidden recipients feature, I've tested it and it works (the parameter is named wildcard, docs).

Excellent. Now all I have to do is convince them to include support for TWOFISH and they'll almost be ready for all of this.

Mailvelope will implement support for WKD that also can be used to discover keys associated with an e-mail address. That'd be an additional method of discovering keys.

Yeah there's a lot of planned Mailvelope work this year, but I can't discuss that at this point in time.

Maybe the OP wants Mailvelope because it's super-simple to install for non-technical users and has API that can be used from a web browser? Just guessing...

Indeed, but what it sacrifices for that convenience is … considerable. Which is why it should be a final fallback if all else fails, rather than the preferred solution and certainly not the only solution.

[Hasimir]

Yes, exactly. I like it because all the necessary components are already there. For personal messages in Diaspora it already works out of the box. And while WKS/WKD is a well thought-out concept, the Mailvelope keyserver and automatic key-retrieval is functional and operational for over two years now, so even if it wouldn't support WKD, I would choose it in case the keys would not be provided by the Mastodon service itself.

The SKS keyserver pool is functional, can provide automatic key retrieval (assuming network connectivity) can be deployed locally as a private server, syncs with the rest of the network to ensure fidelity of data and has been operating for over two decades if we count from the original server (still running) at pgp.mit.edu. It also does not centralise power in the hands of one company.

Mailvelope's solution, which they cribbed from Hushmail, by the way, does all those less than ideal things. As for Hushmail, the reason they're considered a joke these days is because they exploited their own JavaScript interface to intercept passphrases of a number of their own customers at the behest of the USA (specifically for the FBI and DEA during the Farmers' Market investigation).

Now Mailvelope are setting up a lot of the same things. Not that that means they'll do the same thing as Hush, they probably won't or at least won't want to. The same is true of ProtonMail, who I've already gone all inquisitorial on with the Hushmail comparisons. Fortunately they had some good answers.

Still, centralising power with a single point of failure seems foolish when it would serve the network, and everyone participating in it, far better if it resided with those people instead. It's, you know, federated … 😉

And one key per user id is a very reasonable constraint in my eye, even if not necessary in the strictest sense of the word ¯_(ツ)_/¯

Uh-huh. So which key takes priority? The first uploaded to that server or the most recent?

Not to mention the little point of having one main key for comms, as is the case for me, but various roles: personally, politically and professionally. In my case the first two UIDs are personal, the next two are political (one of them is revoked), the one after that is a concession to one of the flavours of the month and the last is professional.

My Key ID is 0x321E4E2373590E5D (minimised version from my server) and the full fingerprint is DB4724E6FA4286C92B4E55C4321E4E2373590E5D (full version from the SKS pool). You tell me, which UID should be the One True UID™ and factor in that I'm the registrant of the domain in the first UID, but other keys for that address exist (and the same is true of the backup address in the second UID).

Be careful when researching this; you may also find keys which are not and were never mine, but have my name and email on them. A close examination will help identify those and this tool is invaluable and a lot easier to read than gpg --list-packets is.

Excuse me? Yes, of course? I mean, I guess it would be possible to ship all the necessary javascript from the server like OpenXchange Guard, or Protonmail do it, but that would mean that this would have to be integrated with the Mastodon source code,

To an extent, for the most part it only really needs to initiate calls to a local crypto interface based on interaction with the web interface. That sort of thing could be some kind of scripted hook or as alightweight as REST-like API call (and very probably will be).

For the most part, though it probably won't be so closely intertwined since there is no reason for fediverse end users to keep any private key data on the server. Their public keys, certainly, but not their private keys.

and I personally like the separation of where the web application comes from, and where my OpenPGP.js comes from,

Ah, so would you reconsider if it were possible to invoke the GnuPG software drom within the browser in such a way that the only thing you might ever be prompted for was a passphrase to sign or decrypt and in doing so only had to deal with the gpg-agent pinentry dialogue?

Especially since it sounds like you've been customising your own OpenPGP.js implementation. I can understand the temptation, especially if you want something that will just work in multiple settings (i.e. devices), but surely it would be preferable to have the best options for each platform rather than selecting the lowest common denominator just for a homogenous feature set and behaviour?

Then, of course, there are other opportunities for tinkering. In fact, if my quick glance at your profile here is accurate enough, you've spent at least a little time wandering down a Pythonic path already. If that'sright and you didn't turn from it entirely then I think you'll get something out of this eventually (or even now, really; the focus is Python 3.4+, 2.7 is supported, but really it's time to move forward).

although I also see how this is a burden on the user.

Which is why redundancy in implementations for client side functions (which will be the majority) is pretty much required. I would expect OpenPGP.js to have a role in that, but probably more as a final fallback; exceptwhere that was explicitly overridden by an end user. Specific client software could be configured with all sorts of things, while the web interface could try a few options in the order which follows a path of most secure and recommended implementations to weakest.

It is, of course, on that basis that JavaScript implementations of any type end up last on the preference list because JavaScript has no PRNG to draw upon directly (which is also why ProtonMail farms out a lot of calls to the browser and the OS). The best you can achieve with OpenPGP.js with regards to security is what ProtonMail is already doing and even they admit they have their weaknesses. The same is true with other OpenPGP implementations, including OpenPGP.js and Mailvelope.

However there will always be those facing a far more dangerous threat model than many. It's in anticipation of that (or recognition of those already present) that the design concentrates on proven crypto systems for the use case, with multiple means by which solutions may be implemented. Even while not ruling out future advances or alternative proposals. Yes, that's guaranteed, and it's one of the other advantages of defining things as an extension to a protocol rather than simply designing one particular software architecture or stack.

Finally, the majority of this data, when it needs to be protected, is at rest; either at its node of origin in a collection or having been delivered to its destination. The transport is taken care of by the instances themselves and they're already using TLS for that. We can quibble over TLS and the CAs 'til the cows come home, but the fact is it's here to stay. With that done, one must then turn to those security data integrity issues that can't be addressed by the current specifications and OpenPGP meets all of them because it's done it before.

Forward secrecy might be an exception in a pedantic sense, but less so in a practical sense because:

1. ActivityPub will always reveal far more metadata about most interactions than anything you might get from a key packet or an encrypted packet.
2. You can still hide the recipients.
3. Creating a key for a pseudonymous identity is dead simple. As this example demonstrates.

Regarding my use of the word "Signal" I have to apologize, I meant it more in the sense of the crypto protocol, with the double ratchet, and so on, not the whole app and message transport business of it.

Ah, right, in that case you probably could shove anything through a, for lack of a better term, transport tube that was made that way, but there's hardly any point when it's also going to have a TLS encapsulation for delivery and, that being the case, it can also be piped or redirected throughany VPN, SSH tunnel or Tor connection and possibly i2p too (but I haven't played with that in years, so I can't guarantee it).

Still, I don't understand the following statement

[SNIPPETY]

as both, OMEMO and Signal, make use of persistent identity key pairs?

Never mind, your previous comment regarding bits of Signal that you're really interested in render this part of the discussion largely unnecessary. Basically it would have boiled down to, when was the last time you were able to use those persistent keys for anything other than Signal comms? Not to mention manage key exchange of the public key material outside of the Signal network?

For the majority the answer to both of those questions is, "never." Including me, I should add.

On the other hand I have successfully sent and received OpenPGP encrypted SMS messages (yes, SMS; not MMS) using a crappy old Android phone with an SMS gateway installed on it and a bit of Python pulling it all together. Mainly just to see if it would work and, clearly it did.

[mdik]

The SKS keyserver pool is functional, can provide automatic key retrieval (assuming network connectivity) can be deployed locally as a private server, syncs with the rest of the network to ensure fidelity of data and has been operating for over two decades if we count from the original server (still running) at pgp.mit.edu. It also does not centralise power in the hands of one company.

The only thing the SKS keyserver pool is good for, is updating keys you already have the fingerprint for, and that can hardly be described as "automatic key retrieval" in the general sense that you can use the Mailvelope keyserver for.

Uh-huh. So which key takes priority? The first uploaded to that server or the most recent?

After the key is verified, you have to delete it (and verify the deletion via email) before you are able to upload a new key, which then again is verified via (encrypted) email before it becomes available.

You tell me, which UID should be the One True UID™ and factor in that I'm the registrant of the domain in the first UID, but other keys for that address exist (and the same is true of the backup address in the second UID).

The user ids are all fine. It only gets tricky if there are multiple keys for one user id.

By default I would generate one key with one user id that may be shared over all devices, and I would restrict it to the use with Mastodon. Use with email may very well be possible, and might be even convenient if Mastodon user id and email address are the same, but that should be a secondary concern.

To an extent, for the most part it only really needs to initiate calls to a local crypto interface based on interaction with the web interface. That sort of thing could be some kind of scripted hook or as alightweight as REST-like API call (and very probably will be).
[…]
Ah, so would you reconsider if it were possible to invoke the GnuPG software drom within the browser in such a way that the only thing you might ever be prompted for was a passphrase to sign or decrypt and in doing so only had to deal with the gpg-agent pinentry dialogue?

Yes, but how would you initiate those calls to the local crypto interface from within the browser?

[Serkan-devel]

Does it still require a browser plugin to use this encryption?

[mdik]

yes!

it is conceivable to implement it all server-side like e.g. openxchange or protonmail offer, but in general it is a good thing that the end-to-end encryption is separated from the rest of the server-side things!

[Serkan-devel]

@mdik that might make viewing encrypted messages on mobile browsers incredibly hard.
On the minds social network, there is an encrypted chat option, which one needs to password protects separately from the login and is encrypted on the server here.

Maybe if one uses Subresource integrity, one could verify that for example the messanger component hasn't been tampered with.

Could one maybe try out web crypto for the client-side when it arrives on all browsers?

[Serkan-devel]

Wait, web crypto seems to be on almost all browsers https://caniuse.com/#feat=cryptography

[mdik]

For mobile use, I'd assume that most people use one of the many apps, like Tusky, but yes, you're right!

[Serkan-devel]

@mdik tusky is buggy, and I'd like to use all features on the webpage just like on the app. It also saves storage space by not using an app, but a Progressive web app instead, which is a persistent offline web app that can be placed on the homescreen

[Hasimir]

@Serkan-devel I've been able to get both GPG and GPGME (including the Python bindings) to run on a non-rooted Android phone, so getting that to the point of "install this app" and preconfigure it to use curves by default to reduce the CPU hit is just a matter of time.

That still leaves the iPhones and Windows phones, of course, but I don't have either to play with. That first effort was just to see if I could without deactivating my banking apps ... and yep, that's 100% success.

[wiktor-k]

OpenPGP.js uses WebCrypto whenever possible and works great in browsers (and it's also used by Mailvelope and ProtonMail). A bridge to local GnuPG would be very helpful for security minded people.

As for the key retrieval and Web Key Directory, Mailvelope extension itself will support WKD in near future and I think this is particularly good match for Mastodon as the keys are stored on the same server. WKD looks a lot like WebFinger but for keys.

[Serkan-devel]

@Hasimir it still renders iPhones and mobile browsers useless for encryption. That's not 100% success

[Hasimir]

Sigh.

In the context of what was being tested, it is – I did specifically say Android phones. As for the iPhone, I'd take a crack at it if someone will donate the hardware. There's a reasonable chance of getting it to work there too since I'm already compiling the stack with XCode most of the time anyway. Still not sure on Windows, but there's a lot of issues there with multiple runtimes and that's not limited to mobile devices either.

[Serkan-devel]

@Hasimir will mobile browsers be left out?

[Hasimir]

Not if I can help it, no.

[Serkan-devel]

Maybe one could implement encrypted chat without any extensions and use addons to provide more security, while making backwards compatible to the browser version

[Serkan-devel]

*it

[Hasimir]

You know you can edit a comment if you spot a typo, right? ;)

Anyway, that level of approach is for implementation. Protocol design or extension is a little different. So while the issues affecting mobile devices won't be disregarded, they also won't be defining the entire approach (i.e. security won't necessarily be sacrificed for the convenience of all mobile devices). There should still be a quite viable middle ground (e.g. not going with .js solutions, but still selecting algorithms which don't cripple ARM processing power).

[Serkan-devel]

@Hasimir how would it work with webassembly? But not every browser supports it, especially older browsers

[Hasimir]

Some of that might require additional testing, but essentially by running a local service which acts as a bridge between the browser and the GnuPG API (i.e. GPGME). The browser then communicates with that service via a more familiar protocol (e.g. a REST-like series of calls).

Oh, I've tested that too, but not yet on a mobile device. It should work, though since other things using the same principals already do too.

[Serkan-devel]

@Hasimir but that might still require an app to run in the background, or can it be used just for enhancement?

[Hasimir]

It probably would require a means of running in the background, but it could be sandboxed just like browsers are already. Ideally you'd want it separated from the browser to an extent anyway, it would after all be managing secret keys. The last thing people really want is browsers handling it directly, they don't have the computational tools to handle it (which is why they fall back on kludges ... like every attempt to implement crypto in JavaScript ever written).

[Serkan-devel]

https://github.com/tootsuite/mastodon/issues/8123
There is already a zero-knowlage cloud service without needing any addons on the browser and properly encrypts everything on the client-side

[Hasimir]

This CryptPad suffers from the same types of flaws as Mailvelope, though it's taken the NaCl/Sodium option for algorithm selection (i.e. elliptic curves for everything).

The weak point being that it's implemented in JavaScript which is fundamentally incapable of producing strong or sound cryptography because it is incapable of performing the mathematical computation necessary and it is completely incapable of the pseudo-random number generation necessary to generate strong prime numbers for key generation.

Why did you think every bank goes to the effort of producing and maintaining custom apps instead of just recommending browsers like they do for laptops and browsers? It's not out of a desire to enter the consumer software market, it's because they know the smartphone limitations mean those browsers don't meet minimum security requirements.

From my POV, if it's not good enough just to meet banking minimum standards to prevent identity theft or a few too many chargebacks, then it's definitely not something I'd trust my life on. That being the case, why should I expect anyone to trust their lives on it? Or their freedom? Or both?

Your threat model might not need to factor in threats to life and, hey, if that's the case then good for you, that's great. Not everyone's in the same position, though, and right now there's an instance in the fediverse with over 120,000 users, the vast majority of which are facing threats to their lives, freedom and everything in between.

By the way, if you skip down to the encryption section of the CryptPad documentation you can see that they freely admit that their encryption implementation is one of the weakest forms possible. Specifically that they use a single shared key amongst all the recipients and how secret is that key? It's embedded in the URL. Now granted, it does have one for read only access and another for editing, but that's essentially the sole limit of the protection it provides. It doesn't even have a means of proving whether or not contents were tampered with without utilising some external method of verification.

Since everything in ActivityPub is a combination of URLs and JSON data, using this system for creating encrypted private messages would mean that the sole obstacle to intercepting those messages would be determining the URL of each message and those URLs will be referenced elsewhere.

Using CryptPad for the purpose you seem to think it ideal would be more damaging than doing nothing as it may result in people believing their communications were protected when they're not.

[wiktor-k]

Small update, Gpg4Win 3.1.3 changelog contains this piece:

Installer: New optional module "Browser Integration" to register GnuPG as backend for Mailvelope 3.0.

So it appears it will be possible to use system keys from GnuPG in a browser!

[ross-at-ormo]

Does integration with the system gpg keyring work? I can see that gpg4win has registered a Native Messaging Host with Chrome which should allow the Mailvelope extension to integrate with system gpg keyring but does this functionality even exist within Mailvelope? Maybe when they refer to "Mailvelope 3.0" they are insinuating that this functionality needs to be added to the extension, given that the current Mailvelope is version 2.2

[wiktor-k]

Maybe when they refer to "Mailvelope 3.0" they are insinuating that this functionality needs to be added to the extension, given that the current Mailvelope is version 2.2

That would be my guess too. There is also this repository: https://github.com/mailvelope/gpgmejs that confirms some integration is being worked on.

[toberndo]

The GnuPG integration is already fully functional in the current beta2: https://download.mailvelope.com/releases/v3.0.0b2/
Final release of Mailvelope 3.0 is scheduled for November.

[Hasimir]

The second draft of my proposed protocol extension of ActivityStreams 2.0, ActivityPub and OpenPGP was announced publicly on gnupg-devel for review and comment last month and the actual protocol extension specification is here.

The design is software agnostic in that any properly compliant implementation of the OpenPGP protocol could be used.

[Gargron]

Duplicate of #1093