[HN Gopher] Disclosing E2EE vulnerability in multiple Matrix cli...
___________________________________________________________________
Disclosing E2EE vulnerability in multiple Matrix clients
Author : Sami_Lehtinen
Score : 253 points
Date : 2021-09-13 15:45 UTC (7 hours ago)
(HTM) web link (matrix.org)
(TXT) w3m dump (matrix.org)
| jaimehrubiks wrote:
| Any recommendation to get started with matrix? Like use cases,
| featured clients, interesting public chats, or similar? To
| someone whose close environment does not use it
| kiliankoe wrote:
| If you're looking to get started using Matrix, but have no
| contacts to bootstrap it with, you can look into bridges to
| other networks or using something like beeper.com with hosted,
| well-supported bridges.
|
| Disclaimer: I work @ Beeper
| ptman wrote:
| I'm partial to the guide I wrote
| https://matrix.org/docs/guides/free-small-matrix-server/
| zeroping wrote:
| The reference clients and server are a good place to start.
| They're the place to find all the protocol features implemented
| and well supported.
|
| The Element client (desktop/web/android) is electron-based
| https://element.io/get-started Synapse is the server to start
| with https://github.com/matrix-org/synapse/
|
| From there, what's the first place to find people to chat? I
| don't have a good answer there, but the 'spaces' functionality
| is a nice way to group communities.
| preya2k wrote:
| I assume you meant the "spaces" functionality to group rooms?
| zeroping wrote:
| D'oh, yes I did. Thanks.
| galbar wrote:
| I started by setting up a synapse server (with docker it is
| quite easy, although reading all the config options takes some
| time). I already had a server with docker services running
| there, so deploying an extra container was easy for me.
|
| I started trying it, with the Element.io apps and convinced a
| techy friend to try it. Since then, he set up his own server
| and we have a group of friends that we mainly communicate
| through matrix. Also, I try to use it with my parents. They
| want to use it, but end up writing to me through WhatsApp out
| of muscle memory.
|
| After some time I started looking at public rooms that I'd be
| interested into, available in matrix.org or matrix.feneas.org.
|
| The easiest way to start, though, is to create a free account
| in the matrix.org public server using the webapp[0].
|
| [0]: https://app.element.io/#/register
| callahad wrote:
| As for interesting public chats: Quite a lot of the free
| software community is on Matrix these days; check out projects
| you're interested in and see if they have a Matrix link.
|
| For example, the NixOS community has a curated Matrix Space
| linked from https://nixos.org/community/index.html with lots of
| rooms to explore. GNOME, KDE, and Mozilla also have a
| significant presence on Matrix.
| mxuribe wrote:
| The comments that others suggested would be good, or of course
| there's also the "Discover Matrix" page:
| https://matrix.org/discover/
| fouc wrote:
| > trick vulnerable clients into disclosing encryption keys for
| messages previously sent by that client to user accounts later
| compromised by an attacker.
|
| Doesn't the fact there's some kind of mechanism or expectation of
| sending encryption keys willy nilly imply a flaw with the
| protocol perhaps?
| pkulak wrote:
| > willy nilly
|
| It's not though. The fix is to cryptographically verify
| requesting clients before sending.
| aidenn0 wrote:
| They address this in the last two paragraphs of the article.
| Joe_Cool wrote:
| If "send key to all members of channel x" is enabled it would
| be good if that would work.
|
| You can set it to "only other clients and people I have
| personally verified" but that is quite cumbersome for big
| channels that just don't want clear text.
| pkulak wrote:
| I'm a tad worried about getting rid of key-sharing. I seem to use
| this every once in a while. Pretty much any time I use a client I
| haven't used in a while. I guess I could just get the keys from
| the backup, but then I need to have THAT key, which is a bit
| inconvenient.
| Arathorn wrote:
| This is a great example of why key-sharing exists today... and
| why it shouldn't. In theory, you _should_ be able to pick up
| and old client and decrypt new messages and history on it
| absolutely fine. However, in practice, Matrix 's E2EE publishes
| 100 one-time keys (OTKs) on your server to let other devices
| establish secure 1:1 channels with you if you're offline - and
| if you go offline and that pool of OTKs exhausts, then new
| sessions won't get set up and you won't receive keys for new
| messages... giving the misbehaviour you're seeing.
|
| Now, you're right that key-sharing is a useful way to fudge
| around that failure mode.
|
| But an even better way to fix it would be to find a way to stop
| the OTK pool exhausting - and that's precisely what MSC2732 is:
| https://github.com/uhoreg/matrix-
| doc/blob/fallback_keys/prop.... This provides a last-ditch key
| which can be used to set up 1:1 sessions even if you run out of
| OTKs, which is _marginally_ inferior to using a different OTK
| every time, but in practice really isn 't a disaster (see the
| MSC for details).
|
| However, fallback keys are relatively new and aren't
| implemented on all clients yet (matrix-js-sdk has them, but
| matrix-ios-sdk is implementing this coincidentally this
| week)... and so until they land, we still need keyshare
| requests to paper over this limitation.
|
| But in future, hopefully it will be almost unheard-of to need a
| keyshare request, and we can change them to be an entirely
| manual or out-of-hand mechanism of some kind, and avoid classes
| of bugs like the vuln in question here in future.
| pkulak wrote:
| Thank you for writing that all out. I wasn't familiar with
| most of these details.
| e12e wrote:
| > In theory, you should be able to pick up and old client and
| decrypt new messages and history on it absolutely fine.
|
| No? Assume the lost/stolen/forgotten device has outdated (or
| no) protection around its keys - and it should be rotated out
| as soon as possible?
|
| I'd rather not have to worry about if my old phone is in my
| drawer at home, or in an mi6 office (or more likely, with an
| estranged spouse or a journalist)?
| Arathorn wrote:
| if you think the device has been lost then you should
| obviously kick it off your account immediately, and it'll
| be immediately rotated out of all the conversations it was
| in.
|
| otherwise, do you _really_ want to rely on the OTK pool
| exhausting as a very handwavey way to provide post-
| compromise security? A much better solution would be to
| have a firmer metric for your server to explicitly kick out
| your devices after N days of inactivity. Relying on some
| weird bug like OTK pool exhaustion for security purposes is
| horrible.
| e12e wrote:
| Belt and suspenders. It should be possible to kick a
| device, and be a timeout.
| Arathorn wrote:
| It is already possible to kick a device (go to Settings:
| Security in Element, for instance).
|
| I've filed an issue at https://github.com/matrix-
| org/synapse/issues/10813 for inactivity timer logouts.
|
| However, my point still stands that fallback keys are a
| good idea - you should kick the device out deliberately
| (manually or with a timer) rather than rely on a protocol
| quirk meaning that E2EE randomly breaks after some period
| of inactivity(!)
| e12e wrote:
| As long as the timer is passive (key expires) rather than
| active (key expunged).
| criticaltinker wrote:
| > 100 one-time keys (OTKs) on your server
|
| Is 100 a safe default for devices with limited memory, or are
| there other more salient constraints that I'm ignorant of?
| Arathorn wrote:
| Each OTK is a Curve25519 key (or ed25519 key, i forget) -
| so 32 bytes. So 100 takes up 3.2KB of storage on each
| client for the private keys, and the same on the server for
| the public keys, so it's not a big concern :) We could do
| bigger pools, but it's just punting the problem.
| m-p-3 wrote:
| Still haven't received the up-to-date version from F-Droid, which
| is still stuck at 1.2.0. They really should have some provision
| to expedite a release when a serious security flaw is discovered.
|
| Not the Matrix team's fault, but still a bit worrying. Maybe they
| could implement their own F-Droid repo to skip the F-Droid build
| server?
| progval wrote:
| Or they could coordinate with the F-Droid packagers, like they
| did for other distributions. (Actually they might have, since
| they don't exhaustively list them)
| callahad wrote:
| Element did coordinate with the F-Droid packagers on behalf
| of both Element Android and SchildiChat.
|
| Because F-Droid runs their own builds and requires published
| source code, there is no mechanism for pre-building and
| staging security releases for issues which are not yet
| publicly disclosed.
|
| That said, the packager was extremely helpful and prepared
| the metadata updates in advance to ensure that both
| applications could enter the build queue as quickly as
| possible upon release:
|
| - Element 1.2.2: https://gitlab.com/fdroid/fdroiddata/-/commi
| t/76c8f5b87aa8df...
|
| - SchildiChat 1.2.2.sc43: https://gitlab.com/fdroid/fdroiddat
| a/-/commit/232b316f8affe0...
| nybble41 wrote:
| > Because F-Droid runs their own builds and requires
| published source code, ...
|
| That seems... completely reasonable for distributors of
| open-source projects. Mandatory, even, for compliance many
| open-source licenses. Are you saying there are other open
| source repositories (e.g. Linux distros) which would _not_
| require published source code before distributing binaries?
| callahad wrote:
| I wouldn't go that far. What I meant is more that Element
| would've been willing to share our private source tree
| for Element Android 1.2.2 with F-Droid several days in
| advance of disclosure, if it meant that they could pre-
| build the binaries and have them ready to ship the moment
| that the source was made public.
|
| (After verifying that the public source is identical to
| the privately shared copy, of course.)
| m4rtink wrote:
| Do you need a full source tree for this ? IIRC major
| Linux distros do this via preliminary disclosure to a
| private mailing list possibly with a patch attached.
|
| That way distros can do a local build to verify the patch
| works and fixes the issue & they then apply the patch in
| their public infra right after the embargo runs out.
| hrfbi wrote:
| The fdroid maintainers are... Less than competent. I recommend
| anybody not to use the main repo at all if they care about
| security, as any update could take _weeks_ to arrive.
| codetrotter wrote:
| Probably they are just overworked and understaffed. Possibly
| also lacking money for more/beefier build-servers?
| SubzeroCarnage wrote:
| F-Droid maintainers are solely a volunteer effort. The CI
| helps a lot. The biggest slowdown in the chain is the manual
| offline signing step.
|
| You can see here the history https://gitlab.com/fdroid/fdroid
| data/-/commits/master/metada...
|
| You can donate to support them here
| https://opencollective.com/f-droid or here
| https://liberapay.com/F-Droid-Data
| Arathorn wrote:
| F-Droid do the builds rather than Element (or other Matrix
| client vendors), so the whole thing is at the mercy of the
| F-Droid CI process. The Element Android build has entered the
| queue apparently, but not landed yet. We alerted the F-Droid
| team last week to prepare for the release, but beyond that
| there's not much we can do.
| m-p-3 wrote:
| I understand that it's out of your control, and you even gave
| them a heads-up. Thank you for your work :)
| vanous wrote:
| F-droid is a blessing and a curse. Many devs experience this
| 'F-droid catching up with releases' due to the manual signing
| process. The userbase is always confused about that.
| Reproducible builds are claimed to be the possible solution but
| almost nobody is doing that due to the complex setup.
| smichel17 wrote:
| Are reproducible builds the solution? Seems like the fdroid
| folks would still have to build ("reproduce") the apk to
| verify that it matches the one provided by the developer.
| Then they'd sign it and distribute the double-signed apk.
|
| I was under the impression that reproducible builds guard
| against the "fdroid build servers got compromised" attack
| vector, (or "developer got compromised", as compared to dev-
| signed releases) and nothing else.
| danhor wrote:
| My understanding is that the level of trust toward the
| build server can change.
|
| Currently, most things are signed by F-Droid, so
| distributed building is harder. But later less trusted
| servers could build the apps and check, leading to a
| consensus system.
| remram wrote:
| > Matrix supports the concept of "key sharing", letting a Matrix
| client which lacks the keys to decrypt a message request those
| keys from that user's other devices or the original sender's
| device.
|
| I'm a bit curious why you'd ever need to request those keys from
| somebody else, in addition to your own devices (or your
| homeserver, where they'd be stored encrypted by a key known by
| your own devices).
| Arathorn wrote:
| The recommendation is that devices only accept requests to
| share (forward) keys from a) other devices belonging to that
| user, b) the device which originally send the message.
|
| It's acceptable to gossip keys between your own devices
| (assuming you authenticate them correctly!) given... they're
| all your own devices.
|
| It's also acceptable to request the sender to re-send the keys
| to you, given the sender knows for sure whether you were
| allowed to receive the key (given it made that choice in the
| first place).
|
| It's not acceptable to request keys from other devices in the
| room, as they won't necessarily know whether you were actually
| allowed to receive the message key you're requesting - only the
| sender knows for sure whether it should have been sent to you;
| it was their key after all. Plus it would risk make
| vulnerabilities like the one in question here even worse, given
| anyone could try to exfiltrate messages from anyone else,
| rather than "just" the sender (as was the case here).
| Youden wrote:
| Imagine you're a "normal" person who has a phone and doesn't
| really use a computer. You lose your phone and want to retrieve
| the history of a chat you had with your friend on the new
| phone. You ask your friend to send the key to your new device.
| remram wrote:
| That sounds like a manual process that would not be part of
| the automated "key sharing" functionality as described.
| xiaomai wrote:
| What are people using for a self-hosted "slack" type messenger
| these days? I have looked at Matrix (which I am interested in but
| I think needs time to settle right now), Zulip (I really like
| their threading model but it has been confusing for other people
| I have tried it with), Rocket chat (only recently aware of this
| one). What else is there? Anyone have good/bad experiences with
| any of these?
| mxuribe wrote:
| > ...I think needs time to settle right now...
|
| I hear this on occasion (though more rarer nowadays than in the
| past)...But curious, is there something specific that you're
| finding in matrix that is not yet settled? By all means, the
| beauty of open source stuff is that you get to choose whether
| you (and your circle of contacts) uses zulip, mattermost,
| etc...So, i encourage you to use whatever open source offering
| gives you (and your circle of contacts) what is needed/desired.
| But with me being such a fanboy of matrix, i always get
| curious. Would you care to share specifics?
| cyberlurker wrote:
| Mattermost is okay
| dbrgn wrote:
| Yeah, I have good experiences with Mattermost (bundled with
| GitLab) as chat for a hackerspace/makerspace. As long as
| you're OK with unencrypted push messages, building your own
| version of the app and keeping it up to date is horrible.
| (React native levels of horrible.)
| nightpool wrote:
| With the recent dust-up around protonmail's "end-to-end
| encryption", it's hard for me to believe that the hammer isn't
| going to come down on Matrix in a similar way. Nobody has
| seriously turned their attention to the compromised-homeserver
| issue, even though that's the only threat model under which e2ee
| makes sense. Expecting users in hundred-person group chats to
| manually verify each other individual user's keys is nonsensical.
| And even a single unverified key means that their homeserver
| operator could be listening in. I feel like Matrix should move
| more towards emphasizing how easy it is to self-host and maintain
| control of your own Matrix data, making e2ee is a non-issue.
| ajconway wrote:
| The possibility to perform manual or semi-automated (QR code)
| key verification is still useful.
|
| 1. Those who care about encryption are able to verify their
| keys.
|
| 2. The service can't implement mass-surveillance in secret if
| there are at least two random users who verify their keys.
| dkasak wrote:
| Realistically, when would you be in a hundred-person encrypted
| group? Mostly this is the case when you're a member of some
| kind of organization, and there are ideas how to solve this
| case without pairwise verifying all participants (e.g. by
| delegating trust through a single trusted person such as the
| CEO, reducing the number of verifications necessary from
| N(N+1)/2 to N). Even without this, fully verified E2EE is still
| feasible and useful for smaller groups.
|
| And even if you own the homeserver, you still want E2EE since
| you don't want the data to rest in plaintext server-side.
|
| However, there is work currently being done to make it feasible
| for every node to also be its own homeserver, via P2P Matrix
| (https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix).
| schmorptron wrote:
| At uni, it's common to have whatsapp groups for classes,
| which tend to be encrypted 100 to 200 people WhatsApp groups.
| nicoburns wrote:
| How important is it for these kind of groups to be E2E
| encrypted though? If you're sending a message to 100 people
| then you probably ought to consider it de facto public even
| if only the intended recipients receive it.
| zaik wrote:
| How many of those have verified all the public keys? If you
| never do verification e2ee is basically meaningless.
| smichel17 wrote:
| "You can fool some people sometimes, but you can't fool
| all the people all the time."
|
| If you don't verify the keys, e2ee is basically
| meaningless _against targeted surveillance._ As long as
| some fraction of people verify keys, it is still
| effective against mass indiscriminate surveillance.
| nightpool wrote:
| how is e2e better against mass indiscriminate
| surveillance than just normal TLS? The only time when e2e
| is meaningfully different then https is when the server
| you're talking to (i.e. your personal matrix homeserver)
| is compromised. In that case, aren't you already in the
| realm of targeted surveillance?
| smichel17 wrote:
| Some homeservers are larger than others (e.g.
| matrix.org). They don't _all_ need to be compromised to
| enable mass surveillance. It also depends on where TLS is
| terminated. If you 're running a homeserver on AWS or
| something behind their load balancer, there's a
| difference.
|
| Generally, I'd argue that E2EE provides defense in depth
| against "unknown unknowns" if server infrastructure is
| compromised by any means. Although I do acknowledge it
| adds one more level of complexity, and often another 3rd
| party dependency (presuming you're not going to roll your
| own crypto), so it's not a _strict_ positive.
| ncmncm wrote:
| Serious question, if a surveillance organization had
| control of a certificate authority trusted by your
| client, would that allow them access to traffic whose
| security relied on a certificate from that authority?
| SahAssar wrote:
| By that logic the vast majority of users of whatsapp,
| signal and most other e2ee protocols/apps use it in a
| useless way, right? Most people I know who use these apps
| (even the security-conscious ones) never verified the
| key.
| nicoburns wrote:
| Yes, pretty much.
| BHSPitMonkey wrote:
| Signal tells you outright when someone's key has changed,
| though. It's usually pretty trivial to establish that the
| original conversation is authentic when you're just
| talking with people you know in real life (where an
| impersonation attempt would likely fail for numerous
| reasons), and you can assume that device is still theirs
| until their key changes.
| nybble41 wrote:
| There is still a risk that someone is running a MITM
| attack. The initial conversation would be authentic, but
| the key belongs to someone else who is just forwarding
| the messages. Your communications would no longer be
| private and they could switch from passive eavesdropping
| to impersonation at any point without changing the key.
| ncmncm wrote:
| It used to tell you. Does it, still?
| COGlory wrote:
| What dustup around end-to-end encryption? I'm only familiar
| with ProtonMail's IP logging controversy. I was unaware it
| impacted E2E at all?
| [deleted]
| miloignis wrote:
| Even if it's not currently practical for 100 person group
| chats, verifying each other's keys is quite practical for 1on1
| or other small groups of say 10 people or so, and you get a
| great benefit from doing so! Two normal users could use any
| matrix server, including the huge matrix.org one, and
| communicate privately in a direct chat with peace of mind.
|
| Of course, I think self-hosting and decentralizing the servers
| is very important and good work too!
| Youden wrote:
| > I feel like Matrix should move more towards emphasizing how
| easy it is to self-host and maintain control of your own Matrix
| data, making e2ee is a non-issue.
|
| Matrix is way ahead of you. There's ongoing work to build P2P
| clients [0]. That is, each phone/device can be its own home
| server. The latest update was in May [1].
|
| [0]:
| https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix
|
| [1]: https://matrix.org/blog/2021/05/06/introducing-the-
| pinecone-...
| progval wrote:
| It still does not solve key distribution.
|
| Matrix P2P removes the homeservers, but clients are still
| talking to each other through some medium that can
| impersonate them.
|
| There's really no magic solution to solve this, you need
| either a trusted third-party (such as Certificate
| Authorities, who are expensive) or a Web of Trust
| (impractical for users).
| Arathorn wrote:
| Matrix's existing E2EE has identity verification as
| effectively one- or two-hop web-of-trust using QR codes or
| emoji comparisons. It's not impractical for users, because
| everyone's familiar these days with scanning a QR code as a
| mechanism for logging into an app (c.f. Discord, WhatsApp,
| Signal etc). So as long as you scan the people whose
| identity you care about, you're sorted, and it's _much_
| easier for normal users than the clunky old PGP signing
| parties of years gone by (plus it doesn 't leak as much
| metadata, given it's just one or two hops of trust).
| brunoqc wrote:
| Can we get a arewep2pyet.org ? Maybe the wait would be
| more bearable ;)
|
| Or if you prefer threats: "If I die from covid before
| matrix p2p is a thing, my ghost will haunt you for
| evar!".
| Arathorn wrote:
| excellent idea - have registered :)
| vbezhenar wrote:
| For me it looks very weird and defeats the whole purpose of
| Matrix. I mean: it was designed from the ground as a
| federated network, similar to E-mail. Turning it into a
| completely different topology will not end well. If they want
| a P2P client, they should design it from the scratch.
| Otherwise it'll end up as a bunch of hacks glued with tape.
| Arathorn wrote:
| It wasn't designed exclusively as a federated network, tbh
| - we've been planning for P2P since pretty much day one; ht
| tps://matrix.org/~matthew/2016-12-22%20Matrix%20Balancing%.
| .. is a talk I gave in 2015 when Matrix was less than a
| year old on our plans to go P2P.
|
| Personally, I think it's _really_ nice that in P2P Matrix
| precisely the same client-server API is used as for normal
| Matrix, so all the work that goes into the Matrix client
| and E2EE etc is preserved without any changes at all.
| Instead, it just talks to a server running on localhost,
| which then replicates traffic around over the P2P overlay
| (in future using store-and-forward servers if the target
| server is offline). It 's really not a bunch of hacks,
| thanks to Matrix being architected to make the replication
| transport & protocol pluggable from the outset.
| m4rtink wrote:
| That sounds very promising! Having two mobile devices with 5+
| radios (2G, 3G, 4G, wifi, Bluetooth, NFC, ...) inside 5 cm
| from each other yet they can't easily talk directly to each
| other in a user friendly way is such a fail!
|
| Like really, my Palm TX could do that via infraport!
|
| So any effort to break this stalemate makes me very happy. :)
| liotier wrote:
| > Matrix should move more towards emphasizing how easy it is to
| self-host
|
| They are already moving beyond that - towards P2P Matrix, with
| a network mixing traditional servers and individual nodes that
| collapse client and server:
| https://matrix.org/blog/2021/05/06/introducing-the-pinecone-...
| garaetjjte wrote:
| >I feel like Matrix should move more towards emphasizing how
| easy it is to self-host and maintain control of your own Matrix
| data
|
| The problem is, it isn't easy at all. Running homeserver
| requires gigabytes of RAM and significant CPU performance to
| work at usable speeds. It just isn't feasible to run it on some
| dirt cheap VPS, you need beefy machine.
| dkasak wrote:
| You'll be thrilled to know this pretty much isn't true
| anymore, even with Synapse. My instance is running on a cheap
| Hetzner VPS with a not very powerful CPU and is currently
| using about 700M RSS and not much CPU. And I'm in a _lot_ of
| rooms, some of them quite large and high in traffic.
|
| I'm also not even using Synapse workers at all, just a
| monolithic instance. Splitting the setup into workers would
| buy me an additional speedup if things got overly slow.
| nightpool wrote:
| Yes, unfortunately Synapse is possibly one of the worst apps
| i've ever sysadmin'd for, and I'm not even the primary
| sysadmin for my homeserver. I still use it, regularly, but
| we're all really anxiously anticipating the release of
| Dendrite. I'm not the biggest fan of the protocol either, or
| the UI/UX of Riot. I think Matrix is a good idea, but there's
| a lot of historical baggage and I think the world probably
| needs one more "throw everything away but learn the lessons
| of the past" cycle before we get something really, truly good
| in the chat space.
| Semaphor wrote:
| Why does it require that much? I run a Jabber server, and it
| barely uses any resources on my VPS. Unless you mean for
| significant users?
| garaetjjte wrote:
| If you want to actually use the federating feature, you
| will probably join some big channels. And that causes
| pulling of some huge amount of data from other homeservers.
|
| disclaimer: I tested it some time ago with Synapse. Now I
| see there is also new homeserver software, Dendrite. It is
| possible that it is order of magnitude less resource
| hungry, though I wouldn't count on that.
| callahad wrote:
| One of our primary goals on the Synapse last quarter was
| to make it possible for a new homeserver to join Matrix
| HQ (a large, public room) in under 1 GB of RAM. And we
| did it. https://matrix.org/blog/2021/06/15/synapse-1-36-0
| -released
|
| It's not the slimmest beast, in part because Synapse
| needs to scale _up_ to country-scale deployments, but its
| ability to scale down _has_ significantly improved over
| the past year.
|
| That said, Dendrite and Conduit
| (https://gitlab.com/famedly/conduit/) are exciting
| projects which will optimize for different operational
| contexts.
| zaik wrote:
| > Expecting users in hundred-person group chats to manually
| verify each other individual user's keys is nonsensical.
|
| Maybe this could be helped if Matrix clients supported OpenPGP
| encryption which allows for key signing/web of trust? Some XMPP
| clients already have OpenPGP support, it would be nice to one
| day be able to send encrypted messages to Matrix users.
| ncmncm wrote:
| In other news, Nheko supports E2EE.
| criticaltinker wrote:
| _> This is not a protocol or specification bug, but an
| implementation bug which was then unfortunately replicated in
| other independent implementations. _
|
| _> We will also accelerate our work on matrix-rust-sdk as a
| portable reference implementation of the Matrix protocol,
| avoiding the implicit requirement that each independent library
| must necessarily reimplement this logic on its own_
|
| I like the idea of providing a core Rust/C++ library that can be
| called in any other runtime via FFI, compiling to WebAssembly,
| etc. I've used the same technique to ensure consistency in usage
| of a custom time-series compression format across an
| organization. Overall this technique seems in-line with the "DRY"
| principle, and the tradeoffs have been favorable in my
| experience. I think it will be a good step forward for the Matrix
| ecosystem.
| Arathorn wrote:
| The current way we're approaching this is to split the
| reference E2EE implementation into its own rust crate
| (https://github.com/matrix-org/matrix-rust-
| sdk/tree/master/ma...) which can be used with any SDK (e.g.
| we're almost finished embedding it into the Kotlin matrix-
| android-sdk2 client)
|
| Separately, there's also the overall matrix-rust-sdk
| https://github.com/matrix-org/matrix-rust-sdk for clients to
| use as a "full fat" Matrix client SDK - as used by Fractal Next
| (https://gitlab.gnome.org/GNOME/fractal/-/tree/fractal-next)
| etc. We might end up using this in Element too in future
| (especially in Element iOS, where a Swift UI + matrix-rust-sdk
| backend could be quite a cute next generation architecture).
|
| So while the first generation reference Matrix SDKs (matrix-js-
| sdk, matrix-ios-sdk and matrix-android-sdk) were completely
| independent implementations, each with their own bugs and
| increased audit surface, we're hoping that matrix-rust-sdk will
| simplify this a lot in future.
| danShumway wrote:
| Quick comment, just want to show some additional support for
| the shared crate approach that Matrix is pursuing, it should
| give people a lot more confidence to try alternate clients.
|
| I throw messaging apps in the same category as, for example,
| web browsers. It's really tough to try an alternate
| implementation if you're worried that they might have broken
| a complicated security feature. So having more shared crates
| mitigates some of that risk.
| [deleted]
___________________________________________________________________
(page generated 2021-09-13 23:00 UTC)