Jesteśmy częścią Fediversu!

Wszystko co pojawia się na tej stronie powinno dać się śledzić dodając do obserowanych @kolektyw !!! Dalej pracujemy nad tym, żeby dodawać tu wszystko na bieżąco, ale jesteśmy już blisko!

Nie wiesz co chodzi? To weź się misiu pysiu dowiedz;

Fediverse to próba przywrócenia internetu z czasów zanim zeżarło go parę ohydnych korporacji. Bardziej chaotycznego i czasami wymagającego wysiłku, żeby znaleźć to czego się szuka ale też pełnego rzeczy dziwnych, ciekawych i niezwykłych. Bez korporacyjnego prania mózgów, plastikowej sterylności, dostosowywania się do algorytmów czy nabijania odsłon na siłę tylko po to, żeby robić za tło dla reklam i manipulacji miliarderów.
Tworzona oddolnie przez zaangażowane społeczności i jednostki część internetu odżywa, dzięki nowym narzędziom i odzyskiwaniu wirtualnej przestrzeni do życia.

Takie miejsce tworzymy w świecie fizycznym i takiego świata „wirtualnego” chcemy być częścią.

Oczywiście stronę mamy od dawna, ale zawsze przegrywała konkurencję z Fejkiem, Insta itd. Dotarcie do wolnego internetu zawsze będzie trochę bardziej złożone niż kliknięcie „obserwuj” na korporacyjnej społecznościówce. Nawet wyszukiwania w najpopularniejszych przeglądarkach niechętnie kierują w części internetu gdzie nie mają swoich reklam i nie mogą Was śledzić…

Fediverse to zmienia. Umożliwia komunikację pomiędzy milionami kont niezależnie od tego czy korzystają z tej samej usługi i tego samego serwera, czy z zupełnie różnych. To nie jedna malutka sieć społecznościowa, próbująca konkurować z korporacyjnymi molochami zarządzanymi przez miliarderów.
To sposób komunikacji pomiędzy różnymi platformami takimi jak Mastodon, Pixelfed, PeerTube, Lemmy, Friendica, Diaspora, Funkwhale czy innymi. Gdziekolwiek na nich masz konto – będziesz móc teraz wchodzić w interakcję z tym co widzisz na naszej stronie – śledzić nowości, komentować, a już niedługo – zapisywać się na wydarzenia!

Chcesz poczytać więcej o tym, dlaczego trzeba budować lepszy internet? Zajrzyj do społeczności Wolny Internet na szmerze. Chcesz zobaczyć, jak może wyglądać lepsza kultura? Zajrzyj do nas!

Reinterpreting Uranus’s Magnetosphere

NASA launched the Voyager 2 probe nearly 50 years ago, and, to date, it’s the only spacecraft to visit icy Uranus. This ice giant is one of our oddest planets — its axis is tilted so that it rotates on its side! — but a new interpretation of Voyager 2’s data suggests it’s not quite as strange as we’ve thought. Initially, Voyager 2’s data on Uranus’s magnetosphere suggested it was a very extreme place. Unlike other planets, it had energetic energy belts but no plasma. Now researchers have explained Voyager 2’s observations differently: they think the spacecraft arrived just after an intense solar wind event compressed Uranus’s magnetosphere, warping it to an extreme state. Their estimates suggest that Uranus would experience this magnetosphere state less than 5% of the time. But since Voyager 2’s data point is, so far, our only look at the planet, we just assumed this extreme was normal. (Image credit: NASA; research credit: J. Jasinski et al.; via Gizmodo)

#fluidDynamics #magnetohydrodynamics #physics #science #solarWind #Uranus

Against XMPP+OMEMO

XMPP is a messaging protocol (among other things) that needs no introduction to any technical audience. Its various implementations have proliferated through technical communities for decades.

Many large tech companies today used to run XMPP servers. However, the basic protocol transmitted plaintext. If you were lucky, it was plaintext over SSL/TLS, but servers could still see all of your message contents.

OMEMO (XEP-0384) is an attempt to staple end-to-end encryption onto the XMPP ecosystem.

It’s largely inspired by, and based on, an earlier version of the Signal protocol, so you might be tempted to believing that it’s good.

In my opinion, it’s not.

OMEMO is not the worst attempt at making XMPP encrypted (see: XEP-0027 for that), but it still doesn’t meet the bar for the kind of private messaging app that Signal is, and is not a viable competitor to Signal.

To understand why this is true, you only need check whether OMEMO is on by default (it isn’t), or whether OMEMO can be turned off even if your client supports it (it can).

Both of these conditions fail the requirements I outlined under the End-to-End Encryption header in that other blog post.

And that’s all that I should have needed to say on the matter.

Art: Harubaki

Unfortunately, the Internet is full of cargo cults built around specific technologies, and their followers have an emotional interest in muddying the waters.

Criticize one, and their rivals will come out of the woodwork to say, “This is why I use $FooBar instead of $BazQuux!” and insist that their preferred solution is the secure one–with all the confident incorrectness of a climate change denier.

Art: AJ

Let me explain why I don’t recommend XMPP and OMEMO for private messaging.

But before I do, a quick reminder that me criticizing XMPP+OMEMO isn’t an endorsement of weird or stupid alternatives, like using PGP.

Also, this post is about the entire XMPP + OMEMO ecosystem, not just the OMEMO specification.

Art: ScruffKerfluff

Why People Like XMPP

Quite simply, people like XMPP because it’s federated, which means they can control who gets access to their data. This is also one reason why people like Matrix, Mastodon, NextCloud, etc. It gives them a sense of control over their data that a centralized platform doesn’t. You can feel like you’re controlling your own destiny, whether or not that’s true. And those emotions can be a powerful thing.

Unlike Moxie, I don’t inherently think federated technology is always bad.

There are mechanisms you can employ to roll the entire ecosystem forward and keep everyone up-to-date with security fixes to an underlying protocol. Being frozen in time is a real problem in federation, but not an inevitability.

Unfortunately, XMPP is the perfect exhibit for anyone that wants to argue in favor of Moxie’s perspective on federation.

OMEMO Problem 1: Protocol Freeze

When I decided to set out to survey the XMPP+OMEMO ecosystem, the first question that came to mind is, “Which implementation is everyone using?”

The answer is probably Conversations. Other answers I heard were Gajim and forks of Conversations.

We’ll get back to Conversations later, but right now, I want to address a bigger problem with the XMPP+OMEMO ecosystem.

The latest draft of XEP-0384 is version 0.8.3, published in January 2022.

Despite this, almost every OMEMO implementation I can find is still on version 0.3.0 (or earlier) of the OMEMO specification.

Art: CMYKat

The easiest way to tell if they aren’t implementing version 0.4.0 or newer is the absence of AES-256-CBC in their codebase.

See for yourself. All of the following implement version 0.3.0 or older of the OMEMO specification:

• libomemo, dependents:
  
  • weechat-xmpp

  
  

• Conversations, forks:
  
  • blabber.im
  • Monocles
  • Quicksy
  • Snikket

  
  

• Converse.js
• Gajim
• jaxmpp, dependents:
  
  • Stork IM

  
  

• jabber-web
• MartinOMEMO, dependents:
  
  • Siskin IM

  
  

The only implementations I found that supported newer protocol versions were Profanity and Kaidan (via QXmpp).

EDIT: Thanks to tant for pointing me to this list of versions.

What To Even Focus On?

A question comes to mind: Which version of the specification should an enterprising security researcher look at?

Art: CMYKat

The latest version available online, or an ancient version that’s still widely used?

If I find a problem in the latest draft of the specification, some will say that’s a non-issue because the spec is “experimental” and therefore should not implemented yet.

If I find a problem in the older draft of the specification, some will insist that those are known problems with an older version of the spec, and that people “should” be on the newer version if they expect to be secure.

Even worse, there’s probably some overlap between the two sets of people.

Regardless, anyone who’s vested in improving the security of the XMPP+OMEMO ecosystem is at an impasse right out of the gate. That’s not a good place to be in.

OMEMO Problem 2: YOLO Crypto

OMEMO doesn’t attempt to provide even the vaguest rationale for its design choices, and appears to approach cryptography protocol specification with a care-free attitude.

To put it mildly, this is the wrong way to approach cryptography. This is best explained with a concrete example.

Version 0.3.0 of XEP-0384 used AES-128-GCM to encrypt messages. (As we saw in the previous section, this is the version almost everyone is actually using.)

Version 0.4.0 was updated to use AES-256-CBC + HMAC-SHA-256 (Encrypt then HMAC), as Signal does.

Version 0.7.0 introduced yet another protocol change: The HMAC-SHA-256 authentication tag is now truncated to 128 bits.

And what was the changelog message for version 0.7.0?

Various fixes, clarifications and general improvements.

CHANGELOG, XEP-0384 0.7.0

You’ve got to be fucking kidding me.

Harubaki

So here’s the thing: These protocols all provide different security properties, and some of these differences are subtle. Switching from one to the other is the sort of change that should be accompanied by a clear reason.

See, for example, the PASETO v3/v4 rationale doc. That is the level of detail I’d want to see in OMEMO’s specification, especially the changelog. OMEMO’s rationale isn’t merely inadequate, it’s totally absent!

Technical Correction (2024-08-06)

A few people (or maybe the same person under different alts? Didn’t check, don’t really care) have pointed out that this section is not technically correct.

Apparently, while the actual steps in the encryption and decryption algorithms didn’t mention truncation at all, this was alluded to earlier in an earlier section.

I’m not going to significantly alter what I originally wrote above, because the earlier versions of the spec were poorly written and the instructions where absent from the section they needed to be in.

OMEMO Encryption Through the Ages

Before Version 0.4.0

AES-128-GCM doesn’t commit to the key, which can lead to an attack that we call “Invisible Salamanders”.

Historically, this was exploited in “abuse reporting” scenarios, but as I explained in my Threema disclosures, it can sometimes come up in group messaging scenarios.

For flavor, I wrote a GCM exploit in PHP for part of the DEFCON Furs’ badge challenge one year. It’s not a difficult one to pull off.

But if you’re in a setup where you only have one valid key for a given ciphertext, that’s not really a problem.

A bigger concern with this algorithm is that you’re constrained to 96-bit nonces, so if you’re using the same key for multiple messages, you have to worry about symmetric wear-out.

That being said, we can kind of summarize this as a short, reusable list.

• Key entropy: 128 bits
• Key commitment security: None
• Safety limit: messages, each with a max length of bytes.
• Authentication tag length: 128 bits
• Authentication security: 128 bits (polynomial MAC)

Version 0.4.0 – 0.6.0

As mentioned previously, version 0.4.0 of the OMEMO specification moved towards AES-256-CBC + HMAC-SHA-256 for Stanza Content Encryption.

This is congruent with what Signal does, so I won’t belabor the point.

If you implement the encryption algorithm faithfully from the specification’s order of operations, truncation is omitted. However, it does get a passing mention in the double ratchet section, so the authors can argue it was intended “all along”.

• Key entropy: 256 bits
• Key commitment security: 128 bits 64 bits
• Safety limit: It’s complicated. It can range from to bytes.
• Authentication tag length: 256 bits 128 bits (see edit)
• Authentication security: 128 bits 64 bits (cryptographic hash function)

EDIT: As mentioned above, this is actually not correct, because of an easy-to-miss detail in a previous section. There is no relevant encryption protocol change between 0.4.0 and 0.7.0.

Version 0.7.0 and Newer

And now we get to the latest version of the protocol, which is like the previous flavor, but now they truncate the HMAC-SHA-256 authentication tag to 128 bits in the actual steps to be performed.

Specifications should provide clear, unambiguous instructions for implementors. The OMEMO specification authors have failed to do this.

Interestingly, even the current version (0.8.3) doesn’t instruct implementations to use constant-time comparison for the truncated authentication tag in the decrypt path.

Surely, that won’t be a problem, right?

But to be congruent with the other sections in this historical breakdown, version 0.7.0+ looks like this:

• Key entropy: 256 bits
• Key commitment security: 64 bits
• Safety limit: It’s complicated. It can range from to bytes.
• Authentication tag length: 128 bits
• Authentication security: 64 bits (cryptographic hash function)

Remarks

Because there is no rationale given for this sudden square-root reduction in security against existential forgery attacks (EDIT: not correct, it was always truncated, just poorly written), we kind of have to fill in the gaps and assume it was because of some kind of performance or bandwidth considerations.

But even that doesn’t really justify it, does it?

You’re only saving 16 bytes of bandwidth by truncating the MAC. Meanwhile, the actual ciphertext blobs are being encoded with base64, which adds 33% of overhead.

For any message larger than 48 bytes, this base64 encoding will dominate the bandwidth consumption more than using the full HMAC tag would.

CMYKat

Is truncating the HMAC tag to to 128 bits still secure? According to Signal, yes, it is. And I offer no disagreement to Signal’s assessment here.

The problem is, as I’ve said repeatedly, OMEMO’s specification makes no attempt to justify their design decisions.

The “why?” is left as an exercise to the reader, and I’m not convinced that they themselves fully know the answer to that question.

OMEMO Problem 3: Market Penetration

I alluded to this above, but it bears repeating: Even if the previous two problems were resolved overnight, it’s entirely possible to use XMPP without encryption.

Further, you can disable OMEMO even if you’re using a client that supports OMEMO.

When I compare it to Signal, whose users always have end-to-end encryption, XMPP + OMEMO falls short of what is required to be a secure private messaging app.

XMPP+OMEMO evangelists are quick to point out that Conversations, the favored implementation, lets you enforce “always use encryption” mode. This is a damn good idea, but there’s no universal guarantee that all clients will do this, nor make it the default behavior.

On that note, let’s talk about Conversations.

OMEMO Problem 4: You’re not ready for that Conversation

Conversations is, from the best I can gather, the most popular XMPP client with OMEMO support.

If you’re going to discuss OMEMO, in practical terms, you need to look at the most popular implementation of OMEMO to have an informed opinion on the matter. Only focusing on the specification, rathe than actual implementations, would be a foolhardy endeavor.

Conversations appears to follow the “everything but the kitchen sink” methodology to managing their complexity.

Just looking at the crypto folder, I count the following:

1. Code that implements OpenPGP functions (signing, encryption)
2. X.509 certificate validation for XMPP domains based on BouncyCastle
3. An entire first-class SASL implementation, rather than a third-party library
4. Finally, their OMEMO implementation (still named Axolotl) that depends on libsignal

Update (2024-08-09): An earlier version of this blog post criticized them for having two PGP classes in the crypto folder.

The second one (PgpDecryptionService.java) appeared to call a separate API from the one next to it, which seemed like a legacy code path that was in need of refactoring away.

A closer examination reveals that it calls a Service class that in turn calls the first PGP class (PgpEngine.java), so I retracted that item from the above list.

To be clear: These aren’t separate dependencies that Conversations pulls in to implement plugin supports. They’re first-party cryptographic implementations all within this Android app’s codebase.

(Some of them also have third-party dependencies to boot, but that’s generally okay.)

The only thing they didn’t include is their own first-party TLS implementation forked from, like, OpenSSL 1.0.2f. That would’ve filled my Bingo card.

Art by AJ

Your Version Check Bounced

The latest version of Conversations depends on version 1.64 of the Bouncy Castle S/MIME implementation (October 2019), despite 1.70 being the latest that supports Java 1.5 (and 1.78 being the latest overall, but requires Java 1.8).

This means the following security enhancements and fixes are absent in the version Conversations depends on:

• Client-side OCSP Stapling was added in v1.65
• TLS 1.3 support was added in v1.68
• CVE-2023-33202, a DoS vulnerability in ASN.1 reachable through the PEM parser (i.e., any of the X.509 or OpenPGP code referenced above) is fixed in version v1.73.

The last one (CVE-2023-33202) is pernicious. Although it’s reachable through any usage of BouncyCastle’s Java PEM parser, the root cause is the underlying ASN.1 code, which means the domain verifier code is probably affected.

Why is Conversations in August 2024 still using an October 2019 version of their cryptography library?

Why am I pointing this out today when a component it provides that Conversations actually uses had a security fix in July 2023?

It’s not just BouncyCastle, either. Conversations also depends on a version of libsignal that was archived in 2022.

How We Got Here

Though it may be tempting for some readers to assign blame, let me be very clear: Doing so isn’t helpful, so don’t.

XMPP was a well-intentioned open protocol and Internet Standard. OMEMO was the least-bad effort to staple encryption onto XMPP.

If Conversations hadn’t cornered the XMPP market in recent years, the lack of discipline in complexity management (or a Dependabot or Semgrep integration, for that matter) would be a minor annoyance.

A lot of things had to go wrong for things to get as bad as they are.

Maybe part of the blame is a lack of investment or innovation in the XMPP developer community.

Maybe there should have been more dialogue between the security community and the XMPP Standards Foundation.

But the one thing I am certain of is the conclusion to this whole piece.

In Conclusion

As things stand today, I cannot recommend anyone use XMPP + OMEMO.

From the lack of a mechanism to keep implementations up-to-date with protocol versions, to a lack of clear rationale for protocol design decisions, to ecosystem issues with both the app availability and their third-party open source dependencies, to the most popular app (Conversations) being an absolute mess of complications, XMPP+OMEMO hasn’t earned my trust.

It’s possible that these flaws are correctable, and some future iteration of OMEMO will be better. It’s also possible that XMPP’s ecosystem will decide to make end-to-end encryption a non-optional component for all XMPP clients.

But I certainly wouldn’t bet my personal safety on good things happening; especially because of anything I wrote. I’m just some furry with a blog, after all.

CMYKat

“Don’t care, gonna keep using it!”

That’s fine. I’m not anyone’s boss or parent.

But in return, I really don’t appreciate unsolicited evangelism towards any technology.

It’s even worse when said evangelism is shouted over my informed opinions about cryptographic software. So, please don’t do that.

Addendum (2024-08-06)

Tim Henkes, one of the OMEMO authors, wrote a very tedious comment. The TL;DR of it is “you should distinguish between specification criticism and client software criticism, also truncation was in 0.4.0”.

I made the relevant changes above, because technical accuracy is important to me, but wasn’t interested in further involving myself with their project. So I replied saying as such.

Here’s a screenshot of their reply:

I’m just gonna let that speak for itself.

#cryptography #endToEndEncryption #softwareSecurity

Soatok

2024-07-31 16:25:41

What Does It Mean To Be A Signal Competitor?

A lot of recent (and upcoming) blog posts I’ve written, and Fediverse discussions I’ve participated in, have been about the security of communication products.

My criticism of these products is simply that, from a cryptography and security perspective, they’re not a real competitor to Signal.

For all its other faults, Signal sets the bar for secure private messaging. It’s a solid security tool, even if its user experience and feature set leaves a lot of people disappointed. I highly recommend it over, say, Telegram.

In response to my post about jettisoning Telegram, quite a few people have tried to evangelize other products. For example:

Edit: Oh yeah, DON’T USE SIGNAL. Use Matrix instead, offers the benefits of signal without the drawbacks of lack of sync and phone number requirements and is decentralized. The fact that everyone is going gaga for signal as “the BEST messaging app” should be a big red flag in and of itself, because hype trains like this aren’t organic, just saying.

Draconic_NEO on pawb.social

So, let me explain what it means for a communication product to qualify as a Signal competitor from the perspective of someone whose job involves auditing cryptography implementations.

The Minimum Bar to Clear

Open Source

Every private messaging app must be open source in order to qualify as a Signal competitor.

If it’s not open source, it’s not even worth talking about.

End-to-End Encryption

Messages MUST be end-to-end encrypted. This means that you encrypt on one participant’s device, decrypt on another’s, and nobody in the middle can observe plaintext.

When I say MUST, I mean the RFC 2119 keyword.

There must never be a “transmit plaintext” option. No excuses. Secure cryptography is not interoperable with insecure cryptography. If you allow a “transmit plaintext” mode for any reason whatsoever, you have failed to build an encryption product that meets the bar.

This disqualifies Matrix.

This disqualifies Telegram.

This disqualifies XMPP + OMEMO.

This alone disqualifies a lot of so-called private messaging apps.

This doesn’t mean your product is insecure, or that I’m aware of any specific ways to break it.

It just doesn’t occupy the same mindshare as Signal, which only transmits encrypted data and doesn’t have a plaintext protocol to downgrade to.

Therefore, it’s not a goddamn Signal alternative.

How You Encrypt Matters

Signal normalized the use of AES-256-CBC with HMAC-SHA256.

Facebook’s “Secret Conversations” feature deviated from this and preferred AES-GCM for attachments, but this bit them when the Invisible Salamanders attack was discovered.

The way Signal uses AES+HMAC is fine for their use case, but building a secure committing AEAD mode (rather than merely AE) out of these primitives is nontrivial.

If you’re aiming to compete with Signal on security, you should, at minimum, expect to engage with a cryptography auditing firm at least once a year to review and re-review your protocol designs and implementations.

I Will Heavily Scrutinize Your Group Messaging Protocols

Group messaging is one of those topics that might sound easy if you can do peer-to-peer messaging securely, but is catastrophically difficult once you get into the details.

See also: My blog post about Threema.

If you want a starting point, look at RFC 9420 (Messaging Layer Security, which is a group key agreement protocol for messaging apps).

How You Manage Keys Matters

Tox attempted to build atop NaCl’s crypto_box interface, but this is not suitable for a general purpose secure messaging due to a lack of KCI Security.

Key management (which is the focus of an upcoming blog post) is a problem that almost everyone underestimates. It’s also the most user-facing aspect of these messaging applications.

WhatsApp uses Key Transparency to scale user trust. I’m proposing something similar for E2EE for the Fediverse.

This is a much better strategy than expecting users to manually verify “fingerprints”.

Don’t look at OpenPGP as a role model when it comes to user experience. Johnny still cannot fucking encrypt.

Your Feature Should Not Bypass Privacy

Want to add all sorts of frills, like video chat or some dumb bullshit with AI and/or blockchain to secure the attention of venture capitalist investors?

You’d better not implement them in such a way that leaks users’ messages or search queries to your service.

The main reason Signal is “missing” features is because they are thoughtful about how these features are designed and implemented.

Guess what happens if you prioritize shipping features over privacy and cryptography engineering?

That’s right: You stop being a contender for a Signal alternative.

So What?

If your fave isn’t a viable alternative to Signal, don’t fucking recommend it to people in response to me recommending Signal.

That’s all I ask.

Art: Scruff

But what about…?

I’m not here to discuss your use cases, or usability, or anything else. I’m also not saying that Signal is perfect!

Signal is a private messaging app that I would feel safe recommending whistleblowers to use. It meets all these requirements.

In order to be a Signal competitor, no matter how much you like your app, it needs to meet them too, otherwise it isn’t a Signal competitor. Them’s the rules!

AJ

There may be other requirements that are more important to you, that Signal doesn’t meet. That’s fine! You can like other things.

But unless your favorite widget also meets all of the things on this page, it’s not a valid competitor from a security and privacy perspective, and therefore I don’t want to fucking hear about it in response to me saying “use Signal until something better comes along”.

Capiche?

Addendum (2024-08-01)

Since I originally posted this, there have been a lot of opinions expressed and questions asked about messaging apps that have nothing to do with cryptographic security.

Those are good discussions to have, elsewhere. Hell, most of this discussion would be a better response to my other blog post than this one.

The goal of this post was to specify what the minimum bar is for a different app to qualify as a Signal competitor. It’s written from the perspective of someone whose career is in applied cryptography.

If you have thoughts, feelings, opinions, questions, or concerns about messaging apps (including but not limited to Signal), that’s wonderful.

But this specific blog post is not the correct place to voice them!

Especially if the first line of your response is “you’re too focused on [technology, security, cryptography] (select appropriate)”.

Because… no shit? That’s the entire point of this particular post. It’s narrowly scoped for a reason. Please respect that.

My upcoming vulnerability disclosure in Matrix will make the same point, but I wanted a separate, less distracting blog post to link people to when someone tries to evangelize another chat app instead of Signal, especially if they make security claims while doing so.

#cryptography #endToEndEncryption #privateMessengers #Signal

Deploying key transparency at WhatsApp - Engineering at Meta

With key transparency, WhatsApp provides a set of proofs that affirms the correctness of public encryption keys.

^{Kevin Lewi (Meta)}

Security Issues in Matrix’s Olm Library

I don’t consider myself exceptional in any regard, but I stumbled upon a few cryptography vulnerabilities in Matrix’s Olm library with so little effort that it was nearly accidental.

It should not be this easy to find these kind of issues in any product people purportedly rely on for private messaging, which many people evangelize incorrectly as a Signal alternative.

Later, I thought I identified an additional vulnerability that would have been much worse, but I was wrong about that one. For the sake of transparency and humility, I’ll also describe that in detail.

This post is organized as follows:

• Disclosure Timeline
• Vulnerabilities in Olm (Technical Details)
• Recommendations
• Background Information
• An Interesting Non-Issue That Looked Critical

I’ve opted to front-load the timeline and vulnerability details to respect the time of busy security professionals.

Please keep in mind that this website is a furry blog, first and foremost, that sometimes happens to cover security and cryptography topics.

Many people have, over the years, assumed the opposite and commented accordingly. The ensuing message board threads are usually is a waste of time and energy for everyone involved. So please adjust your expectations.

Art by Harubaki

If you’re curious, you can learn more here.

Disclosure Timeline

• 2024-05-15: I took a quick look at the Matrix source code. I identified two issues and emailed them to their security@ email address.
  In my email, I specify that I plan to disclose my findings publicly in 90 days (i.e. on August 14), in adherence with industry best practices for coordinated disclosure, unless they request an extension in writing.
• 2024-05-16: I checked something else on a whim and find a third issue, which I also email to their security@ email address.
• 2024-05-17: Matrix security team confirms receipt of my reports.
• 2024-05-17: I follow up with a suspected fourth finding–the most critical of them all. They point out that it is not actually an issue, because I overlooked an important detail in how the code is architected. Mea culpa!
• 2024-05-18: A friend discloses a separate finding with Matrix: Media can be decrypted to multiple valid plaintexts using different keys and Malicious homeservers can trick Element/Schildichat into revealing links in E2EE rooms.
  They instructed the Matrix developers to consult with me if they needed cryptography guidance. I never heard from them on this externally reported issue.
• 2024-07-12: I shared this blog post draft with the Matrix security team while reminding them of the public disclosure date.
• 2024-07-31: Matrix pushes a commit that announces that libolm is deprecated.
• 2024-07-31: I email the Matrix security team asking if they plan to fix the reported issues (and if not, if there’s any other reason I should withhold publication).
• 2024-07-31: Matrix confirms they will not fix these issues (due to its now deprecated status), but ask that I withhold publication until the 14th as originally discussed.
• 2024-08-14: This blog post is publicly disclosed to the Internet.
• 2024-08-14: The lead Matrix dev claims they already knew about these issues, and, in fact, knowingly shipped cryptography code that was vulnerable to side-channel attacks for years. See Addendum.
• 2024-08-23: MITRE has assigned CVE IDs to these three findings.

Vulnerabilities in Olm

I identified the following issues with Olm through a quick skim of their source code on Gitlab:

1. AES implementation is vulnerable to cache-timing attacks
2. Ed25519 signatures are malleable
3. Timing leakage in base64 decoding of private key material

This is sorted by the order in which they were discovered, rather than severity.

AES implementation is vulnerable to cache-timing attacks

a.k.a. CVE-2024-45191

Olm ships a pure-software implementation of AES, rather than leveraging hardware acceleration.

// Substitutes a word using the AES S-Box.WORD SubWord(WORD word){unsigned int result;result = (int)aes_sbox[(word >> 4) & 0x0000000F][word & 0x0000000F];result += (int)aes_sbox[(word >> 12) & 0x0000000F][(word >> 8) & 0x0000000F] << 8;result += (int)aes_sbox[(word >> 20) & 0x0000000F][(word >> 16) & 0x0000000F] << 16;result += (int)aes_sbox[(word >> 28) & 0x0000000F][(word >> 24) & 0x0000000F] << 24;return(result);}

The code in question is called from this code, which is in turn used to actually encrypt messages.

Software implementations of AES that use a look-up table for the SubWord step of the algorithm are famously susceptible to cache-timing attacks.

This kind of vulnerability in software AES was previously used to extract a secret key from OpenSSL and dm-crypt in about 65 milliseconds. Both papers were published in 2005.

A general rule in cryptography is, “attacks only get better; they never get worse“.

As of 2009, you could remotely detect a timing difference of about 15 microseconds over the Internet with under 50,000 samples. Side-channel exploits are generally statistical in nature, so such a sample size is generally not a significant mitigation.

How is this code actually vulnerable?

In the above code snippet, the vulnerability occurs in
aes_sbox[/* ... */][/* ... */].

Due to the details of how the AES block cipher works, the input variable (word) is a sensitive value.

Software written this way allows attackers to detect whether or not a specific value was present in one of the processor’s caches.

To state the obvious: Cache hits are faster than cache misses. This creates an observable timing difference.

Such a timing leak allows the attacker to learn the value that was actually stored in said cache. You can directly learn this from other processes on the same hardware, but it’s also observable over the Internet (with some jitter) through the normal operation of vulnerable software.

See also: cryptocoding’s description for table look-ups indexed by secret data.

How to mitigate this cryptographic side-channel

The correct way to solve this problem is to use hardware accelerated AES, which uses distinct processor features to implement the AES round function and side-steps any cache-timing shenanigans with the S-box.

Not only is this more secure, but it’s faster and uses less energy too!

If you’re also targeting devices that don’t have hardware acceleration available, you should first use hardware acceleration where possible, but then fallback to a bitsliced implementation such as the one in Thomas Pornin’s BearSSL.

See also: the BearSSL documentation for constant-time AES.

Art by AJ

Ed25519 signatures are malleable

a.k.a. CVE-2024-45193

Ed25519 libraries come in various levels of quality regarding signature validation criteria; much to the chagrin of cryptography engineers everywhere. One of those validation criteria involves signature malleability.

Signature malleability usually isn’t a big deal for most protocols, until suddenly you discover a use case where it is. If it matters, that usually that means you’re doing something with cryptocurrency.

Briefly, if your signatures are malleable, that means you can take an existing valid signature for a given message and public key, and generate a second valid signature for the same message. The utility of this flexibility is limited, and the impact depends a lot on how you’re using signatures and what properties you hope to get out of them.

For ECDSA, this means that for a given signature , a second signature is also possible (where is the order of the elliptic curve group you’re working with).

Matrix uses Ed25519, whose malleability is demonstrated between and .

This is trivially possible because S is implicitly reduced modulo the order of the curve, , which is a 253-bit number (0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3ed) and S is encoded as a 256-bit number.

The Ed25519 library used within Olm does not ensure that , thus signatures are malleable. You can verify this yourself by looking at the Ed25519 verification code.

int ed25519_verify(const unsigned char *signature, const unsigned char *message, size_t message_len, const unsigned char *public_key) { unsigned char h[64]; unsigned char checker[32]; sha512_context hash; ge_p3 A; ge_p2 R; if (signature[63] & 224) { return 0; } if (ge_frombytes_negate_vartime(&A, public_key) != 0) { return 0; } sha512_init(&hash); sha512_update(&hash, signature, 32); sha512_update(&hash, public_key, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, h); sc_reduce(h); ge_double_scalarmult_vartime(&R, h, &A, signature + 32); ge_tobytes(checker, &R); if (!consttime_equal(checker, signature)) { return 0; } return 1;}

This is almost certainly a no-impact finding (or low-impact at worst), but still an annoying one to see in 2024.

If you’d like to learn more, this page is a fun demo of Ed25519 malleability.

To mitigate this, I recommend implementing these checks from libsodium.

Art: CMYKat

Timing leakage in base64 decoding of private key material

a.k.a. CVE-2024-45192

If you weren’t already tired of cache-timing attacks based on table look-ups from AES, the Matrix base64 code is also susceptible to the same implementation flaw.

while (pos != end) { unsigned value = DECODE_BASE64[pos[0] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[1] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[2] & 0x7F]; value <<= 6; value |= DECODE_BASE64[pos[3] & 0x7F]; pos += 4; output[2] = value; value >>= 8; output[1] = value; value >>= 8; output[0] = value; output += 3;}

The base64 decoding function in question is used to load the group session key, which means the attack published in this paper almost certainly applies.

How would you mitigate this leakage?

Steve Thomas (one of the judges of the Password Hashing Competition, among other noteworthy contributions) wrote some open source code a while back that implements base64 encoding routines in constant-time.

The real interesting part is how it avoids a table look-up by using arithmetic (from this file):

// Base64 character set:// [A-Z] [a-z] [0-9] + /// 0x41-0x5a, 0x61-0x7a, 0x30-0x39, 0x2b, 0x2finline int base64Decode6Bits(char src){int ch = (unsigned char) src;int ret = -1;// if (ch > 0x40 && ch < 0x5b) ret += ch - 0x41 + 1; // -64ret += (((0x40 - ch) & (ch - 0x5b)) >> 8) & (ch - 64);// if (ch > 0x60 && ch < 0x7b) ret += ch - 0x61 + 26 + 1; // -70ret += (((0x60 - ch) & (ch - 0x7b)) >> 8) & (ch - 70);// if (ch > 0x2f && ch < 0x3a) ret += ch - 0x30 + 52 + 1; // 5ret += (((0x2f - ch) & (ch - 0x3a)) >> 8) & (ch + 5);// if (ch == 0x2b) ret += 62 + 1;ret += (((0x2a - ch) & (ch - 0x2c)) >> 8) & 63;// if (ch == 0x2f) ret += 63 + 1;ret += (((0x2e - ch) & (ch - 0x30)) >> 8) & 64;return ret;}

Any C library that handles base64 codecs for private key material should use a similar implementation. It’s fine to have a faster base64 implementation for non-secret data.

Worth noting: Libsodium also provides a reasonable Base64 codec.

Recommendations

These issues are not fixed in libolm.

Instead of fixing libolm, the Matrix team recommends all Matrix clients adopt vodozemac.

I can’t speak to the security of vodozemac.

Art: CMYKat

But I can speak against the security of libolm, so moving to vodozemac is probably a good idea. It was audited by Least Authority at one point, so it’s probably fine.

Most Matrix clients that still depended on libolm should treat this blog as public 0day, unless the Matrix security team already notified you about these issues.

Background Information

If you’re curious about the backstory and context of these findings, read on.

Otherwise, feel free to skip this section. It’s not pertinent to most audiences. The people that need to read it already know who they are.

End-to-end encryption is one of the topics within cryptography that I find myself often writing about.

In 2020, I wrote a blog post covering end-to-end encryption for application developers. This was published several months after another blog I wrote covering gripes with AES-GCM, which included a shallow analysis of how Signal uses the algorithm for local storage.

In 2021, I published weaknesses in another so-called private messaging app called Threema.

In 2022, after Elon Musk took over Twitter, I joined the Fediverse and sought to build end-to-end encryption support for direct messages into ActivityPub, starting with a specification. Work on this effort was stalled while trying to solve Public Key distribution in a federated environment (which I hope to pick up soon, but I digress).

Earlier this year, the Telegram CEO started fearmongering about Signal with assistance from Elon Musk, so I wrote a blog post urging the furry fandom to move away from Telegram and start using Signal more. As I had demonstrated years prior, I was familiar with Signal’s code and felt it was a good recommendation for security purposes (even if its user experience needs significant work).

I thought that would be a nice, self-contained blog post. Some might listen, most would ignore it, but I could move on with my life.

I was mistaken about that last point.

Art by AJ

An overwhelming number of people took it upon themselves to recommend or inquire about Matrix, which prompted me to hastily scribble down my opinion on Matrix so that I might copy/paste a link around and save myself a lot of headache.

Just when I thought the firehose was manageable and I could move onto other topics, one of the Matrix developers responded to my opinion post.

Thus, I decided to briefly look at their source code and see if any major or obvious cryptography issues would fall out of a shallow visual scan.

Since you’re reading this post, you already know how that ended.

Credit: CMYKat

Since the first draft of this blog post was penned, I also outlined what I mean when I say an encrypted messaging app is a Signal competitor or not, and published my opinion on XMPP+OMEMO (which people also recommend for private messaging).

Why mention all this?

Because it’s important to know that I have not audited the Olm or Megolm codebases, nor even glanced at their new Rust codebase.

The fact is, I never intended to study Matrix. I was annoyed into looking at it in the first place.

My opinion of their project was already calcified by the previously discovered practically-exploitable cryptographic vulnerabilities in Matrix in 2022.

The bugs described above are the sort of thing I mentally scan for when I first look at a project just to get a feel for the maturity of the codebase. I do this with the expectation (hope, really) of not finding anything at all.

(If you want two specific projects that I’ve subjected to a similar treatment, and failed to discover anything interesting in: Signal and WireGuard. These two set the bar for cryptographic designs.)

It’s absolutely bonkers that an AES cache timing vulnerability was present in their code in 2024.

It’s even worse when you remember that I was inundated with Matrix evangelism in response to recommending furries use Signal.

I’m a little outraged because of how irresponsible this is, in context.

It’s so bad that I didn’t even need to clone their git repository, let alone run basic static analysis tools locally.

So if you take nothing else away from this blog post, let it be this:

There is roughly a 0% chance that I got extremely lucky in my mental grep and found the only cryptography implementation flaws in their source code. I barely tried at all and found these issues.

I would bet money on there being more bugs or design flaws that I didn’t find, because this discovery was the result of an extremely half-assed effort to blow off steam.

Wasn’t libolm deprecated in May 2022?

The Matrix developers like to insist that their new Rust hotness “vodozemac” is what people should be using today.

I haven’t looked at vodozemac at all, but let’s pretend, for the sake of argument, that its cryptography is actually secure.

(This is very likely if they turn out to be using RustCrypto for their primitives, but I don’t have the time or energy for that nerd snipe, so I’m not going to look. Least Authority did audit their Rust library, for what it’s worth, and Least Authority isn’t clownshoes.)

It’s been more than 2 years since they released vodozemac. What does the ecosystem penetration for this new library look like, in practice?

A quick survey of the various Matrix clients on GitHub says that libolm is still the most widely used cryptography implementation in the Matrix ecosystem (as of this writing):

3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all.

If we only focus on clients that support E2EE, vodozemac has successfully been adopted by 19% of the open source Matrix clients on GitHub.

I deliberately excluded any repositories that were archived or clearly marked as “old” or “legacy” software, because including those would artificially inflate the representation of libolm. It would make for a more compelling narrative to do so, but I’m not trying to be persuasive here.

Deprecation policies are a beautiful lie. The impact of a vulnerability in Olm or Megolm is still far-reaching, and should be taken seriously by the Matrix community.

Worth calling out: this quick survey, which is based on a GitHub Topic, certainly misses other implementations. Both FluffyChat and Cinny, which were not tagged with this GitHub Topic, depend a language-specific Olm binding.

These bindings in turn wrap libolm rather than the Rust replacement, vodozemac.

But the official clients…

I thought the whole point of choosing Matrix over something like Signal is to be federated, and run your own third-party clients?

If we’re going to insist that everyone should be using Element if they want to be secure, that defeats the entire marketing point about third-party clients that Matrix evangelists cite when they decry Signal’s centralization.

So I really don’t want to hear it.

CMYKat

An Interesting Non-Issue That Looked Critical

As I mentioned in the timeline at the top, I thought I found a fourth issue with Matrix’s codebase. Had I been correct, this would have been a critical severity finding that the entire Matrix ecosystem would need to melt down to remediate.

Fortunately for everyone, I made a mistake, and there is no fourth vulnerability after all.

However, I thought it would be interesting to write about what I thought I found, the impact it would have had if it were real, and why I believed it to be an issue.

Let’s start with the code in question:

void ed25519_sign(unsigned char *signature, const unsigned char *message, size_t message_len, const unsigned char *public_key, const unsigned char *private_key) { sha512_context hash; unsigned char hram[64]; unsigned char r[64]; ge_p3 R; sha512_init(&hash); sha512_update(&hash, private_key + 32, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, r); sc_reduce(r); ge_scalarmult_base(&R, r); ge_p3_tobytes(signature, &R); sha512_init(&hash); sha512_update(&hash, signature, 32); sha512_update(&hash, public_key, 32); sha512_update(&hash, message, message_len); sha512_final(&hash, hram); sc_reduce(hram); sc_muladd(signature + 32, hram, private_key, r);}

The highlighted segment is doing pointer arithmetic. This means it’s reading 32 bytes, starting from the 32nd byte in private_key.

What’s actually happening here is: private_key is the SHA512 hash of a 256-bit seed. If you look at the function prototype, you’ll notice that public_key is a separate input.

Virtually every other Ed25519 implementation I’ve ever looked at before expected users to provide a 32 byte seed followed by the public key as a single input.

This led me to believe that this private_key + 32 pointer arithmetic was actually using the public key for calculating r.

The variable r (not to be confused with big R) generated via the first SHA512 is the nonce for a given signature, it must remain secret for Ed25519 to remain secure.

If r is known to an attacker, you can do some arithmetic to recover the secret key from a single signature.

Because I had mistakenly believed that r was calculated from the SHA512 of only public inputs (the public key and message), which I must emphasize isn’t correct, I had falsely concluded that any previously intercepted signature could be used to steal user’s private keys.

Credit: CMYKat

But because private_key was actually the full SHA512 hash of the seed, rather than the seed concatenated with the public key, this pointer arithmetic did NOT use the public key for the calculation of r, so this vulnerability does not exist.

If the code did what I thought it did, however, this would have been a complete fucking disaster for the Matrix ecosystem. Any previously intercepted message would have allowed an attacker to recover a user’s secret key and impersonate them. It wouldn’t be enough to fix the code; every key in the ecosystem would need to be revoked and rotated.

Whew!

I’m happy to be wrong about this one, because that outcome is a headache nobody wants.

So no action is needed, right?

Well, maybe.

Matrix’s library was not vulnerable, but I honestly wouldn’t put it past software developers at large to somehow, somewhere, use the public key (rather than a secret value) to calculate the EdDSA signature nonces as described in the previous section.

To that end, I would like to propose a test vector be added to the Wycheproof test suite to catch any EdDSA implementation that misuses the public key in this way.

Then, if someone else screws up their Ed25519 implementation in the exact way I thought Matrix was, the Wycheproof tests will catch it.

For example, here’s a vulnerable test input for Ed25519:

{ "should-fail": true, "secret-key": "d1d0ef849f9ec88b4713878442aeebca5c7a43e18883265f7f864a8eaaa56c1ef3dbb3b71132206b81f0f3782c8df417524463d2daa8a7c458775c9af725b3fd", "public-key": "f3dbb3b71132206b81f0f3782c8df417524463d2daa8a7c458775c9af725b3fd", "message": "Test message", "signature": "ffc39da0ce356efb49eb0c08ed0d48a1cadddf17e34f921a8d2732a33b980f4ae32d6f5937a5ed25e03a998e4c4f5910c931b31416e143965e6ce85b0ea93c09"}

A similar test vector would also be worth creating for Ed448, but the only real users of Ed448 were the authors of the xz backdoor, so I didn’t bother with that.

(None of the Project Wycheproof maintainers knew this suggestion is coming, by the way, because I was respecting the terms of the coordinated disclosure.)

Closing Thoughts

Despite finding cryptography implementation flaws in Matric’s Olm library, my personal opinion on Matrix remains largely unchanged from 2022. I had already assumed it would not meet my bar for security.

Cryptography engineering is difficult because the vulnerabilities you’re usually dealing with are extremely subtle. (Here’s an unrelated example if you’re not convinced of this general observation.) As SwiftOnSecurity once wrote:

twitter.com/SwiftOnSecurity/st…

The people that developed Olm and Megolm has not proven themselves ready to build a Signal competitor. In balance, most teams are not qualified to do so.

I really wish the Matrix evangelists would accept this and stop trying to cram Matrix down other people’s throats when they’re talking about problems with other platforms entirely.

More important for the communities of messaging apps:

You don’t need to be a Signal competitor. Having E2EE is a good thing on its own merits, and really should be table stakes for any social application in 2024.

It’s only when people try to advertise their apps as a Signal alternative (or try to recommend it instead of Signal), and offer less security, that I take offense.

Just be your own thing.

My work-in-progress proposal to bring end-to-end encryption to the Fediverse doesn’t aim to compete with Signal. It’s just meant to improve privacy, which is a good thing to do on its own merits.

If I never hear Matrix evangelism again after today, it would be far too soon.

If anyone feels like I’m picking on Matrix, don’t worry: I have far worse things to say about Telegram, Threema, XMPP+OMEMO, Tox, and a myriad other projects that are hungry for Signal’s market share but don’t measure up from a cryptographic security perspective.

If Signal fucked up as bad as these projects, my criticism of Signal would be equally harsh. (And remember, I have looked at Signal before.)

Addendum (2024-08-14)

One of the lead Matrix devs posted a comment on Hacker News after this blog post went live that I will duplicate here:

the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc.

if you actually look at % of impacted clients, it’s tiny.

meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented on in the readme and github.com/matrix-org/olm/issu… since day 1.

So the Matrix developers already knew about these vulnerabilities, but deliberately didn’t fix them, for years.

Congratulations, you’ve changed my stance. It used to be “I don’t consider Matrix a Signal alternative and they’ve had some embarrassing and impactful crypto bugs but otherwise I don’t care”. Now it’s a stronger stance:

Don’t use Matrix.

I had incorrectly assumed ignorance, when it was in fact negligence.

There’s no reasonable world in which anyone should trust the developers of cryptographic software (i.e., libolm) that deliberately ships with side-channels for years, knowing they’re present, and never bother to fix them.

This is fucking clownshoes.

#crypto #cryptography #endToEndEncryption #Matrix #sideChannels #vuln

Soatok

2024-07-31 16:25:41

What Does It Mean To Be A Signal Competitor?

A lot of recent (and upcoming) blog posts I’ve written, and Fediverse discussions I’ve participated in, have been about the security of communication products.

My criticism of these products is simply that, from a cryptography and security perspective, they’re not a real competitor to Signal.

For all its other faults, Signal sets the bar for secure private messaging. It’s a solid security tool, even if its user experience and feature set leaves a lot of people disappointed. I highly recommend it over, say, Telegram.

In response to my post about jettisoning Telegram, quite a few people have tried to evangelize other products. For example:

Edit: Oh yeah, DON’T USE SIGNAL. Use Matrix instead, offers the benefits of signal without the drawbacks of lack of sync and phone number requirements and is decentralized. The fact that everyone is going gaga for signal as “the BEST messaging app” should be a big red flag in and of itself, because hype trains like this aren’t organic, just saying.

Draconic_NEO on pawb.social

So, let me explain what it means for a communication product to qualify as a Signal competitor from the perspective of someone whose job involves auditing cryptography implementations.

The Minimum Bar to Clear

Open Source

Every private messaging app must be open source in order to qualify as a Signal competitor.

If it’s not open source, it’s not even worth talking about.

End-to-End Encryption

Messages MUST be end-to-end encrypted. This means that you encrypt on one participant’s device, decrypt on another’s, and nobody in the middle can observe plaintext.

When I say MUST, I mean the RFC 2119 keyword.

There must never be a “transmit plaintext” option. No excuses. Secure cryptography is not interoperable with insecure cryptography. If you allow a “transmit plaintext” mode for any reason whatsoever, you have failed to build an encryption product that meets the bar.

This disqualifies Matrix.

This disqualifies Telegram.

This disqualifies XMPP + OMEMO.

This alone disqualifies a lot of so-called private messaging apps.

This doesn’t mean your product is insecure, or that I’m aware of any specific ways to break it.

It just doesn’t occupy the same mindshare as Signal, which only transmits encrypted data and doesn’t have a plaintext protocol to downgrade to.

Therefore, it’s not a goddamn Signal alternative.

How You Encrypt Matters

Signal normalized the use of AES-256-CBC with HMAC-SHA256.

Facebook’s “Secret Conversations” feature deviated from this and preferred AES-GCM for attachments, but this bit them when the Invisible Salamanders attack was discovered.

The way Signal uses AES+HMAC is fine for their use case, but building a secure committing AEAD mode (rather than merely AE) out of these primitives is nontrivial.

If you’re aiming to compete with Signal on security, you should, at minimum, expect to engage with a cryptography auditing firm at least once a year to review and re-review your protocol designs and implementations.

I Will Heavily Scrutinize Your Group Messaging Protocols

Group messaging is one of those topics that might sound easy if you can do peer-to-peer messaging securely, but is catastrophically difficult once you get into the details.

See also: My blog post about Threema.

If you want a starting point, look at RFC 9420 (Messaging Layer Security, which is a group key agreement protocol for messaging apps).

How You Manage Keys Matters

Tox attempted to build atop NaCl’s crypto_box interface, but this is not suitable for a general purpose secure messaging due to a lack of KCI Security.

Key management (which is the focus of an upcoming blog post) is a problem that almost everyone underestimates. It’s also the most user-facing aspect of these messaging applications.

WhatsApp uses Key Transparency to scale user trust. I’m proposing something similar for E2EE for the Fediverse.

This is a much better strategy than expecting users to manually verify “fingerprints”.

Don’t look at OpenPGP as a role model when it comes to user experience. Johnny still cannot fucking encrypt.

Your Feature Should Not Bypass Privacy

Want to add all sorts of frills, like video chat or some dumb bullshit with AI and/or blockchain to secure the attention of venture capitalist investors?

You’d better not implement them in such a way that leaks users’ messages or search queries to your service.

The main reason Signal is “missing” features is because they are thoughtful about how these features are designed and implemented.

Guess what happens if you prioritize shipping features over privacy and cryptography engineering?

That’s right: You stop being a contender for a Signal alternative.

So What?

If your fave isn’t a viable alternative to Signal, don’t fucking recommend it to people in response to me recommending Signal.

That’s all I ask.

Art: Scruff

But what about…?

I’m not here to discuss your use cases, or usability, or anything else. I’m also not saying that Signal is perfect!

Signal is a private messaging app that I would feel safe recommending whistleblowers to use. It meets all these requirements.

In order to be a Signal competitor, no matter how much you like your app, it needs to meet them too, otherwise it isn’t a Signal competitor. Them’s the rules!

AJ

There may be other requirements that are more important to you, that Signal doesn’t meet. That’s fine! You can like other things.

But unless your favorite widget also meets all of the things on this page, it’s not a valid competitor from a security and privacy perspective, and therefore I don’t want to fucking hear about it in response to me saying “use Signal until something better comes along”.

Capiche?

Addendum (2024-08-01)

Since I originally posted this, there have been a lot of opinions expressed and questions asked about messaging apps that have nothing to do with cryptographic security.

Those are good discussions to have, elsewhere. Hell, most of this discussion would be a better response to my other blog post than this one.

The goal of this post was to specify what the minimum bar is for a different app to qualify as a Signal competitor. It’s written from the perspective of someone whose career is in applied cryptography.

If you have thoughts, feelings, opinions, questions, or concerns about messaging apps (including but not limited to Signal), that’s wonderful.

But this specific blog post is not the correct place to voice them!

Especially if the first line of your response is “you’re too focused on [technology, security, cryptography] (select appropriate)”.

Because… no shit? That’s the entire point of this particular post. It’s narrowly scoped for a reason. Please respect that.

My upcoming vulnerability disclosure in Matrix will make the same point, but I wanted a separate, less distracting blog post to link people to when someone tries to evangelize another chat app instead of Signal, especially if they make security claims while doing so.

#cryptography #endToEndEncryption #privateMessengers #Signal

Deploying key transparency at WhatsApp - Engineering at Meta

With key transparency, WhatsApp provides a set of proofs that affirms the correctness of public encryption keys.

^{Kevin Lewi (Meta)}

Invisible Salamanders Are Not What You Think

Ever since the Invisible Salamanders paper was published, there has been a quiet renaissance within my friends and colleagues in applied cryptography for studying systems that use Authenticated Encryption with Associated Data (AEAD) constructions, understanding what implicit assumptions these systems make about the guarantees of the AEAD mode they chose to build upon, and the consequences of those assumptions being false.

I’ve discussed Invisible Salamanders several times throughout this blog, from my criticisms of AES-GCM and XMPP + OMEMO to my vulnerability disclosures in Threema.

Five years after Invisible Salamanders, it’s become clear to me that many software developers do not fully appreciate the underlying problem discussed in the Invisible Salamanders paper, even when I share trivial proof-of-concept exploits.

Background

Fast AEAD constructions based on polynomial MACs, such as AES-GCM and ChaCha20-Poly1305, were designed to provide confidentiality and integrity for the plaintext data, and optionally integrity for some additional associated data, in systems where both parties already negotiated one shared symmetric key.

The integrity goals of the systems that adopted these AEAD constructions were often accompanied by performance goals–usually to prevent Denial of Service (DoS) attacks in networking protocols. Verification needed to be very fast and consume minimal resources.

In this sense, AEAD constructions were an incredible success. So successful, in fact, that most cryptographers urge application developers to use one of the fast AEAD modes as the default suggestion without looking deeper at the problem being solved. This is a good thing, because most developers will choose something stupid like ECB mode in the absence of guidance from cryptographers, and AEAD modes are much, much safer than any hand-rolled block cipher modes.

The problem is, that one tiny little assumption that both parties (sender, recipient) for a communication have agreed on exactly one symmetric key for use in the protocol.

Fast MACs Are Not Key-Committing

Cryptographers have concluded that AEAD constructions based on polynomial MACs–while great for performance and rejection of malformed packets without creating DoS risks–tend to make the same assumption. This is even true of misuse-resistant modes like AES-GCM-SIV and extended-nonce constructions like XSalsa20-Poly1305.

When discussing this implicit assumption of only one valid key in the systems that use these AEAD modes, we say that the modes are not key-committing. This terminology is based on what happens when this assumption is false.

Consequently, you can take a single, specially crafted ciphertext (with an authentication tag) and decrypt it under multiple different keys. The authentication tags will be valid for all keys, and the plaintext will be different.

Art: Swizz

What does this look like in practice?

Consider my GCM exploit, which was written to generate puzzle ciphertexts for the DEFCON Furs badge challenge a few years ago. How it works is conceptually simple (although the actual mechanics behind step 4 is a bit technical):

1. Generate two keys.
   There’s nothing special about these keys, or their relationship to each other, and can be totally random. They just can’t be identical or the exploit is kind of pointless.
2. Encrypt some blocks of plaintext with key1.
3. Encrypt some more blocks of plaintext with key2.
4. Calculate a collision block from the ciphertext in the previous two steps–which is just a bit of polynomial arithmetic in GF(2^128)
5. Return the ciphertext (steps 2, 3, 4) and authentication tag calculated over them (which will collide for both keys).

A system that decrypts the output of this exploit under key1 will see some plaintext, followed by some garbage, followed by 1 final block of garbage.

If the same system decrypts under key2, it will see some garbage, followed by some plaintext, followed by 1 final block of garbage.

For many file formats, this garbage isn’t really a problem. Additionally, a bit more precomputation allows you to choose garbage that will be more advantageous to ensuring both outputs are accepted as “valid” by the target system.

For example, choosing two keys and a targeted nonce may allow both the valid plaintext and garbage blocks to begin with a PDF file header.

If you’re familiar with the file polyglot work of Ange Albertini, you can use this to turn the Invisible Salamanders problem into an artform.

And this is just the simple attack!

The Invisible Salamanders paper outlined a more advanced variant (with a proof of concept) in Section 3.2, which doesn’t suffer from nearly as much garbage data as the simple attack.

As Bruce Schneier often says, “Attacks only get better, they never get worse.”

Why is it called Invisible Salamanders?

The proof-of-concept used in the paper involved sending one picture (of a salamander) over an end-to-end encrypted messaging app, but when the recipient flagged it as abusive, the moderator saw a different picture.

youtube.com/watch?v=3M1jIO-jLH…

Thus, the salamander was invisible to the moderators of the encrypted messaging app.

As for the choice of a “salamander”, I’ve been told by friends familiar with the research that was inspired by the original name of the Signal Protocol being “Axolotl”.

But, like, who cares about these details besides me? It’s a cute and memorable name.

What are the consequences of violating the “one key” assumption?

That depends entirely on what your system does!

In Database Cryptography Fur the Rest of Us, I discussed the use of AEAD modes to prevent confused deputy attacks. This works great, but if you’re building an application that supports multi-tenancy, you suddenly have to care about this issue again.

An earlier design for OPAQUE, a password authenticated key exchange algorithm, was broken by a partitioning oracle attack due to building atop AEAD modes that are not key-committing. This let an attacker recover passwords from Shadowsocks proxy servers with a complexity similar to a binary search algorithm.

These are two very different impacts from the same weakness, which I believe is a significant factor for why the Invisible Salamanders issue isn’t more widely understood.

Sometimes violating the “one key” assumption that went into fast AEAD modes based on Polynomial MACs completely destroys the security of your system.

Other times, it opens the door for a high-complexity but low-impact behavior that simply violates the principle of least astonishment but doesn’t buy the attacker anything useful.

They Just Don’t Get It

The Invisible Salamanders issue is relevant in any system that uses symmetric-key encryption where more than one key can be valid.

This includes, but is not limited to:

• Multi-tenant data warehouses
• Group messaging protocols
  
  • It’s sometimes tempting to discount group messaging as a relevant consideration if your experience is “emulated groups atop 1-to-1 messaging”, but there are protocols that establish a Group Key (i.e., RFC 9420) and then use that for all group messages.

  
  

• Envelope encryption schemes with multiple wrapping keys
• Bearer tokens (such as JSON Web Tokens) in systems that utilize Key IDs

Systems can mitigate this issue by introducing an explicit key commitment scheme (based on a cryptographic hash rather than a polynomial MAC) or by using a committing cipher mode (such as AES + HMAC, if done carefully).

However, most of the time, this advice falls on deaf ears whenever this concern is brought up by a cryptography engineer who’s more aware of this issue.

“Abuse reporting? We don’t have no stinking abuse reporting!”

The most common misunderstanding is, “We don’t have a report abuse feature, so this issue doesn’t affect us.”

This is because the Invisible Salamanders talk and paper focused on how it could be leveraged to defeat abuse reporting tools and bypass content moderation.

In my experience, many security teams would read the paper and conclude that it only impacts abuse reporting features and not potentially all systems that allow multiple symmetric keys in a given context.

Another Exploit Scenario

Imagine you’re building a Data Loss Prevention product that integrates with corporate file-sharing and collaboration software (e.g. ownCloud) for small and medium businesses.

One day, someone decides to ship an end-to-end encryption feature to the file-sharing software that uses AES-GCM to encrypt files, and then encrypts the keys to each recipient’s public key. This is basically the envelope encryption use-case above.

So, you dutifully update your integration to act as another “user”, whose public key must be included in all E2EE transfers, and will block download of ciphertexts it cannot decrypt OR contains sensitive information.

And this works, until an insider threat clever enough to abuse the Invisible Salamanders issue comes along.

In order for said insider threat (e.g., a senior business analyst) to leak sensitive data (e.g., anything that would be useful for illegal insider trading) to another person that shouldn’t have access to it (e.g., a store clerk that’s talking to the press), they just have to do this:

1. Encrypt the data they want to exfiltrate using key1.
2. Encrypt some innocuous data that won’t trigger your DLP product, using key2.
3. Ensure that both messages encrypt to the same ciphertext and authentication tag.
4. Give their recipient key1, give everyone else (including your DLP software) key2.

Bam! File leaked, and everyone’s none the wiser, until it’s too late. Let’s actually imagine what happens next:

A random store clerk has leaked sensitive data to the press that only a few analysts had access to.

The only communication between the analyst and the store clerk is a file that was shared to all employees, using the E2EE protocol. No emails or anything else were identified.

Your DLP product didn’t identify any other communications between these two, but somehow the store clerk has the data on their desktop.

A detailed forensics analysis may eventually figure out what happened, but by then, the damage is done and your product’s reputation is irrecoverably damaged.

All because the hypothetical E2EE protocol didn’t include a key-commitment mechanism, and nobody identified this deficit in their designs.

This isn’t to endorse DLP solutions at all, but rather, to highlight one of the many ways that the Invisible Salamander issue can be used creatively by clever attackers.

Art: AJ

“Couldn’t you do the same with steganography?”

No, the attack is very different from stego.

Stego is about hiding a message in plain sight, so that only the person that knows where/how to look can find it.

The Invisible Salamanders attack lets you send one ciphertext through a network then selectively decrypt it to one of two plaintexts, depending on which key you reveal to each participant.

In the Invisible Salamanders paper and talk, they used this to send “abusive” messages to a recipient that the moderator would not see. Thus, invisible.

In one, the message is always emitted to anyone who knows how to find it. In the other, the attacker selects which you see, even if you have mechanisms to ensure you’re seeing the same ciphertext. It’s not a subtle difference.

Mitigation Techniques

There are multiple ways to mitigate the risk of Invisible Salamanders in a cryptosystem.

1. Use HMAC, or (failing that) something built atop cryptographic hash functions, rather than a Polynomial MAC.
2. Use an AEAD cipher designed with multi-recipient integrity as a security goal.
3. Compute a non-invertible, one-way commitment of the encryption key.

A trivial mitigation looks like this:

class SoatokExampleEncryptor { const NEW_ENCRYPT_KEY = 'myProtocol$encryptKey'; const NEW_COMMITMENT = 'myProtocol$commitment'; public function __construct(#[SensitiveParameter] private string $key) {} /** * Let's assume we're starting with a simple AES-GCM wrapper */ public function legacyEncrypt(string $plaintext, string $assocData = ''): string { $nonce = random_bytes(12); $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $this->key, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $nonce . $ciphertext . $tag; } /** * An improved function looks something like this */ public function newEncrypt(string $plaintext, string $assocData = ''): string { // Avoid birthday bound issues with 256-bits of randomness $longerNonce = random_bytes(32); // Derive a subkey and synthetic nonce $tmp = hash_hkdf('sha512', $this->key, 44, self::NEW_ENCRYPT_KEY . $longerNonce); $encKey = substr($tmp, 0, 32); $nonce = substr($tmp, 32); // New: Key commitment $commitment = hash_hkdf('sha512', $this->key, 32, self::NEW_COMMITMENT . $longerNonce); // Most of this is unchanged $tag = ''; $ciphertext = openssl_encrypt( $plaintext, 'aes-256-gcm', $encKey, OPENSSL_RAW_DATA, $nonce, $tag, $assocData ); return $longerNonce . $commitment . $ciphertext . $tag; }}

And then the decryption logic would recalculate the commitment, and compare it with the stored value, in constant-time.

It’s important that the commitment be stored with the ciphertext, rather than bundling it with the key.

(It may be worthwhile to also include the commitment in the associated data, to add a mechanism against downgrade attacks.)

The Lesson to Learn

If you’re building a network protocol that uses AEAD to encrypt data over an insecure network (e.g., WireGuard), keep up the good work.

If you’re doing anything more involved than that, at the application layer, pause for a moment and consider whether your system will ever need multiple valid symmetric keys at once.

And, if the answer is “yes”, then you should always explicitly add a key-commitment mechanism to your system design.

(Hire a cryptographer if you’re not sure how to proceed.)

In my opinion, hemming and hawing over whether there’s a significant impact to the Invisible Salamanders issue is a worse use of your time than just solving it directly.

Eventually, I expect a new generation of AEAD modes will be standardized that explicitly provide key-commitment.

When these new designs are standardized, widely supported, and sufficiently trusted by experts, feel free to update my advice to “prefer using those modes” instead.

Header art: Harubaki, CMYKat, and a photo by Brian Gratwicke. Poorly photoshopped by myself.

#AEAD #AESGCM #InvisibleSalamanders #randomKeyRobustness #symmetricCryptography

KEM Trails – Understanding Key Encapsulation Mechanisms

There is, at the time of this writing, an ongoing debate in the Crypto Research Forum Group (CFRG) at the IETF about KEM combiners.

One of the participants, Deirdre Connolly, wrote a blog post titled How to Hold KEMs. The subtitle is refreshingly honest: “A living document on how to juggle these damned things.”

Deirdre also co-authored the paper describing a Hybrid KEM called X-Wing, which combines X25519 with ML-KEM-768 (which is the name for a standardized tweak of Kyber, which I happened to opine on a few years ago).

After sharing a link to Deirdre’s blog in a few places, several friendly folk expressed confusion about KEMs in general.

So very briefly, here’s an introduction to Key Encapsulation Mechanisms in general, to serve as a supplementary resource for any future discussion on KEMs.

You shouldn’t need to understand lattices or number theory, or even how to read a mathematics paper, to understand this stuff.

CMYKat

Building Intuition for KEMs

For the moment, let’s suspend most real-world security risks and focus on a simplified, ideal setting.

To begin with, you need some kind of Asymmetric Encryption.

Asymmetric Encryption means, “Encrypt some data with a Public Key, then Decrypt the ciphertext with a Secret Key.” You don’t need to know, or even care, about how it works at the moment.

Your mental model for asymmetric encryption and decryption should look like this:

interface AsymmetricEncryption { encrypt(publicKey: CryptoKey, plaintext: Uint8Array); decrypt(secretKey: CryptoKey, ciphertext: Uint8Array);}

As I’ve written previously, you never want to actually use asymmetric encryption directly.

Using asymmetric encryption safely means using it to exchange a key used for symmetric data encryption, like so:

// Alice sends an encrypted key to BobsymmetricKey = randomBytes(32)sendToBob = AsymmetricEncryption.encrypt( bobPublicKey, symmetricKey)// Bob decrypts the encrypted key from Alicedecrypted = AsymmetricEncryption.decrypt( bobSecretKey, sendToBob)assert(decrypted == symmetricKey) // true

You can then use symmetricKey to encrypt your actual messages and, unless something else goes wrong, only the other party can read them. Hooray!

And, ideally, this is where the story would end. Asymmetric encryption is cool. Don’t look at the scroll bar.

CMYKat

Unfortunately

The real world isn’t as nice as our previous imagination.

We just kind of hand-waved that asymmetric encryption is a thing that happens, without further examination. It turns out, you have to examine further in order to be secure.

The most common asymmetric encryption algorithm deployed on the Internet as of February 2024 is called RSA. It involves Number Theory. You can learn all about it from other articles if you’re curious. I’m only going to describe the essential facts here.

Keep in mind, the primary motivation for KEMs comes from post-quantum cryptography, not RSA.

CMYKat

From Textbook RSA to Real World RSA

RSA is what we call a “trapdoor permutation”: It’s easy to compute encryption (one way), but decrypting is only easy if you have the correct secret key (the other way).

RSA operates on large blocks, related to the size of the public key. For example: 2048-bit RSA public keys operate on 2048-bit messages.

Encrypting with RSA involves exponents. The base of these exponents is your message. The outcome of the exponent operation is reduced, using the modulus operator, by the public key.

(The correct terminology is actually slightly different, but we’re aiming for intuition, not technical precision. Your public key is both the large modulus and exponent used for encryption. Don’t worry about it for the moment.)

If you have a very short message, and a tiny exponent (say, 3), you don’t need the secret key to decrypt it. You can just take the cube-root of the ciphertext and recover the message!

That’s obviously not very good!

To prevent this very trivial weakness, cryptographers proposed standardized padding schemes to ensure that the output of the exponentiation is always larger than the public key. (We say, “it must wrap the modulus”.)

The most common padding mode is called PKCS#1 v1.5 padding. Almost everything that implements RSA uses this padding scheme. It’s also been publicly known to be insecure since 1998.

The other padding mode, which you should be using (if you even use RSA at all) is called OAEP. However, even OAEP isn’t fool proof: If you don’t implement it in constant-time, your application will be vulnerable to a slightly different attack.

This Padding Stinks; Can We Dispense Of It?

It turns out, yes, we can. Safely, too!

We need to change our relationship with our asymmetric encryption primitive.

Instead of encrypting the secret we actually want to use, let’s just encrypt some very large random value.

Then we can use the result with a Key Derivation Function (which you can think of, for the moment, like a hash function) to derive a symmetric encryption key.

class OversimplifiedKEM { function encaps(pk: CryptoKey) { let N = pk.getModulus() let r = randomNumber(1, N-1) let c = AsymmetricEncryption.encrypt(pk, r) return [c, kdf(r)] } function decaps(sk: CryptoKey, c: Uint8Array) { let r2 = AsymmetricEncryption.decrypt(sk, c) return kdf(r2) }}

In the pseudocode above, the actual asymmetric encryption primitive doesn’t involve any sort of padding mode. It’s textbook RSA, or equivalent.

KEMs are generally constructed somewhat like this, but they’re all different in their own special, nuanced ways. Some will look like what I sketched out, others will look subtly different.

Understanding that KEMs are a construction on top of asymmetric encryption is critical to understanding them.

It’s just a slight departure from asymmetric encryption as most developers intuit it.

Cool, we’re almost there.

CMYKat

The one thing to keep in mind: While this transition from Asymmetric Encryption (also known as “Public Key Encryption”) to a Key Encapsulation Mechanism is easy to follow, the story isn’t as simple as “it lets you skip padding”. That’s an RSA specific implementation detail for this specific path into KEMs.

The main thing you get out of KEMs is called IND-CCA security, even when the underlying Public Key Encryption mechanism doesn’t offer that property.

CMYKat

IND-CCA security is a formal notion that basically means “protection against an attacker that can alter ciphertexts and study the system’s response, and then learn something useful from that response”.

IND-CCA is short for “indistinguishability under chosen ciphertext attack”. There are several levels of IND-CCA security (1, 2, and 3). Most modern systems aim for IND-CCA2.

Most people reading this don’t have to know or even care what this means; it will not be on the final exam. But cryptographers and their adversaries do care about this.

What Are You Feeding That Thing?

Deirdre’s blog post touched on a bunch of formal security properties for KEMs, which have names like X-BIND-K-PK or X-BIND-CT-PK.

Most of this has to deal with, “What exactly gets hashed in the KEM construction at the KDF step?” (although some properties can hold even without being included; it gets complicated).

For example, from the pseudocode in the previous section, it’s more secure to not only hash r, but also c and pk, and any other relevant transcript data.

class BetterKEM { function encaps(pk: CryptoKey) { let N = pk.getModulus() let r = randomNumber(1, N-1) let c = AsymmetricEncryption.encrypt(pk, r) return [c, kdf(pk, c, r)] } function decaps(sk: CryptoKey, c: Uint8Array) { let pk = sk.getPublickey() let r2 = AsymmetricEncryption.decrypt(sk, c) return kdf(pk, c, r2) }}

In this example, BetterKem is greatly more secure than OversimplifiedKEM, for reasons that have nothing to do with the underlying asymmetric primitive. The thing it does better is commit more of its context into the KDF step, which means that there’s less pliability given to attackers while still targeting the same KDF output.

If you think about KDFs like you do hash functions (which they’re usually built with), changing any of the values in the transcript will trigger the avalanche effect: The resulting calculation, which is not directly transmitted, is practically indistinguishable from random bytes. This is annoying to try to attack–even with collision attack strategies (birthday collision, Pollard’s rho, etc.).

However, if your hash function is very slow (i.e., SHA3-256), you might be worried about the extra computation and energy expenditure, especially if you’re working with larger keys.

Specifically, the size of keys you get from ML-KEM or other lattice-based cryptography.

That’s where X-Wing is actually very clever: It combines X25519 and ML-KEM-768 in such a way that binds the output to both keys without requiring the additional bytes of ML-KEM-768 ciphertext or public key.

From the X-Wing paper.

However, it’s only secure to use it this way because of the specific properties of ML-KEM and X25519.

Some questions may come to mind:

1. Does this additional performance hit actually matter, though?
2. Would a general purpose KEM combiner be better than one that’s specially tailored to the primitives it uses?
3. Is it secure to simply concatenate the output of multiple asymmetric operations to feed into a single KDF, or should a more specialized KDF be defined for this purpose?

Well, that’s exactly what the CFRG is debating!

CMYKat

Closing Thoughts

KEMs aren’t nearly as arcane or unapproachable as you may suspect. You don’t really even need to know any of the mathematics to understand them, though it certainly does help.

I hope that others find this useful.

Header art by Harubaki and AJ.

#asymmetricCryptography #cryptography #KDF #KEM #keyEncapsulationMechanism #postQuantumCryptography #RSA

It’s Time for Furries to Stop Using Telegram

I have been a begrudging user of Telegram for years simply because that’s what all the other furries use, despite their cryptography being legendarily bad.

When I signed up, I held my nose and expressed my discontent at Telegram by selecting a username that’s a dig at MTProto’s inherent insecurity against chosen ciphertext attacks: IND_CCA3_Insecure.

Art: CMYKat

I wrote about Furries and Telegram before, and included some basic privacy recommendations. As I said there: Telegram is not a private messenger. You shouldn’t think of it as one.

Recent Developments

Telegram and Elon Muck have recently begun attacking Signal and trying to paint it as insecure.

Matthew Green has a Twitter thread (lol) about it, but you can also read a copy here (archive 1, archive 2, PDF).

twitter.com/matthew_d_green/st…

twitter.com/matthew_d_green/st…

twitter.com/matthew_d_green/st…

twitter.com/matthew_d_green/st…

Et cetera.

This is shitty, and exacerbates a growing problem on Telegram: The prevalence of crypto-bros and fascist groups using it to organize.

Why Signal is Better for Furries

First, Signal has sticker packs now. If you want to use mine, here you go.

For years, the main draw for furries to Telegram over Signal was sticker packs. This is a solved problem.

Second, you can setup a username and keep your phone number private. You don’t need to give your phone number to strangers anymore!

(This used to be everyone’s criticism of Signal, but the introduction of usernames made it moot.)

Finally, it’s trivial for Americans to setup a second Signal account using Twilio or Google Voice, so you can compartmentalize your furry posting from the phone number your coworkers or family is likely to know.

(Note: I cannot speak to how to deal with technology outside of America, because I have never lived outside America for any significant length of time and do not know your laws. If this is relevant to you, ask someone in your country to help figure out how to navigate technological and political issues pertinent to your country; I am not local to you and have no fucking clue.)

The last two considerations were really what stopped furries (or queer people in general, really) from using Signal.

Why Signal?

There are two broadly-known private messaging apps that use state-of-the-art cryptography to ensure your messages are private, and one of them is owned by Meta (a.k.a., Facebook, which owns WhatsApp). So Signal is the only real option in my book.

That being said, Cwtch certainly looks like it may be promising in the near future. However, I have not studied its cryptography in depth yet. Neither has it been independently audited to my knowledge.

It’s worth pointing out that the lead developer of Cwtch is wrote a book titled Queer Privacy, so she’s overwhelmingly more likely to be receptive to the threat models faced by the furry community (which is overwhelmingly LGBTQ+).

For the sake of expedience, today, Signal is a “yes” and Cwtch is a hopeful “maybe”.

How I Setup a Second Signal Account

I own a Samsung S23, which means I can’t just use the vanilla Android tutorials for setting up a second profile on my device. Instead, I had to use the “Secure Folder” feature. The Freedom of the Press Foundation has more guidance worth considering.

If you don’t own a Samsung phone, you don’t need to bother with this “Secure Folder” feature (as the links above will tell you). You can just set up a work profile and get the same result! You probably also can’t access the same feature, since that’s a Samsung exclusive idiom. Don’t sweat it.

I don’t know anything about Apple products, so I can’t help you there, but there’s probably a way to set it up for yourself too. (If not, maybe consider this a good reason to stop giving abusive corporations like Apple money?)

The other piece of the puzzle you need is a second phone number. Google Voice is one way to acquire one; the other is to setup a Twilio account. There are plenty of guides online for doing that.

(Luckily, I’ve had one of these for several years, so I just used that.)

Why does Signal require a phone number?

The historical reason is that Signal was a replacement for text messaging (a.k.a., SMS). That’s probably still the official reason (though they don’t support SMS anymore).

From what I understand, the Signal development team has always been much more concerned about privacy for people that own mobile phones, but not computers, than they were concerned about the privacy of people that own computers, but not mobile phones.

After all, if you pick a random less privileged person, especially homeless or from a poor country, they’re overwhelmingly more likely to have a mobile phone than a computer. This doesn’t scratch the itch of people who would prefer to use PGP, but it does prioritize the least privileged people’s use case.

Their workflow, therefore, optimized for people that own a phone number. And so, needing a phone number to sign up wasn’t ever a problem they worried about for the people they were most interested in protecting.

Fortunately, using Signal doesn’t immediately reveal your phone number to anyone you want to chat with, ever since they introduced usernames. You still need one to register.

Tell Your Friends

I understand that the network effect is real. But it’s high time furries jettisoned Telegram as a community.

Lazy edit of the “Friendship Ended” meme

Finally, Signal is developed and operated by a non-profit. You should consider donating to them so that we can bring private messaging to the masses.

Addendum (2024-05-15)

I’ve been asked by several people about my opinions on other platforms and protocols.

Specifically, Matrix. I do not trust the Matrix developers to develop or implement a secure protocol for private messaging.

I don’t have an informed opinion about Signal forks (Session, Molly, etc.). Generally, I don’t review cryptography software for FOSS maximalists with skewed threat models unless I’m being paid to do so, and that hasn’t happened yet.

#endToEndEncryption #furries #FurryFandom #privacy #Signal #Telegram

Introducing Alacrity to Federated Cryptography

There are two mental models for designing a cryptosystem that offers end-to-end encryption to all of its users.

The first is the Signal model.

Predicated on Moxie’s notion that the ecosystem is moving, Signal (and similar apps) maintain some modicum of centralized control over the infrastructure and deployment of their app. While there are obvious downsides to this approach, it allows them to quickly roll out ecosystem-wide changes to their encryption protocols without having to deal with third-party clients falling behind.

The other is the federated model, which is embraced by Matrix, XMPP with OMEMO, and other encrypted chat apps and protocols.

This model can be attractive to a lot of people whose primary concern is data sovereignty rather than cryptographic protections. (Most security experts care about both aspects, but we differ in how they rank the two priorities relative to each other.)

As I examined in my criticisms of Matrix and XMPP+OMEMO, they kind of prove Moxie’s point about the ecosystem:

• Two years after the Matrix team deprecated their C implementation of Olm in favor of a Rust library, virtually all of the clients that actually switched (as of the time of my blog post disclosing vulnerabilities in their C library) were either Element, or forks of Element. The rest were still wrapping libolm.
• Most OMEMO libraries are still stuck on version 0.3.0 of the specification, and cannot communicate with XMPP+OMEMO implementations that are on newer versions of the specification.

And this is personally a vexing observation, for two reasons:

1. I don’t like that Moxie’s opinion is evidently more correct when you look at the consequences of each model.
2. I’m planning to develop end-to-end encryption for direct messages on the Fediverse, and don’t want to repeat the mistakes of Matrix and OMEMO.
   (Aside from them mistakenly claiming to be Signal competitors, which I am not doing with my E2EE proposal or any implementations thereof.)

Fortunately, I have a solution to both annoyances that I intend to implement in my end-to-end encryption proposal.

Thus, I’d like to introduce Cryptographic Alacrity to the discussion.

Note: The term “crypto agility” was already coined by people who never learned from the alg=none vulnerability of JSON Web Tokens and think it’s A-okay to negotiate cryptographic primitives at run-time based on attacker-controllable inputs.

Because they got their foolish stink all over that term, I discarded it in favor of coining a new one. I apologize for the marginal increase in cognitive load this decision may cause in the future.

Cryptographic Alacrity

For readers who aren’t already familiar with the word “alacrity” from playing Dungeons & Dragons once upon a time, the Merriam-Webster dictionary defines Alacrity as:

promptness in response : cheerful readiness

Alacrity Definition & Meaning – Merriam Webster

When I describe a cryptography protocol as having “cryptographic alacrity”, I mean there is a built-in mechanism to enforce protocol upgrades in a timely manner, and stragglers (read: non-compliant implementations) will lose the ability to communicate with up-to-date software.

Alacrity must be incorporated into a protocol at its design phase, specified clearly, and then enforced by the community through its protocol library implementations.

The primary difference between Alacrity and Agility is that Alacrity is implemented through protocol versions and a cryptographic mechanism for enforcing implementation freshness across the ecosystem, whereas Agility is about being able to hot-swap cryptographic primitives in response to novel cryptanalysis.

This probably still sounds a bit abstract to some of you.

CMYKat

To best explain what I mean, let’s look at a concrete example. Namely, how I plan on introducing Alacrity to my Fediverse E2EE design, and then enforcing it henceforth.

Alacrity in E2EE for the Fediverse

One level higher in the protocol than bulk message and/or media attachment encryption will be a Key Derivation Function. (Probably HKDF, probably as part of a Double Ratchet protocol or similar. I haven’t specified that layer just yet.)

Each invocation of HKDF will have a hard-coded 256-bit salt particular to the protocol version that is currently being used.

(What most people would think to pass as the salt in HKDF will instead be appended to the info parameter.)

The protocol version will additionally be used in a lot of other places (i.e., domain separation constants), but those are going to be predictable string values.

The salt will not be predictable until the new version is specified. I will likely tie it to the SHA256 hash of a Merkle root of a Federated Public Key Directory instance and the nickname for each protocol version.

Each library will have a small window (probably no more than 3 versions at any time) of acceptable protocol versions.

A new version will be specified, with a brand new KDF salt, every time we need to improve the protocol to address a security risk. Additionally, we will upgrade the protocol version at least once a year, even if no security risks have been found in the latest version of the protocol.

If your favorite client depends on a 4 year old version of the E2EE protocol library, you won’t be able to silently downgrade security for all of your conversation participants. Instead, you will be prevented from talking to most users, due to incompatible cryptography.

Version Deprecation Schedule

Let’s pretend, for the sake of argument, that we launch the first protocol version on January 1, 2025. And that’s when the first clients start to be built atop the libraries that speak the protocols.

Assuming no emergencies occur, after 9 months (i.e., by October 1, 2025), version 2 of the protocol will be specified. Libraries will be updated to support reading (but not sending) messages encrypted with protocol v2.

Then, on January 1, 2026 at midnight UTC–or a UNIX timestamp very close to this, at least–clients will start speaking protocol v2. Other clients can continue to read v1, but they should write v2.

This will occur every year on the same cadence, but with a twist: After clients are permitted to start writing v3, support for reading v1 MUST be removed from the codebase.

This mechanism will hold true even if the protocols are largely the same, aside from tweaked constants.

AJ

What does Alacrity give us?

Alacrity allows third-party open source developers the capability of writing their own software (both clients and servers) without a significant risk of the Matrix and OMEMO problem (i.e., stale software being used years after it should have been deprecated).

By offering a sliding window of acceptable versions and scheduling planned version bumps to be about a year apart, we can minimize the risk of clock skew introducing outages.

Additionally, it provides third-party developers ample opportunity to keep their client software conformant to the specification.

It doesn’t completely eliminate the possibility of stale versions being used in silos. Especially if some developers choose malice. However, anyone who deviates from the herd to form their own cadre of legacy protocol users has deliberately or negligently accepted the compatibility risks.

Can you staple Alacrity onto other end-to-end encryption projects?

Not easily, no.

This is the sort of mechanism that needs to be baked in from day one, and everyone needs to be onboard at the project’s inception.

Retroactively trying to make Matrix, XMPP, OpenPGP, etc. have Cryptographic Alacrity after the horses left the barn is an exercise in futility.

I would like your help introducing Alacrity into my pet project.

I’d love to help, but I’m already busy enough with work and my own projects.

If you’re designing a product that you intend to sell to the public, talk to a cryptography consulting firm. I can point you to several that are reputable, but most of them are pretty good.

If you’re designing something for the open source community, and don’t have the budget to hire professionals, I’ll respond to such inquiries when my time, energy, and emotional bandwidth is available to do so. No promises on a timeline, of course.

AJ

How do you force old versions to get dropped?

You don’t.

The mechanism I mostly care about is forcing new versions get adopted.

Dropping support for older versions is difficult to mechanize. Being actively involved in the community to encourage implementations do this (if for no other reason to reduce risk by deleting dead code) is sufficient.

I am choosing to not make perfect the enemy of good with this proposal.

This isn’t a new idea.

No, it isn’t a new idea. The privacy-focused cryptocurrency, Zcash, has a similar mechanism build into their network upgrades.

It’s wildly successful when federated or decentralized systems adopt such a policy, and actually enforce it.

The only thing that’s novel in this post is the coined term, Cryptographic Alacrity.

Addendum – Questions Asked After This Post Went Live

Art: ScruffKerfluff

What about Linux Distros with slow release cycles?

What about them?!

In my vision of the future, the primary deliverable that users will actually hold will most likely be a Browser Extension, not a binary blob signed by their Linux distro.

They already make exceptions to their glacial release cadences for browsers, so I don’t anticipate whatever release cadence we settle on being a problem in practice.

For people who write clients with desktop software: Debian and Ubuntu let users install PPAs. Anyone who does Node.js development on Linux is familiar with them.

Why 1 year?

It was an example. We could go shorter or longer depending on the needs of the ecosystem.

How will you enforce the removal of old versions if devs don’t comply?

That’s a much lower priority than enforcing the adoption of new versions.

But realistically, sending pull requests to remove old versions would be the first step.

Publicly naming and shaming clients that refuse to drop abandoned protocol versions is always an option for dealing with obstinance.

We could also fingerprint clients that still support the old versions and refuse to connect to them at all, even if there is a version in common, until they update to drop the old version.

That said, I would hope to not need to go that far.

I really don’t want to overindex on this, but people keep asking or trying to send “what about?” comments that touch on this question, so now I’m writing a definitive statement to hopefully quell this unnecessary discourse.

The ubiquitous adoption of newer versions is a much higher priority than the sunsetting of old versions. It should be obvious that getting your users to use the most secure mode available is intrinsically a net-positive.

If your client can negotiate in the most secure mode available (i.e., if we move onto post-quantum cryptography), and your friends’ clients enforce the correct minimum version, it doesn’t really matter so much if your client in particular is non-compliant.

Focusing so much on this aspect is a poor use of time and emotional bandwidth.

Header art also made by AJ.

#cryptographicAgility #cryptographicAlacrity #cryptography #endToEndEncryption #fediverse #Matrix #OMEMO #XMPP

Soatok

2024-07-31 16:25:41

What Does It Mean To Be A Signal Competitor?

A lot of recent (and upcoming) blog posts I’ve written, and Fediverse discussions I’ve participated in, have been about the security of communication products.

My criticism of these products is simply that, from a cryptography and security perspective, they’re not a real competitor to Signal.

For all its other faults, Signal sets the bar for secure private messaging. It’s a solid security tool, even if its user experience and feature set leaves a lot of people disappointed. I highly recommend it over, say, Telegram.

In response to my post about jettisoning Telegram, quite a few people have tried to evangelize other products. For example:

Edit: Oh yeah, DON’T USE SIGNAL. Use Matrix instead, offers the benefits of signal without the drawbacks of lack of sync and phone number requirements and is decentralized. The fact that everyone is going gaga for signal as “the BEST messaging app” should be a big red flag in and of itself, because hype trains like this aren’t organic, just saying.

Draconic_NEO on pawb.social

So, let me explain what it means for a communication product to qualify as a Signal competitor from the perspective of someone whose job involves auditing cryptography implementations.

The Minimum Bar to Clear

Open Source

Every private messaging app must be open source in order to qualify as a Signal competitor.

If it’s not open source, it’s not even worth talking about.

End-to-End Encryption

Messages MUST be end-to-end encrypted. This means that you encrypt on one participant’s device, decrypt on another’s, and nobody in the middle can observe plaintext.

When I say MUST, I mean the RFC 2119 keyword.

There must never be a “transmit plaintext” option. No excuses. Secure cryptography is not interoperable with insecure cryptography. If you allow a “transmit plaintext” mode for any reason whatsoever, you have failed to build an encryption product that meets the bar.

This disqualifies Matrix.

This disqualifies Telegram.

This disqualifies XMPP + OMEMO.

This alone disqualifies a lot of so-called private messaging apps.

This doesn’t mean your product is insecure, or that I’m aware of any specific ways to break it.

It just doesn’t occupy the same mindshare as Signal, which only transmits encrypted data and doesn’t have a plaintext protocol to downgrade to.

Therefore, it’s not a goddamn Signal alternative.

How You Encrypt Matters

Signal normalized the use of AES-256-CBC with HMAC-SHA256.

Facebook’s “Secret Conversations” feature deviated from this and preferred AES-GCM for attachments, but this bit them when the Invisible Salamanders attack was discovered.

The way Signal uses AES+HMAC is fine for their use case, but building a secure committing AEAD mode (rather than merely AE) out of these primitives is nontrivial.

If you’re aiming to compete with Signal on security, you should, at minimum, expect to engage with a cryptography auditing firm at least once a year to review and re-review your protocol designs and implementations.

I Will Heavily Scrutinize Your Group Messaging Protocols

Group messaging is one of those topics that might sound easy if you can do peer-to-peer messaging securely, but is catastrophically difficult once you get into the details.

See also: My blog post about Threema.

If you want a starting point, look at RFC 9420 (Messaging Layer Security, which is a group key agreement protocol for messaging apps).

How You Manage Keys Matters

Tox attempted to build atop NaCl’s crypto_box interface, but this is not suitable for a general purpose secure messaging due to a lack of KCI Security.

Key management (which is the focus of an upcoming blog post) is a problem that almost everyone underestimates. It’s also the most user-facing aspect of these messaging applications.

WhatsApp uses Key Transparency to scale user trust. I’m proposing something similar for E2EE for the Fediverse.

This is a much better strategy than expecting users to manually verify “fingerprints”.

Don’t look at OpenPGP as a role model when it comes to user experience. Johnny still cannot fucking encrypt.

Your Feature Should Not Bypass Privacy

Want to add all sorts of frills, like video chat or some dumb bullshit with AI and/or blockchain to secure the attention of venture capitalist investors?

You’d better not implement them in such a way that leaks users’ messages or search queries to your service.

The main reason Signal is “missing” features is because they are thoughtful about how these features are designed and implemented.

Guess what happens if you prioritize shipping features over privacy and cryptography engineering?

That’s right: You stop being a contender for a Signal alternative.

So What?

If your fave isn’t a viable alternative to Signal, don’t fucking recommend it to people in response to me recommending Signal.

That’s all I ask.

Art: Scruff

But what about…?

I’m not here to discuss your use cases, or usability, or anything else. I’m also not saying that Signal is perfect!

Signal is a private messaging app that I would feel safe recommending whistleblowers to use. It meets all these requirements.

In order to be a Signal competitor, no matter how much you like your app, it needs to meet them too, otherwise it isn’t a Signal competitor. Them’s the rules!

AJ

There may be other requirements that are more important to you, that Signal doesn’t meet. That’s fine! You can like other things.

But unless your favorite widget also meets all of the things on this page, it’s not a valid competitor from a security and privacy perspective, and therefore I don’t want to fucking hear about it in response to me saying “use Signal until something better comes along”.

Capiche?

Addendum (2024-08-01)

Since I originally posted this, there have been a lot of opinions expressed and questions asked about messaging apps that have nothing to do with cryptographic security.

Those are good discussions to have, elsewhere. Hell, most of this discussion would be a better response to my other blog post than this one.

The goal of this post was to specify what the minimum bar is for a different app to qualify as a Signal competitor. It’s written from the perspective of someone whose career is in applied cryptography.

If you have thoughts, feelings, opinions, questions, or concerns about messaging apps (including but not limited to Signal), that’s wonderful.

But this specific blog post is not the correct place to voice them!

Especially if the first line of your response is “you’re too focused on [technology, security, cryptography] (select appropriate)”.

Because… no shit? That’s the entire point of this particular post. It’s narrowly scoped for a reason. Please respect that.

My upcoming vulnerability disclosure in Matrix will make the same point, but I wanted a separate, less distracting blog post to link people to when someone tries to evangelize another chat app instead of Signal, especially if they make security claims while doing so.

#cryptography #endToEndEncryption #privateMessengers #Signal

Deploying key transparency at WhatsApp - Engineering at Meta

With key transparency, WhatsApp provides a set of proofs that affirms the correctness of public encryption keys.

^{Kevin Lewi (Meta)}

Federated Key Transparency Project Update

Earlier this year, I wrote about planned effort to design a federated Key Transparency proposal.

The end goal for this work was constrained to building end-to-end encryption into a new type of Direct Message on the Fediverse, with other protocols and services being a stretch goal rather than its primary purpose.

The ideal situation is to enable developers to write code that looks as simple as this:

async function initialize(message, recipient) { const bundle = await fediverse.getSignedPreKeyBundle(recipient); // This also checks the inclusion proof and witness cosigs: const pubKey = await directory.fetch(recipient, bundle.keyId); if (!await pubKey.verify(bundle)) { throw new Error('Invalid signature or bundle'); } const session = await e2ee.beginSession(bundle); return session.send(message);}initialize("OwO what's this?", "soatok@furry.engineer") .then(async (session) => { /* ... */ });

And then have secure end-to-end encryption such that only a trusted public key for the intended recipient can decrypt.

Work on the specification for the Public Key Directory component has recently started. A few things have changed since my last blog post on the topic. I’ve also gotten a lot of similar questions that wouldn’t be appropriate to try to answer within the specification itself.

Original art: CMYKat, poorly edited by myself

The Big Picture

This section is written mostly for anyone who hasn’t paid attention to my other writing on this project.

This is how I believe this project will develop in the immediate future.

1. Public Key Directory (PKD)
   
   • Specification (WIP)
   • Reference Implementation (Not Started)
   • Client-Side SDKs (Not Started)
     
     • Go
     • Ruby
     • PHP
     • TypeScript

     
     

   
   

2. End-to-End Encryption for the Fediverse (FediE2EE)
   
   • Specification (WIP)
     
     • Client-Side Secret Key Management
     • Federated Public Key Infrastructure (See: PKD)
     • Asynchronous Forward-Secure Ratcheting Protocol + Group Key Agreement
     • Symmetric-Key Authenticated Encryption

     
     

   • Reference Implementations (Not Started)
     
     • Go
     • Ruby
     • PHP
     • TypeScript

     
     

   
   

3. Fediverse Instance Patches to Support E2EE
   
   • Mastodon
   • ?????

   
   

4. Client-Side Software
   
   • ?????

   
   

5. PKD Extensions
   
   • age v1 public keys

   
   

Once the PKD complete is complete, there’s nothing stopping other people from defining their own PKD extensions and building on top of our design to add Key Transparency to their own protocols.

My focus, once we have a solid specification and reference implementation, is going to shift towards building FediE2EE.

I will not, however, be working on client-side software unless no one else expresses interest.

The reason for my tentative recusal is simple: I absolutely suck at user interface design, and you’ll probably hate whatever I can cobble together. I am many things, but an artist is not one of them.

You don’t want me designing UIs.
Art: CMYKat

To that end, my final deliverable in this project will be open source libraries (and accompanying guidance for using said libraries) than user experience experts can glue into their own clients.

That said, the only client-side software that should exist are browser extensions, desktop clients, and mobile apps.

I strongly discourage anyone from trying to deploy any code that touches secret keys to a traditional web application, or JavaScript running inside of a WebView.

I’m ambivalent on Electron. It’s better than redownloading the code from a server and running it blindly every page load, but it’s not highly regarded by security professionals.

Decisions Made

The most important topic to cover is design decisions I’ve made with my specification that will shape the evolution of this project.

Account Recovery

The current draft of the specification includes two Protocol Message types, BurnDown and Fireproof, which warrant further examination.

BurnDown is simple in concept: It revokes all of a particular user’s public keys and auxiliary data records. If you have no currently-trusted public keys, you are permitted to push a self-signed AddKey message.

A not-so-subtle detail of BurnDown that everyone should pay attention to is that the instance admin can issue them on behalf of other users hosted on that server.

CMYKat

If you aren’t comfortable with your admin being able to issue a BurnDown at any time, that’s where Fireproof comes in: It allows you to opt out of this capability entirely.

Fireproof is a double-edged sword. It protects you from malicious admins, but it prevents you from ever recovering your account if you lose access to all of your secret keys.

The most important decision I made here is: Fireproof is an opt-in protection, which (as of the current draft) has no “undo”. (I’m considering allowing an “undo” if it makes sense to ever do so. Tell me what you think!)

It’s often said that security at the expense of usability comes at the expense of security. Account recovery mechanisms are, necessarily, always some kind of a backdoor.

Conversely, defaults matter to security. Allowing BurnDown messages be issued by default, from a specification perspective, implies most users will not issue a Fireproof message. (Client software may counteract this by prompting users with a choice when they first enroll, without a default setting, but I digress.)

I believe this choice is the best of all possible options, but you’re certainly welcome to disagree. It’s important to me that I be very loudly transparent about this decision.

No ECDSA Support

I had floated the idea of supporting NIST P-384 in my initial blog post.

Ultimately, there is no real incentive to do so, considering Ed25519 is now in FIPS 186-5 (which has been a standard for 18 months now).

And since we’re already using Ed25519, that satisfies any hypothetical FIPS use-case, should any governments choose to use my design for anything.

Thus, there will be no NIST P-384 support in the Public Key Directory project.

Art: AJ

Right To Be Forgotten

Key Transparency involves creating a global, immutable history. The Right To Be Forgotten enshrined in the EU’s GDPR law is fundamentally incompatible with the security goals of key transparency.

What this means is that, if I just shrugged and plugged Actor IDs and Public Keys into a hash function and committed that hash to a Merkle tree, then, years later, a malicious troll demands their data be removed in accordance with the GDPR, it immediately becomes a catch-22.

Do you comply with the asserted right and break the history and provable security of your transparency ledger? Or do you risk legal peril for noncompliance?

When I first noodled over this, a few people said, “But you’re not in the EU. Why do you care?”

And, like, some of the people that will want to use this design one day are in the EU. Some of them may want to run their own Public Key Directory instances. I want them to have a good time with it. Is that so strange?

There is a way to get both properties without sacrificing the universal consistency of a single Merkle tree, but it relies on untested legal theory.

MarleyTanuki

In short, what you need to do is:

1. Client-side: Encrypt the sensitive fields, then send the ciphertext and the ephemeral key to the Directory.
2. The Directory will commit to the ciphertext, not the plaintext, and hold onto the keys in order to decrypt records on-the-fly.
3. When a data erasure request comes in by an EU citizen asserting their right to be forgotten, erase the key to render the data irrecoverable.

This constitutes a forceful BurnDown with amnesia.

Does This Introduce Any Specific Risks?

This works in principle, but a couple of things need to hold true in order to maintain the integrity of the transparency log.

1. You need to use a committing authenticated encryption mode.
   Without this property, it’s possible to swap one key for another (rather than simply erasing it) and get a valid plaintext for the (ciphertext, tag) committed in the ledger.

   This protects the Directory from a malicious user that later gets privileged access and manipulates stored keys.

2. You need a plaintext commitment that is independent of the key. In addition to key-independence, it needs to be difficult to brute force, and you can’t have additional randomness (i.e., salts) added that could be changed after-the-fact to produce a “valid” commitment for another plaintext.
   This protects users from a Directory that lies about which plaintext a particular ciphertext decrypts to.

This is currently specified as follows:

1. Encryption is AES-256-CTR then HMAC-SHA512, Encrypt-then-MAC.
2. The authentication tag covers a random value used for subkey derivation, as well as a Plaintext Commitment (Q).
3. The Plaintext Commitment (Q) is derived from Argon2id and HMAC of the plaintext. There are some subtle detains with how the Argon2id salt is derived, and why specific parameters were chosen the way they are, but this is covered in the specification document.

I had considered using Zero Knowledge Proofs here, but the current HMAC + Argon2 approach solves the problem securely without needing to study ZKDocs (and its supporting material) for hours.

Does This Give Us Compliance?

If we assume that “crypto shredding” is a valid technique for complying with data erasure demands, this lets us honor those requests while ensuring independent third parties can maintain a consistent view of the state of the transparency log.

It is worth repeating: This is not based on a tested legal theory. It is not legal advice. It is a best effort, good faith attempt to engineer a solution that would adhere to the “spirit of the law” as interpreted by an American furry with no academic or legal credentials from any country.

That being said, page 75 of this report about distributed ledgers and GDPR implies it’s not an entirely unfounded hypothesis.

Frequently Asked Questions

I’ve been asked a lot of similar questions since I started this project. This is a good a place as any to answer some of them.

Have you talked with ____?

Short answer: No, I haven’t.

Longer answer: My goal is simply to build a specification, then an implementation, that allows end-to-end encryption on the Fediverse.

No part of that sentence implies getting anyone else’s permission, or compromising on my security decisions in order to meet a competing concern.

For example, there’s always pressure from the open source community to support RSA keys, or to interoperate with other software (i.e., Matrix).

Those are non-goals of mine.

Should the ActivityPub authors or Mastodon developers decide differently from me, I wouldn’t want to sign off on their protocol design just because it appeases someone else.

I also don’t have any sort of requirement that what I specify and build becomes “standardized” in any meaningful way.

So, no, I haven’t talked with any of them yet. I also don’t plan to until the specifications and reference implementations are closer to maturity.

And even then, the message I have in mind for when that time comes looks something like this:

Hiya,

I’m building my own end-to-end encryption design for the Fediverse. Here’s the specification, here’s a reference implementation. (Links go here.)

[If applicable: I see you accepted a grant to build something similar.]

Please feel free to reuse whatever you deem useful (if anything) of my work in your own designs. I’m not interested in changing mine.

If you’d like to just adopt what I’ve already built, that’s fine too.

Soatok

I don’t want a deep involvement in anyone else’s political or social mess. I don’t want any of their grant money either, for that matter.

I just want to make security and privacy possible, to help queer people decide when, where, and how they selectively reveal themselves to others.

That said, if the W3C grant recipients want to look at the work I’m doing, they can consider it licensed under public domain, ISC, CC0, WTFPL, or whatever license is easiest for their lawyers to digest. I literally do not give a shit about intellectual property with this project. Go wild.

What if no one steps up to build client software?

Then, as a last resort, I will build something myself. Most likely, a browser extension.

It will probably be ugly, but lightweight, as I am deathly allergic to React Native, NextJS, and other front-end development frameworks.

How can I contribute?

The GitHub repository for the Public Key Directory spec is located here, if you’d like to read and/or suggest improvements to the specification.

As mentioned in my previous blog post on this topic, there is a Signal group for meta-discussion. If you are interested in writing code, that would be the best place to hang out.

What about money? Although my Ko-Fi isn’t difficult to locate, nor hard to guess, I’m not soliciting any financial contributions for this project. It isn’t costing me anything to design or build, presently.

If you represent a company that focuses on cryptography development or software assurance consulting, I may be interested in talking at some point about getting the designs reviewed and implementations audited by professionals. However, we’re a long way from that right now.

Do you have a timeline in mind?

Somewhat, yeah.

I’d like to have version 0.1 of the specification tagged by the end of September 2024.

If I have the time to stick to that timeline, I intend to start working on the reference implementation and client SDKs in a few languages. This is when software developers’ contributions will begin to be the most welcomed.

I can’t really project a timeline beyond that, today.

In addition to building a reference implementation, I would like to pursue formal verification for my protocol design. This allows us to be confident in the correctness and security of the protocol as specified. I cannot provide even a rough estimate for how long that will take to complete.

Once this Public Key Directory project is in a good place, however, my focus will be shifting back towards specifying end-to-end encryption for the Fediverse. Because that’s why I’m doing all this in the first place.

AJ

#crypto #cryptography #OnlinePrivacy #symmetricCryptography

Towards Federated Key Transparency

In late 2022, I blogged about the work needed to develop a specification for end-to-end encryption for the fediverse. I sketched out some of the key management components on GitHub, and then the public work abruptly stalled.

A few of you have wondered what’s the deal with that.

This post covers why this effort stalled, what I’m proposing we do next.

What’s The Hold Up?

The “easy” (relatively speaking) parts of the problem are as follows:

1. Secret key management. (This is sketched out already, and provides multiple mechanisms for managing secret key material. Yay!)
2. Bulk encryption of messages and media. (I’ve done a lot of work in this space over the years, so it’s an area I’m deeply familiar with. When we get to this part, it will be almost trivial. I’m not worried about it at all.)
3. Forward-secure ratcheting / authenticated key exchange / group key agreement. (RFC 9420 is a great starting point.)

That is to say, managing secret keys, using secret keys, and deriving shared secret keys are all in the “easy” bucket.

The hard part? Public key management.

CMYKat made this

Why is Public Key Management Hard?

In a centralized service (think: Twitter, Facebook, etc.), this is actually much easier to build: Shove your public keys into a database, and design your client-side software to trust whatever public key your server gives them. Bob’s your uncle, pack it up and go home.

Unfortunately, it’s kind of stupid to build anything that way.

If you explicitly trust the server, the server could provide the wrong public key (i.e., one for which the server knows the corresponding secret key) and you’ll be none the wiser. This makes it trivial for the server to intercept and read your messages.

If your users are trusting you regardless, they’re probably just as happy if you don’t encrypt at the endpoint at all (beyond using TLS, but transport encryption is table stakes for any online service so nevermind that).

But let’s say you wanted to encrypt between peers anyway, because you’re feeling generous (or don’t want to field a bunch of questionably legal demands for user data by law enforcement; a.k.a. the Snapchat threat model).

You could improve endpoint trust by shoving all of your users’ public keys into an append-only data structure; i.e. key transparency, like WhatsApp proposed in 2023:

youtube.com/watch?v=_N4Q05z5vP…

And, to be perfectly clear, key transparency is a damn good idea.

Key transparency keeps everyone honest and makes it difficult for criminals to secretly replace a victim’s public key, because the act of doing so is unavoidably published to an append-only log.

The primary challenge is scaling a transparency feature to serve a public, federated system.

AJ

Federated Key Transparency?

Despite appearances, I haven’t been sitting on my thumbs for the past year or so. I’ve been talking with cryptography experts about their projects and papers in the same space.

Truthfully, I had been hoping to piggyback off one of those upcoming projects (which is focused more on public key discovery for SAML- and OAuth-like protocols) to build the Federated PKI piece for E2EE for the Fediverse.

Unfortunately, that project keeps getting delayed and pushed back, and I’ve just about run out of patience for it.

Additionally, there are some engineering challenges that I would need to tackle to build atop it, so it’s not as simple as “let’s just use that protocol”, either.

So let’s do something else instead:

Art: ScruffKerfluff

Fediverse Public Key Directories

Orthogonal to the overall Fediverse E2EE specification project, let’s build a Public Key Directory for the Fediverse.

This will not only be useful for building a coherent specification for E2EE (as it provides the “Federated PKI” component we’d need to build it securely), but it would also be extremely useful for software developers the whole world over.

Imagine this:

• If you want to fetch a user’s SSH public key, you can just query for their username and get a list of non-expired, non-revoked public keys to choose from.
• If you wanted public key pinning and key rotation for OAuth2 and/or OpenID Connect identity providers without having to update configurations or re-deploy any applications, you can do that.
• If you want to encrypt a message to a complete stranger, such that only they can decrypt it, without any sort of interaction (i.e., they could be offline for a holiday and still decrypt it when they get back), you could do that.

Oh, and best of all? You can get all these wins without propping up any cryptocurrency bullshit either.

From simple abstractions, great power may bloom.

Mark Miller

How Will This Work?

We need to design a specific kind of server that speaks a limited set of the ActivityPub protocol.

I say “limited” because it will only not support editing or deleting messages provided by another instance. It will only append data.

To understand the full picture, let’s first look at the message types, public key types, and how the message types will be interpreted.

Message Types

Under the ActivityPub layer, we will need to specify a distinct set of Directory Message Types. An opening offer would look like this:

1. [strong]AddKey[/strong] — contains an Asymmetric Public Key, a number mapped to the user, and instance that hosts it, and some other metadata (i.e., time)
2. [strong]RevokeKey[/strong] — marks an existing public key as revoked
3. [strong]MoveIdentity[/strong] — moves all of the public keys from identity A to identity B. This can be used for username changes or instance migrations.

We may choose to allow more message types at the front-end if need be, but that’s enough for our purposes.

Public Key Types

We are not interested in backwards compatibility with every existing cryptosystem. We will only tolerate a limited set of public key types.

At the outset, only Ed25519 will be supported.

In the future, we will include post-quantum digital signature algorithms on this list, but not before the current designs have had time to mature.

RSA will never be included in the set.

ECDSA over NIST P-384 may be included at some point, if there’s sufficient interest in supporting e.g., US government users.

If ECDSA is ever allowed, RFC 6979 is mandatory.

Message Processing

When an instance sends a message to a Directory Server, it will need to contain a specific marker for our protocol. Otherwise, it will be rejected.

Each message will have its own processing rules.

After the processing rules are applied, the message will be stored in the Directory Server, and a hash of the message will be published to a SigSum transparency ledger. The Merkle root and inclusion proofs will be stored in an associated record, attached to the record for the new message.

Every message will have its hash published in SigSum. No exceptions.

We will also need a mechanism for witness co-signatures to be published and attached to the record.

Additionally, all messages defined here are generated by the users, client-side. Servers are not trusted, generally, as part of the overall E2EE threat model.

AddKey

{ "@context": "https://example.com/ns/fedi-e2ee/v1", "action": "AddKey", "message": { "time": "2024-12-31T23:59:59Z", "identity": "foo@mastodon.example.com", "public-key": "ed25519:<key goes here>" }, "signature": "SignatureOfMessage"}

The first AddKey for any given identity will need to be self-signed by the key being added (in addition to ActivityPub messages being signed by the instance).

After an identity exists in the directory, every subsequent public key MUST be signed by a non-revoked keypair.

RevokeKey

{ "@context": "https://example.com/ns/fedi-e2ee/v1", "action": "RevokeKey", "message": { "time": "2024-12-31T23:59:59Z", "identity": "foo@mastodon.example.com", "public-key": "ed25519:<key goes here>" }, "signature": "SignatureOfMessage"}

This marks the public key as untrusted, and effectively “deletes” it from the list that users will fetch.

Important: RevokeKey will fail unless there is at least one more trusted public key for this user. Otherwise, a denial of service would be possible.

Replaying an AddKey for a previously-revoked key MUST fail.

MoveIdentity

{ "@context": "https://example.com/ns/fedi-e2ee/v1", "action": "MoveIdentity", "message": { "time": "2024-12-31T23:59:59Z", "old-identity": "foo@mastodon.example.com", "new-identity": "bar@akko.example.net" }, "signature": "SignatureOfMessage"}

This exists to facilitate migrations and username changes.

Other Message Types

The above list is not exhaustive. We may need other message types depending on the exact feature set needed by the final specification.

Fetching Public Keys

A simple JSON API (and/or an ActivityStream; haven’t decided) will be exposed to query for the currently trusted public keys for a given identity.

{ "@context": "https://example.com/ns/fedi-e2ee/v1", "public-keys": [ { "data": { "time": "2024-12-31T23:59:59Z", "identity": "foo@mastodon.example.com", "public-key": "ed25519:<key goes here>" }, "signature": "SignatureOfData", "sigsum": { /* ... */ }, }, { "data": { /* ... */ }, /* ... */ }, /* ... */ ]}

Simple and easy.

CMYKat

Gossip Between Instances

Directory Servers should be configurable to mirror records from other instances.

Additionally, they should be configurable to serve as Witnesses for the SigSum protocol.

The communication layer here between Directory Servers will also be ActivityPub.

Preventing Abuse

The capability of learning a user’s public key doesn’t imply the ability to send messages or bypass their block list.

Additionally, Fediverse account usernames are (to my knowledge) generally not private, so I don’t anticipate there being any danger in publishing public keys to an append-only ledger.

That said, I am totally open to considering use cases where the actual identity is obfuscated (e.g., HMAC with a static key known only to the instance that hosts them instead of raw usernames).

What About GDPR / Right To Be Forgotten?

Others have previously suggested that usernames might be subject to the “right to be forgotten”, which would require breaking history for an append-only ledger.

After discussing a proposed workaround with a few people in the Signal group for this project, we realized complying necessarily introduced security issues by giving instance admins the capability of selectively remapping the user ID to different audiences, and detecting/mitigating this remapping is annoying.

However, we don’t need to do that in the first place.

According to this webpage about GDPR’s Right to be Forgotten:

However, an organization’s right to process someone’s data might override their right to be forgotten. Here are the reasons cited in the GDPR that trump the right to erasure:

• (…)
• The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority.
• (…)
• The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.

Enabling private communication is in the public interest. The only information that will be stored in the ledger in relation to the username are cryptographic public keys, so it’s not like anything personal (e.g., email addresses or legal names) will be included.

However, we still need to be extremely up-front about this to ensure EU citizens are aware of the trade-off we’re making.

Account Recovery

In the event that a user loses access to all of their secret keys and wants to burn down the old account, they may want a way to start over with another fresh self-signed AddKey.

However, the existing policies I wrote above would make this challenging:

1. Since every subsequent AddKey must be signed by an incumbent key, if you don’t have access to these secret keys, you’re locked out.
2. Since RevokeKey requires one trusted keypair remains in the set, for normal operations, you can’t just burn the set down to zero even while you still had access to the secret keys.

There is an easy way out of this mess: Create a new verb; e.g. BurnDown that an instance can issue that resets all signing keys for a given identity.

The use of BurnDown should be a rare, exceptional event that makes a lot of noise:

• All existing E2EE sessions must break, loudly.
• All other participants must be alerted to the change, through the client software.
• Witnesses and watchdog nodes must take note of this change.

This comes with some trade-offs. Namely: Any account recovery mechanism is a backdoor, and giving the instance operators the capability of issuing BurnDown messages is a risk to their users.

Therefore, users who trust their own security posture and wish to opt out of this recovery feature should also be able to issue a Fireproof message at any point in the process, which permanent and irrevocably prevents any BurnDown from being accepted on their current instance.

If users opt out of recovery and then lose their signing keys, they’re locked out and need to start over with a new Fediverse identity. On the flipside, their instance operator cannot successfully issue a BurnDown for them, so they have to trust them less.

Notice

This is just a rough sketch of my initial ideas, going into this project. It is not comprehensive, nor complete.

There are probably big gaps that need to be filled in, esp. on the ActivityPub side of things. (I’m not as worried about the cryptography side of things.)

How Will This Be Used for E2EE Direct Messaging?

I anticipate that a small pool of Directory Servers will be necessary, due to only public keys and identities being stored.

Additional changes beyond just the existence of Directory Servers will need to be made to facilitate private messaging. Some of those changes include:

• Some endpoint for users to know which Directory Servers a given ActivityPub instance federates with (if any).
• Some mechanism for users to asynchronously exchange Signed Pre-Key bundles for initiating contact. (One for users to publish new bundles, another for users to retrieve a bundle.)
  
  • These will be Ed25519-signed payloads containing an ephemeral X25519 public key.

  
  

This is all outside the scope of the proposal I’m sketching out here today, but it’s worth knowing that I’m aware of the implementation complexity.

The important thing is: I (soatok@furry.engineer) should be able to query pawb.fun, find the Directory Server(s) they federate with, and then query that Directory server for Crashdoom@pawb.fun and get his currently trusted Ed25519 public keys.

From there, I can query pawb.fun for a SignedPreKey bundle, which will have been signed by one of those public keys.

And then we can return to the “easy” pile.

MarleyTanuki

Development Plan

Okay, so that was a lot of detail, and yet not enough detail, depending on who’s reading this blog post.

What I wrote here today is a very rough sketch. The devil is always in the details, especially with cryptography.

Goals and Non-Goals

We want Fediverse users to be able to publish a public key that is bound to their identity, which anyone else on the Internet can fetch and then use for various purposes.

We want to leverage the existing work into key transparency by the cryptography community.

We don’t want to focus on algorithm agility or protocol compatibility.

We don’t want to involve any government offices in the process. We don’t care about “real” identities, nor about codifying falsehoods about names.

We don’t want any X.509 or Web-of-Trust machinery involved in the process.

Tasks

The first thing we would need to do is write a formal specification for a Directory Server (whose job is only to vend Public Keys in an auditable, transparent manner).

Next, we need to actually build a reference implementation of this server, test it thoroughly, and then have security experts pound at the implementation for a while. Any security issues that can be mitigated by design will require a specification update.

We will NOT punt these down to implementors to be responsible for, unless we cannot avoid doing so.

Once these steps are done, we can start rolling the Directory Servers out. At this point, we can develop client-side libraries in various programming languages to make it easy for developers to adopt.

My continued work on the E2EE specification for the Fediverse can begin after we have an implementation of the Directory Server component ready to go.

Timeline

I have a very demanding couple of months ahead of me, professionally, so I don’t yet know when I can commit to starting the Fediverse Directory Server specification work.

Strictly speaking, it’s vaguely possible to get buy-in from work to focus on this project as part of my day-to-day responsibilities, since it has immediate and lasting value to the Internet.

However, I don’t want to propose it because that would be crossing the professional-personal streams in a way I’m not really comfortable with.

The last thing I need is angry Internet trolls harassing my coworkers to try to get under my fur, y’know?

If there is enough interest from the broader Fediverse community, I’m also happy to delegate this work to anyone interested.

Once the work can begin, I don’t anticipate it will take more than a week for me to write a specification that other crypto nerds will take seriously.

I am confident in this because most of the cryptography will be constrained to hash functions, preventing canonicalization and cross-protocol attacks, and signatures.

Y’know, the sort of thing I write about on my furry blog for fun!

Building a reference implementation will likely take a bit longer; if, for no other reason, than I believe it would be best to write it in Go (which has the strongest SigSum support, as of this writing).

This is a lot of words to say, as far as timelines go:

CMYKat

How to Get Involved

Regardless of whether my overall E2EE proposal gets adopted, the Directory Server component is something that should be universally useful to the Fediverse and to software developers around the world.

If you are interested in participating in any technical capacity, I have just created a Signal Group for discussing and coordinating efforts.

All of these efforts will also be coordinated on the fedi-e2ee GitHub organization.

The public key directory server’s specification will eventually exist in this GitHub repository.

Can I Contribute Non-Technically?

Yes, absolutely. In the immediate future, once it kicks off, the work is going to be technology-oriented.

However, we may need people with non-technical skills at some point, so feel free to dive in whenever you feel comfortable.

What About Financially?

If you really have money burning a hole in your pocket and want to toss a coin my way, I do have a Ko-Fi. Do not feel pressured at all to do so, however.

Because I only use Ko-Fi as a tip jar, rather than as a business, I’m not specifically tracking which transaction is tied to which project, so I can’t make any specific promises about how any of the money sent my way will be allocated.

What I will promise, however, is that any icons/logos/etc. created for this work will be done by an artist and they will be adequately compensated for their work. I will not use large-scale computing (a.k.a., “Generative AI”) for anything.

Closing Thoughts

What I’ve sketched here is much simpler (and more ActivityPub-centric) than the collaboration I was originally planning.

Thanks for being patient while I tried, in vain, to make that work.

As of today, I no longer think we need to wait for them. We can build this ourselves, for each other.

#cryptography #endToEndEncryption #fediverse #KeyTransparency #Mastodon #MerkleTrees #PublicKeys

What Does It Mean To Be A Signal Competitor?

A lot of recent (and upcoming) blog posts I’ve written, and Fediverse discussions I’ve participated in, have been about the security of communication products.

My criticism of these products is simply that, from a cryptography and security perspective, they’re not a real competitor to Signal.

For all its other faults, Signal sets the bar for secure private messaging. It’s a solid security tool, even if its user experience and feature set leaves a lot of people disappointed. I highly recommend it over, say, Telegram.

In response to my post about jettisoning Telegram, quite a few people have tried to evangelize other products. For example:

Edit: Oh yeah, DON’T USE SIGNAL. Use Matrix instead, offers the benefits of signal without the drawbacks of lack of sync and phone number requirements and is decentralized. The fact that everyone is going gaga for signal as “the BEST messaging app” should be a big red flag in and of itself, because hype trains like this aren’t organic, just saying.

Draconic_NEO on pawb.social

So, let me explain what it means for a communication product to qualify as a Signal competitor from the perspective of someone whose job involves auditing cryptography implementations.

The Minimum Bar to Clear

Open Source

Every private messaging app must be open source in order to qualify as a Signal competitor.

If it’s not open source, it’s not even worth talking about.

End-to-End Encryption

Messages MUST be end-to-end encrypted. This means that you encrypt on one participant’s device, decrypt on another’s, and nobody in the middle can observe plaintext.

When I say MUST, I mean the RFC 2119 keyword.

There must never be a “transmit plaintext” option. No excuses. Secure cryptography is not interoperable with insecure cryptography. If you allow a “transmit plaintext” mode for any reason whatsoever, you have failed to build an encryption product that meets the bar.

This disqualifies Matrix.

This disqualifies Telegram.

This disqualifies XMPP + OMEMO.

This alone disqualifies a lot of so-called private messaging apps.

This doesn’t mean your product is insecure, or that I’m aware of any specific ways to break it.

It just doesn’t occupy the same mindshare as Signal, which only transmits encrypted data and doesn’t have a plaintext protocol to downgrade to.

Therefore, it’s not a goddamn Signal alternative.

How You Encrypt Matters

Signal normalized the use of AES-256-CBC with HMAC-SHA256.

Facebook’s “Secret Conversations” feature deviated from this and preferred AES-GCM for attachments, but this bit them when the Invisible Salamanders attack was discovered.

The way Signal uses AES+HMAC is fine for their use case, but building a secure committing AEAD mode (rather than merely AE) out of these primitives is nontrivial.

If you’re aiming to compete with Signal on security, you should, at minimum, expect to engage with a cryptography auditing firm at least once a year to review and re-review your protocol designs and implementations.

I Will Heavily Scrutinize Your Group Messaging Protocols

Group messaging is one of those topics that might sound easy if you can do peer-to-peer messaging securely, but is catastrophically difficult once you get into the details.

See also: My blog post about Threema.

If you want a starting point, look at RFC 9420 (Messaging Layer Security, which is a group key agreement protocol for messaging apps).

How You Manage Keys Matters

Tox attempted to build atop NaCl’s crypto_box interface, but this is not suitable for a general purpose secure messaging due to a lack of KCI Security.

Key management (which is the focus of an upcoming blog post) is a problem that almost everyone underestimates. It’s also the most user-facing aspect of these messaging applications.

WhatsApp uses Key Transparency to scale user trust. I’m proposing something similar for E2EE for the Fediverse.

This is a much better strategy than expecting users to manually verify “fingerprints”.

Don’t look at OpenPGP as a role model when it comes to user experience. Johnny still cannot fucking encrypt.

Your Feature Should Not Bypass Privacy

Want to add all sorts of frills, like video chat or some dumb bullshit with AI and/or blockchain to secure the attention of venture capitalist investors?

You’d better not implement them in such a way that leaks users’ messages or search queries to your service.

The main reason Signal is “missing” features is because they are thoughtful about how these features are designed and implemented.

Guess what happens if you prioritize shipping features over privacy and cryptography engineering?

That’s right: You stop being a contender for a Signal alternative.

So What?

If your fave isn’t a viable alternative to Signal, don’t fucking recommend it to people in response to me recommending Signal.

That’s all I ask.

Art: Scruff

But what about…?

I’m not here to discuss your use cases, or usability, or anything else. I’m also not saying that Signal is perfect!

Signal is a private messaging app that I would feel safe recommending whistleblowers to use. It meets all these requirements.

In order to be a Signal competitor, no matter how much you like your app, it needs to meet them too, otherwise it isn’t a Signal competitor. Them’s the rules!

AJ

There may be other requirements that are more important to you, that Signal doesn’t meet. That’s fine! You can like other things.

But unless your favorite widget also meets all of the things on this page, it’s not a valid competitor from a security and privacy perspective, and therefore I don’t want to fucking hear about it in response to me saying “use Signal until something better comes along”.

Capiche?

Addendum (2024-08-01)

Since I originally posted this, there have been a lot of opinions expressed and questions asked about messaging apps that have nothing to do with cryptographic security.

Those are good discussions to have, elsewhere. Hell, most of this discussion would be a better response to my other blog post than this one.

The goal of this post was to specify what the minimum bar is for a different app to qualify as a Signal competitor. It’s written from the perspective of someone whose career is in applied cryptography.

If you have thoughts, feelings, opinions, questions, or concerns about messaging apps (including but not limited to Signal), that’s wonderful.

But this specific blog post is not the correct place to voice them!

Especially if the first line of your response is “you’re too focused on [technology, security, cryptography] (select appropriate)”.

Because… no shit? That’s the entire point of this particular post. It’s narrowly scoped for a reason. Please respect that.

My upcoming vulnerability disclosure in Matrix will make the same point, but I wanted a separate, less distracting blog post to link people to when someone tries to evangelize another chat app instead of Signal, especially if they make security claims while doing so.

#cryptography #endToEndEncryption #privateMessengers #Signal

E2EE for the Fediverse Update – We’re Going Post-Quantum

In 2022, I wrote about my plan to build end-to-end encryption for the Fediverse. The goals were simple:

1. Provide secure encryption of message content and media attachments between Fediverse users, as a new type of Direct Message which is encrypted between participants.
2. Do not pretend to be a Signal competitor.

The primary concern at the time was “honest but curious” Fediverse instance admins who might snoop on another user’s private conversations.

After I finally was happy with the client-side secret key management piece, I had moved on to figure out how to exchange public keys. And that’s where things got complicated, and work stalled for 2 years.

Art: AJ

I wrote a series of blog posts on this complication, what I’m doing about it, and some other cool stuff in the draft specification.

• Towards Federated Key Transparency introduced the Public Key Directory project
• Federated Key Transparency Project Update talked about some of the trade-offs I made in this design
  
  • Not supporting ECDSA at all, since FIPS 186-5 supports Ed25519
  • Adding an account recovery feature, which power users can opt out of, that allows instance admins to help a user recover from losing all their keys
  • Building a Key Transparency system that can tolerate GDPR Right To Be Forgotten takedown requests without invalidating history

  
  

• Introducing Alacrity to Federated Cryptography discussed how I plan to ensure that independent third-party clients stay up-to-date or lose the ability to decrypt messages

Recently, NIST published the new Federal Information Protection Standards documents for three post-quantum cryptography algorithms:

• FIPS-203 (ML-KEM, formerly known as CRYSTALS-Kyber),
• FIPS-204 (ML-DSA, formerly known as CRYSTALS-Dilithium)
• FIPS-205 (SLH-DSA, formerly known as SPHINCS+)

The race is now on to implement and begin migrating the Internet to use post-quantum KEMs. (Post-quantum signatures are less urgent.) If you’re curious why, this CloudFlare blog post explains the situation quite well.

Since I’m proposing a new protocol and implementation at the dawn of the era of post-quantum cryptography, I’ve decided to migrate the asymmetric primitives used in my proposals towards post-quantum algorithms where it makes sense to do so.

Art: AJ

The rest of this blog post is going to talk about technical specifics and the decisions I intend to make in both projects, as well as some other topics I’ve been thinking about related to this work.

Which Algorithms, Where?

I’ll discuss these choices in detail, but for the impatient:

• Public Key Directory
  
  • Still just Ed25519 for now

  
  

• End-to-End Encryption
  
  • KEMs: X-Wing (Hybrid X25519 and ML-KEM-768)
  • Signatures: Still just Ed25519 for now

  
  

Virtually all other uses of cryptography is symmetric-key or keyless (i.e., hash functions), so this isn’t a significant change to the design I have in mind.

Post-Quantum Algorithm Selection Criteria

While I am personally skeptical if we will see a practical cryptography-relevant quantum computer in the next 30 years, due to various engineering challenges and a glacial pace of progress on solving them, post-quantum cryptography is still a damn good idea even if a quantum computer doesn’t emerge.

Post-Quantum Cryptography comes in two flavors:

1. Key Encapsulation Mechanisms (KEMs), which I wrote about previously.
2. Digital Signature Algorithms (DSAs).

Originally, my proposals were going to use Elliptic Curve Diffie-Hellman (ECDH) in order to establish a symmetric key over an untrusted channel. Unfortunately, ECDH falls apart in the wake of a crypto-relevant quantum computer. ECDH is the component that will be replaced by post-quantum KEMs.

Additionally, my proposals make heavy use of Edwards Curve Digital Signatures (EdDSA) over the edwards25519 elliptic curve group (thus, Ed25519). This could be replaced with a post-quantum DSA (e.g., ML-DSA) and function just the same, albeit with bandwidth and/or performance trade-offs.

But isn’t post-quantum cryptography somewhat new?

Lattice-based cryptography has been around almost as long as elliptic curve cryptography. One of the first designs, NTRU, was developed in 1996.

Meanwhile, ECDSA was published in 1992 by Dr. Scott Vanstone (although it was not made a standard until 1999). Lattice cryptography is pretty well-understood by experts.

However, before the post-quantum cryptography project, there hasn’t been a lot of incentive for attackers to study lattices (unless they wanted to muck with homomorphic encryption).

So, naturally, there is some risk of a cryptanalysis renaissance after the first post-quantum cryptography algorithms are widely deployed to the Internet.

However, this risk is mostly a concern for KEMs, due to the output of a KEM being the key used to encrypt sensitive data. Thus, when selecting KEMs for post-quantum security, I will choose a Hybrid construction.

Hybrid what?

We’re not talking folfs, sonny!

Hybrid isn’t just a thing that furries do with their fursonas. It’s also a term that comes up a lot in cryptography.

Unfortunately, it comes up a little too much.
I made this dumb meme with imgflip
When I say we use Hybrid constructions, what I really mean is we use a post-quantum KEM and a classical KEM (such as HPKE‘s DHKEM), then combine them securely using a KDF.

Post-quantum KEMs

For the post-quantum KEM, we only really have one choice: ML-KEM. But this choice is actually three choices: ML-KEM-512, ML-KEM-768, or ML-KEM-1024.

The security margin on ML-KEM-512 is a little tight, so most cryptographers I’ve talked with recommend ML-KEM-768 instead.

Meanwhile, the NSA wants the US government to use ML-KEM-1024 for everything.

How will you hybridize your post-quantum KEM?

Originally, I was looking to use DHKEM with X25519, as part of the HPKE specification. After switching to post-quantum cryptography, I would need to combine it with ML-KEM-768 in such a way that the whole shebang is secure if either component is secure.

But then, why reinvent the wheel here? X-Wing already does that, and has some nice binding properties that a naive combination might not.

So let’s use X-Wing for our KEM.

Notably, OpenMLS is already doing this in their next release.

Art: CMYKat

Post-quantum signatures

So our KEM choice seems pretty straightforward. What about post-quantum signatures?

Do we even need post-quantum signatures?

Well, the situation here is not nearly as straightforward as KEMs.

For starters, NIST chose to standardize two post-quantum digital signature algorithms (with a third coming later this year). They are as follows:

• ML-DSA (formerly CRYSTALS-Dilithium), that comes in three flavors:
  
  • ML-DSA-44
  • ML-DSA-65
  • ML-DSA-87

  
  

• SLH-DSA (formerly SPHINCS+), that comes in 24 flavors
• FN-DSA (formerly FALCON), that comes in two flavors but may be excruciating to implement in constant-time (this one isn’t standardized yet)

Since we’re working at the application layer, we’re less worried about a few kilobytes of bandwidth than the networking or X.509 folks are. Relatively speaking, we care about security first, performance second, and message size last.

After all, people ship Electron, React Native, and NextJS apps that load megabytes of JavaScript code to print, “hello world,” and no one bats an eye. A few kilobytes in this context is easily digestible for us.

(As I said, this isn’t true for all layers of the stack. WebPKI in particular feels a lot of pain with large public keys and/or signatures.)

Eliminating post-quantum signature candidates

Performance considerations would eliminate SLH-DSA, which is the most conservative choice. Even with the fastest parameter set (SLH-DSA-128f), this family of algorithms is about 550x slower than Ed25519. (If we prioritize bandwidth, it becomes 8000x slower.)

Adopted from CloudFlare’s blog post on post-quantum cryptography.

Between the other two, FN-DSA is a tempting option. Although it’s difficult to implement in constant-time, it offers smaller public key and signature sizes.

However, FN-DSA is not standardized yet, and it’s only known to be safe on specific hardware architectures. (It might be safe on others, but that’s not proven yet.)

In order to allow Fediverse users be secure on a wider range of hardware, this uncertainty would limit our choice of post-quantum signature algorithms to some flavor of ML-DSA–whether stand-alone or in a hybrid construction.

Unlike KEMs, hybrid signature constructions may be problematic in subtle ways that I don’t want to deal with. So if we were to do anything, we would probably choose a pure post-quantum signature algorithm.

Against the Early Adoption of Post-Quantum Signatures

There isn’t an immediate benefit to adopting a post-quantum signature algorithm, as David Adrian explains.

The migration to post-quantum cryptography will be a long and difficult road, which is all the more reason to make sure we learn from past efforts, and take advantage of the fact the risk is not imminent. Specifically, we should avoid:

• Standardizing without real-world experimentation
• Standardizing solutions that match how things work currently, but have significant negative externalities (increased bandwidth usage and latency), instead of designing new things to mitigate the externalities
• Deploying algorithms pre-standardization in ways that can’t be easily rolled back
• Adding algorithms that are pre-standardization or have severe shortcomings to compliance frameworks

We are not in the middle of a post-quantum emergency, and nothing points to a surprise “Q-Day” within the next decade. We have time to do this right, and we have time for an iterative feedback loop between implementors, cryptographers, standards bodies, and policymakers.

The situation may change. It may become clear that quantum computers are coming in the next few years. If that happens, the risk calculus changes and we can try to shove post-quantum cryptography into our existing protocols as quickly as possible. Thankfully, that’s not where we are.

David Adrian, Lack of post-quantum security is not plaintext.

Furthermore, there isn’t currently any commitment from the Sigsum developers to adopt a post-quantum signature scheme in the immediate future. They hard-code Ed25519 for the current iteration of the specification.

The verdict on digital signature algorithms?

Given all of the above, I’m going to opt to simply not adopt post-quantum signatures until a later date.

Version 1 of our design will continue to use Ed25519 despite it not being secure after quantum computers emerge (“Q-Day”).

When the security industry begins to see warning signs of Q-Day being realistically within a decade, we will prioritize migrating to use post-quantum signature algorithms in a new version of our design.

Should something drastic happen that would force us to decide on a post-quantum algorithm today, we would choose ML-DSA-44. However, that’s unlikely for at least several years.

Remember, Store Now, Decrypt Later doesn’t really break signatures the way it would break public-key encryption.

Art: Harubaki

Miscellaneous Technical Matters

Okay, that’s enough about post-quantum for now. I worry that if I keep talking about key encapsulation, some of my regular readers will start a shitty garage band called My KEMical Romance before the end of the year.

CMYKat

Let’s talk about some other technical topics related to end-to-end encryption for the Fediverse!

Federated MLS

MLS was implicitly designed with the idea of having one central service for passing messages around. This makes sense if you’re building a product like Signal, WhatsApp, or Facebook Messenger.

It’s not so great for federated environments where your Delivery Service may be, in fact, more than one service (i.e., the Fediverse). An expired Internet Draft for Federated MLS talks about these challenges.

If we wanted to build atop MLS for group key agreement (like has been suggested before), we’d need to tackle this in a way that doesn’t cede control of MLS epochs to any server that gets compromised.

CMYKat

How to Make MLS Tolerate Federation

First, the Authentication Service component can be replaced by client-side protocols, where public keys are sourced from the Public Key Directory (PKD) services.

That is to say, from the PKD, you can fetch a valid list of Ed25519 public keys for each participant in the group.

When a group is created, the creator’s Ed25519 public key is known. Everyone they invite, their software necessarily has to know their Ed25519 public key in order to invite them.

In order for a group action to be performed, it must be signed by one of the public keys enrolled into the group list. Additionally, some actions may be limited by permissions attached at the time of the invite (or elevated by a more privileged user; which necessitates another group action).

By requiring a valid signature from an existing group member, we remove the capability of the Fediverse instance that’s hosting the discussion group to meddle with it in any way (unless, for some reason, the server is somehow also a participant that was invited).

But therein lies the other change we need to make: In many cases, groups will span multiple Fediverse servers, so groups shouldn’t be dependent on a single instance.

Spreading The Load Across Instances

Put simply, we need a consensus algorithm to determine which instance hosts messages. We could look to Raft as a starting point, but whatever we land on should be fair, fault-tolerant, and deterministic to all participants who can agree on the same symmetric keying material at some point in time.

To that end, I propose using an additional HKDF output from the Group Key Agreement protocol to select a “leader” for all instances involved in the group, weighted by the number of participants on each instance.

Then, every N messages (where N >= 1), a new leader is elected by the same deterministic protocol. This will be performed entirely client-side, and clients will choose N. I will refer to this as a sub-epoch, since it doesn’t coincide with a new MLS epoch.

Since the agreed-upon group key always ratchets forward when a group action occurs (i.e., whenever there’s a new epoch), getting another KDF output to elect the next leader is straightforward.

This isn’t a fully fleshed out idea. Building consensus protocols that can handle real-world operational issues is heavily specialized work and there’s a high risk of falling to the illusion of safety until it’s too late. I will probably need help with this component.

That said, we aren’t building an anonymity network, so the cost of getting a detail wrong isn’t measurable in blood.

We aren’t really concerned with Sybil attacks. Winning the election just means you’re responsible for being a dumb pipe for ciphertext. Client software should trust the instance software as little as possible.

We also probably don’t need to worry about availability too much. Since we’re building atop ActivityPub, when a server goes down, the other instances can hold encrypted messages in the outbox for the host instance to pick up when it’s back online.

If that’s not satisfactory, we could also select both a primary and secondary leader for each epoch (and sub-epoch), to have built-in fail-over when more than one instance is involved in a group conversation.

If messages aren’t being delivered for an unacceptable period of time, client software can forcefully initiate a new leader election by expiring the current MLS epoch (i.e. by rotating their own public key and sending the relevant bundle to all other participants).

Art: Kyume

Those are just some thoughts. I plan to talk it over with people who have more expertise in the relevant systems.

And, as with the rest of this project, I will write a formal specification for this feature before I write a single line of production code.

Abuse Reporting

I could’ve swore I talked about this already, but I can’t find it in any of my previous ramblings, so here’s a good place as any.

The intent for end-to-end encryption is privacy, not secrecy.

What does this mean exactly? From the opening of Eric Hughes’ A Cypherpunk’s Manifesto:

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy.

A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know.

Privacy is the power to selectively reveal oneself to the world.

Eric Hughes (with whitespace and emphasis added)

Unrelated: This is one reason why I use “secret key” when discussing asymmetric cryptography, rather than “private key”. It also lends towards sk and pk as abbreviations, whereas “private” and “public” both start with the letter P, which is annoying.

With this distinction in mind, abuse reporting is not inherently incompatible with end-to-end encryption or any other privacy technology.

In fact, it’s impossible to create useful social technology without the ability for people to mitigate abuse.

So, content warning: This is going to necessarily discuss some gross topics, albeit not in any significant detail. If you’d rather not read about them at all, feel free to skip this section.

Art: CMYKat

When thinking about the sorts of problems that call for an abuse reporting mechanism, you really need to consider the most extreme cases, such as someone joining group chats to spam unsuspecting users with unsolicited child sexual abuse material (CSAM), flashing imagery designed to trigger seizures, or graphic depictions of violence.

That’s gross and unfortunate, but the reality of the Internet.

However, end-to-end encryption also needs to prioritize privacy over appeasing lazy cops who would rather everyone’s devices include a mandatory little cop that watches all your conversations and snitches on you if you do anything that might be illegal, or against the interest of your government and/or corporate masters. You know the type of cop. They find privacy and encryption to be rather inconvenient. After all, why bother doing their jobs (i.e., actual detective work) when you can just criminalize end-to-end encryption and use dragnet surveillance instead?

Whatever we do, we will need to strike a balance that protects users’ privacy, without any backdoors or privileged access for lazy cops, with community safety.

Thus, the following mechanisms must be in place:

1. Groups must have the concept of an “admin” role, who can delete messages on behalf of all users and remove users from the group. (Signal currently doesn’t have this.)
2. Users must be able to delete messages on their own device and block users that send abusive content. (The Fediverse already has this sort of mechanism, so we don’t need to be inventive here.)
3. Users should have the ability to report individual messages to the instance moderators.

I’m going to focus on item 3, because that’s where the technically and legally thorny issues arise.

Keep in mind, this is just a core-dump of thoughts about this topic, and I’m not committing to anything right now.

Technical Issues With Abuse Reporting

First, the end-to-end encryption must be immune to Invisible Salamanders attacks. If it’s not, go back to the drawing board.

Every instance will need to have a moderator account, who can receive abuse reports from users. This can be a shared account for moderators or a list of moderators maintained by the server.

When an abuse report is sent to the moderation team, what needs to happen is that the encryption keys for those specific messages are re-wrapped and sent to the moderators.

So long as you’re using a forward-secure ratcheting protocol, this doesn’t imply access to the encryption keys for other messages, so the information disclosed is limited to the messages that a participant in the group consents to disclosing. This preserves privacy for the rest of the group chat.

When receiving a message, moderators should not only be able to see the reported message’s contents (in the order that they were sent), but also how many messages were omitted in the transcript, to prevent a type of attack I colloquially refer to as “trolling through omission”. This old meme illustrates the concept nicely:
Trolling through omission.
And this all seems pretty straightforward, right? Let users protect themselves and report abuse in such a way that doesn’t invalidate the privacy of unrelated messages or give unfettered access to the group chats. “Did Captain Obvious write this section?”

But things aren’t so clean when you consider the legal ramifications.

Harubaki

Potential Legal Issues With Abuse Reporting

Suppose Alice, Bob, and Troy start an encrypted group conversation. Alice is the group admin and delete messages or boot people from the chat.

One day, Troy decides to send illegal imagery (e.g., CSAM) to the group chat.

Bob immediately, disgusted, reports it to his instance moderator (Dave) as well as Troy’s instance moderator (Evelyn). Alice then deletes the messages for her and Bob and kicks Troy from the chat.

Here’s where the legal questions come in.

If Dave and Evelyn are able to confirm that Troy did send CSAM to Alice and Bob, did Bob’s act of reporting the material to them count as an act of distribution (i.e., to Dave and/or Evelyn, who would not be able to decrypt the media otherwise)?

If they aren’t able to confirm the reports, does Alice’s erasure count as destruction of evidence (i.e., because they cannot be forwarded to law enforcement)?

Are Bob and Alice legally culpable for possession? What about Dave and Evelyn, whose servers are hosting the (albeit encrypted) material?

It’s not abundantly clear how the law will intersect with technology here, nor what specific technical mechanisms would need to be in place to protect Alice, Bob, Dave, and Evelyn from a particularly malicious user like Troy.

Obviously, I am not a lawyer. I have an understanding with my lawyer friends that I will not try to interpret law or write my own contracts if they don’t roll their own crypto.

That said, I do have some vague ideas for mitigating the risk.

Ideas For Risk Mitigation

To contend with this issue, one thing we could do is separate the abuse reporting feature from the “fetch and decrypt the attached media” feature, so that while instance moderators will be capable of fetching the reported abuse material, it doesn’t happen automatically.

When the “reason” attached to an abuse report signals CSAM in any capacity, the client software used by moderators could also wholesale block the download of said media.

Whether that would be sufficient mitigate the legal matters raised previously, I can’t say.

And there’s still a lot of other legal uncertainty to figure out here.

• Do instance moderators actually have a duty to forward CSAM reports to law enforcement?
  
  • If so, how should abuse forwarding to be implemented?
  • How do we train law enforcement personnel to receive and investigate these reports WITHOUT frivolously arresting the wrong people or seizing innocent Fediverse servers?
  • How do we ensure instance admins are broadly trained to handle this?
  • How do we deal with international law?

  
  

• How do we prevent scope creep?
  
  • While there is public interest in minimizing the spread of CSAM, which is basically legally radioactive, I’m not interested in ever building a “snitch on women seeking reproductive health care in a state where abortion is illegal” capability.

  
  

• Does Section 230 matter for any of these questions?

We may not know the answers to these questions until the courts make specific decisions that establish relevant case law, or our governments pass legislation that clarifies everyone’s rights and responsibilities for such cases.

Until then, the best answer may simply to do nothing.

That is to say, let admins delete messages for the whole group, let users delete messages they don’t want on their own hardware, and let admins receive abuse reports from their users… but don’t do anything further.

Okay, we should definitely require an explicit separate action to download and decrypt the media attached to a reported message, rather than have it be automatic, but that’s it.

Harubaki

What’s Next?

For the immediate future, I plan on continuing to develop the Federated Public Key Directory component until I’m happy with its design. Then, I will begin developing the reference implementations for both client and server software.

Once that’s in a good state, I will move onto finishing the E2EE specification. Then, I will begin building the client software and relevant server patches for Mastodon, and spinning up a testing instance for folks to play with.

Timeline-wise, I would expect most of this to happen in 2025.

I wish I could promise something sooner, but I’m not fond of moving fast and breaking things, and I do have a full time job unrelated to this project.

Hopefully, by the next time I pen an update for this project, we’ll be closer to launching. (And maybe I’ll have answers to some of the legal concerns surrounding abuse reporting, if we’re lucky.)

CMYKat

#E2EE #endToEndEncryption #fediverse #FIPS #Mastodon #postQuantumCryptography

Some Thoughts on the Twitter Mass Exodus

Another wave of Twitter users are jettisoning the social media website in favor of alternatives. Some are landing in the Fediverse (Mastodon and other ActivityPub-enabled software). Others are going to BlueSky.

Some are just outright abandoning social media entirely, disillusioned by the entire concept.

As someone working on design specifications to propose end-to-end encryption for the Fediverse, you might assume I’d make a specific recommendation here.

And you would be right: "]BlueSky is the winner.

Alright everyone, pack it up and go home.

CMYKat

…

…

You’re still here?

Okay, yes, there’s a little bit of nuance to that remark.

Pick Your Poison

What does social media mean to you?

If you’re just looking for a way to connect with your existing friends, and maybe meet some of their friends, and share neat things with each other, you’ll probably find the Fediverse a comfortable space to just exist.

But if you’re interested in clout, popularity, reach… maybe because you’re an extrovert, or maybe because [url=https://soatok.blog/2020/10/16/commission-prices-for-furries-and-artists/]your small business model literally depends on such factors… you’re probably going to find BlueSky easier than the Fediverse, due to BlueSky being extremely familiar to Twitter users (both technologically and culturally).

If you crave a central platform–a community watering hole where all the popular kids hang out–you want BlueSky.

If you want Twitter, just without the Nazis that took over the space when Elon Musk bought it, you want BlueSky.

Conversely, if you want to try something different, where there is no centralization (even if it is “temporary” in BlueSky’s case), corporate control, or advertiser-friendly moderation practices, consider joining the Fediverse.

Why Does Winning Matter?

If BlueSky “wins”, a deluge of new users will follow.

This means that BlueSky will become the new social commons of the Internet–a space previously occupied by Twitter, but before by Facebook and MySpace–and they’ll bring all their problems with them.

Can BlueSky scale to hundreds of millions of users?

Can BlueSky’s business model succeed if tested as such a scale without adequate ramp up time?

Can they maintain a positive community and successfully moderate away the Nazis that currently infest Twitter without incurring the wrath of American politicians?

The BlueSky team has interesting times ahead of them, if they do win.

If the Fediverse were to win, we would need the most popular software (Mastodon) to heavily focus on moderation tools yesterday. The tools need not only exist, the software updates need to propagate the network and instance admins learn to use them before the tidal wave of new users and their Twitter habits arrive.

I don’t think the Fediverse is in a position to “win”.

But, in my humble opinion, the best thing for the Fediverse right now isn’t to “win”.

I think it’s in Fedi’s best interest to let BlueSky tank the waves of popular appeal. We’ll continue to exist, doing our own thing.

What About Twitter?

Well, Twitter shouldn’t win. It’s become the Nazi bar.

If your politics are extremely right-wing and authoritarian, you’ll love Twitter.

Twitter is the website where you can call me slurs and wish death on me, and nothing will happen to you, but if you say the word “cisgender” your post is flagged for “Hateful Content”.

Twitter is Dead

I’ve long since been a critic of Twitter. In 2020, I wrote about how they only checked the length of your Gender field client-side, and tolerated up to a megabyte of data to be stored if you ignored that.

When they first pitched Birdwatch (now “Community Notes”), I called it fundamentally flawed. I stand by that, but for a brief moment, it was actually kind of funny.

The death of Twitter began when they banned a bunch of journalists (and one furry blogger) while calling it “free speech”.

The most recent moves (forced arbitration in a Texas court that always sides with the corporation, allowing your Twitter posts to be trained by their AI, etc.) weren’t the death of Twitter, they’re just stages of decomposition in rigor mortis.

Elon Musk calls Twitter (now “X”, named after his relationship with his wife) the “everything app”.

If you try to be everything to everyone, you will become nothing. And X will become exactly that.

Personally, I wouldn’t be surprised to hear that this was deliberate self-sabotage. After all, the money to buy Twitter came from Saudi Arabia. Therefore, if it’s also true that Twitter was instrumental in the Arab Spring, then Twitter’s downfall could be intentional as a form of retribution.

BlueSky and Decentralization

BlueSky is currently centralized, in the same way that Twitter always has been.

BlueSky was meant to be a protocol first, not a platform. They have always had the intent of eventually becoming decentralized, even if they built a central pillar from their inception.

If that actually happens, then the folks that adapt to BlueSky will be boiling-frogged into being more comfortable with decentralization.

Should that happen, the Fediverse will be less uncomfortable to many people who were hesitant to join. After all, the decision paralysis of “what instance do I choose?” will vanish.

Looking Forward

The best possible outcome for the Internet is for BlueSky to become a competitor with X (the smoldering husk that used to be Twitter) with roughly equal market share.

This means the Fediverse will thrive, the people that remain on X will get what they deserve (each other), and BlueSky will get all of the benefits of a mass market appeal. It also means that BlueSky will have to experiment with moderation tooling to cope with the influx of new users, which the Fediverse developers can learn from to improve the experience for everyone here. Win-win all around.

So I invite Fediverse users to cheer, “BlueSky wins,” with me… and then we will resume posting on Fedi instead.

CMYKat

What if I want to join the Fediverse instead?

Check out this website: FurryFediverse.org.

It explains everything you need and reduces the cognitive load of needing to choose an instance.

(You can also just get started where ever you’d like, and then move if you’re not happy with your starter instance.)

Is the Twitter Exodus Temporary?

In the past couple of years, there have been a lot of waves of people leaving Twitter to another platform (Mastodon, BlueSky, etc.), only to return a little while later. The Network Effect is more powerful than most people realize.

I do think this time is different for one simple reason: Influencers and celebrities are starting to make the jump to BlueSky.

Many of their fans and followers will probably straddle both apps for a while, before they decide they like BlueSky better. That is why I believe the current exodus from Twitter is likely to be the most decisive one.

Before 2040, we will probably be talking about a BlueSky exodus as well. This could be a result of their “credible exit” strategy, or because they failed as a protocol.

Even if you dislike BlueSky, or disagree with its business model or technical decisions, it’s worth paying attention to how their story unfolds. There will undoubtedly be lessons to learn here.

Header art: Background by Jim, foreground by CMYKat (edited by me).

#0cf #BlueSky #fediverse #Twitter

WDR Heimatfilm – „Eher fliegen hier Ufos“ (2023)

@SWeiermann gebührt der Dank für seinen Hinweis auf diesen Film vom WDR in der ARD-Mediathek. Warum ich den Film von Ingo Haeb und Gina Wenzel damals übersehen habe, weiß ich nicht. Vielleicht war es die „Programmbegleitung“ der ARD? Vielleicht hatte ich anderes zu tun? Dumm wäre es gewesen, hätte ich den Film verpasst!

Mediathekperlen | WDR Heimatfilm - „Eher fliegen hier Ufos“ (2023)

SWeiermann gebührt der Dank für seinen Hinweis auf diesen Film vom WDR in der ARD-Mediathek. Warum ich den Film von Ingo Haeb und Gina Wenzel damals…

^{Mediathekperlen (NexxtPress)}

Willkommen zu Krasse Links No 30. Heftet Euch Gewalt an die Pfadentscheidung, heute dematerialisieren wir die Erlaubnisstrukturen der Superindividuen.

Wenn am 5. November Donald Trump die Wahl gewinnt, wird er Präsident der Vereinigten Staaten. Aber was passiert, wenn Kamala Harris die Wahl gewinnt? Entweder wird sie Präsidentin, oder …

A key swing state takes several days to finish counting votes. Harris edges Trump by a few thousand ballots, appearing to clinch the election. Trump then blankets the state with ads exhorting officials to “stop the steal,” sends top allies to rail daily outside counting facilities about a crooked process, files a blizzard of litigation urging judges to throw out ballots being counted after Election Day and spreads claims that the vote was swung by non-citizens. Threats rain down on election officials and vote counters, with protests driving up the local and national temperature. Then, Trump allies on a handful of county election boards resist certification, threatening to disenfranchise thousands of voters and disrupt the state’s effort to finalize an accurate count.

All die Verschwörungstheorien, Lügen und Grenzverletzungen aus dem MAGA-Lager sind nicht einfach „Desinformationen“ oder „Propaganda“. Wir sollten uns stattdessen fragen:

Wozu geben sie sich damit die Erlaubnis?

Neulich hatte ich hier über ein KI-Paper von Anthropic berichtet, in dem via „Sparse Autoencoder“ (ein spezielle Art von neuronalem Netz, das ich dort auch erkläre) einzelne Semantiken im Neuronengefüge eines Large Langugage Models identifiziert und isoliert wurden.

Nun haben Wissenschaftler*innen diese Methode dazu genutzt, unterschiedliche Modelle darauf zu testen, ob sie dieselben Semantiken (hier: monosemantische Features) implementieren und die Antwort ist: yep.

Our findings reveal a high degree of similarity in SAE feature spaces across various models. Furthermore, our research reveals that subspaces of features associated with specific semantic concepts, such as calendar or people tokens, demonstrate remarkably high similarity across different models. This suggests that certain semantic feature subspaces are universally encoded across varied LLM architectures.

Das beweist natürlich meine Theorie nicht, aber ein anderes als dieses Ergebnis würde sie hinfällig machen.

Der hier öfter zitierte François Chollet hat einen sehenswerten Vortrag über die technischen Grenzen von Large Language Models gehalten und ich bleibe dabei: er scheint einer der wenigen im Silicon Valley zu sein, die es geblickt haben.

2022 hatte ich zusammen mit anderen im Auftrag des Wikimedia e.V. die Konzeptstudie über die „Nationale Bildungsplattform“ (jetzt: „Digitale Vernetzungsinfrastruktur für die Bildung“) veröffentlicht und die eine Erkenntnis, die mich seitdem haunted, ist, wie pfadopportunistisch Technologieentwicklung ist.

Wir führten einige semistrukturierte Interviews mit allen möglichen Beteiligten und fanden heraus, dass das ganze Konzept von Anfang an und bis zum Ende des Prozesses auf einem Prototypen basierte (BIRD), der wiederum auf Softwarekomponenten basierte, die allesamt im Zuge eines anderen Projektes an der Universität Potsdam entwickelt wurden.

Ulrike Lucke hatte an der Uni Rostock bereits an vergleichbaren Problemen gearbeitet und in ihrer Zeit an der Universität Potsdam weiter die Vernetzung von Hochschuldiensten vorangetrieben. (Lucke Interview, 2022) Insbesondere über den ebenfalls vom BMBF geförderten »Qualitätspakt Lehre« wurden viele Technologien entwickelt und erprobt, die heute in BIRD stecken. So hatte das »Schaufenster«, das sich in den Ausschreibungsunterlagen findet, bereits ein Vorleben an der Universität Pots- dam. An Single Sign-on und einem Walletkonzept wurde ebenfalls gearbeitet, und auch der Metadatenaustausch wurde in verschiedenen Projekten erprobt. In den Worten von Ulrike Lucke: »Also, es ist nichts 100 pro neu, sondern nur wirklich zusammengesammelt, angepasst, zusammengefügt.«

Ich will das nicht skandalisieren, sondern fand das erst nur erstaunlich und dann fand ich erstaunlich, dass ich es erstaunlich fand, obwohl es im wahrsten Sinne des Wortes naheliegend ist?

Vielleicht, weil wir uns Technologieentwicklung als Heldengeschichten von genialen Individuen erzählen, haben wir das Offensichtliche übersehen, nämlich, dass jede neue Technologie eine Pfadentscheidung ist, die durch vorherige Pfadentscheidungen ermöglicht wurde. Technologieentwicklung ist ein Gestrüpp, dass sich nur entlang seiner Ränder weitererzählen lässt.

Sicher, die Navigation technologischer Pfadgelegenheiten ist (meist) profitgetrieben, aber weil das, was bereits im Regal liegt, die plausiblen Pfade vorzeichnet, entwickelt Technologie immer auch ein Eigenleben.

Umgekehrt heißt das auch: Einmal errichtete Infrastruktur determiniert und motiviert ihre Anschlussnutzung.

Italien baut mit EU-Geldern Konzentrationslager und andere militarisierte Infrastrukturen in Tunesien (und beginnend auch in Albanien) und der Guardian hatte vor ein paar Wochen eine ausführlich recherchierte Story mit vielen Einzelschicksalen.

Marie, from the Ivory Coast city of Abidjan, knows others who describe rape by Tunisia’s national guard. “We’re being raped in large numbers; they [the national guard] take everything from us.”

Andere werden in die Wüste getrieben.

Her body was found mid-August near Kasserine, face down in sand. Mohamed estimates up to 50 of his friends have been snatched from Sfax by the national guard and dumped in the desert. Of these five have disappeared or were found dead. Another 10 crossed into Algeria.

Die Zustände in den Camps sind menschenverachtend.

“They eat dead animals, roadkill, anything they find,” says Youssef.
Denied all healthcare, Yasmine says the camp is rife with disease including tuberculosis, HIV, scabies and syphilis. Concern is mounting over the infant mortality rate. “Babies are born in 40C heat without medical help, vaccination, food. How can they survive?”

Behaltet Eure Meloni-Beschimpfungen für Euch, denn das ist unsere Gewalt. Sie passiert in unserem Namen und wir erlauben das. Und diese Erlaubnisstruktur ist bereits eine wichtige Pfadentscheidung dafür, wie wir mit der Milliarde Flüchtlingen im Zuge des bevorstehenden Klimakollaps umgehen werden. Wer immer noch glaubt, in der Startrek Timeline zu leben, sollte langsam mal aufwachen.

In seinem Newsletter spielt Timothy Snider einmal durch, was es bedeutet, wenn Trump seine Pläne für Massendeportationen wahr macht.

An attempt to rapidly deport twelve million people will also change everyone else. As Trump has said, such an action will have to bring in law enforcement at all levels. Such a huge mission will effectively redefine the purpose of law enforcement: the principle is no longer to make all people feel safe, but to make some people unsafe. And of course the diversion of law enforcement resources to deportation means that crimes will not be investigated or prosecuted. So some people will be radically less safe, but everyone regardless of status will in fact be less safe.
[…]
The deep purpose of a mass deportation is to establish a new sort of politics, a politics of us-and-them, which means (at first) everyone else against the Latinos. In this new regime, the government just stokes the fears and encourages the denunciations, and we expect little more of it. If Trump and Vance win, this dynamic will be hard to stop, especially if they have majorities in Congress. The only way to avoid it is to stop them in November with the vote.

Weil wir nicht einfach gewalttätige Individuen sind, sondern Dividuen, die einander Gewalt erlauben (siehe auch Milgram), kommt jede Gewalt mit ihrer Erlaubnisstruktur.

Es ist am Ende nicht so sehr die Gewalt selbst, die die Gesellschaft verändert, sondern die Infrastrukturen der Gewalt und ihre angeschlossenen Erlaubnisstrukturen. Weil Semantiken alle miteinander verkoppelt sind, kann man keinen Gewaltakt rechtfertigen, ohne einen ganzen Rattenschwanz von verknüpften Semantiken mitzuverschieben. Alles, was der Faschismus berührt, färbt er ein.

Das gilt nicht nur für Massendeportationen. Wenn ich tausende Tote und Konzentrationslager an den EU-Außengrenze erlaube, weil ich finde, das hier zu viele „Fremde“ sind; wenn ich jahrelange Haftstrafen gegen Klimaaktivist*innen erlaube, weil sie den Verkehr stören; wenn ich den Tod von zigtausenden palästinensischen Zivilist*innen in Kauf nehme, weil „Israel sich verteidigen muss“, dann baue ich an immer monströseren Erlaubnisstrukturen, die immer mehr Gewalt normalisieren und also motivieren.

The Market Exit erklärt, warum Meritokratie Bullshit ist. Das eindrücklichste Beispiel war, fand ich, dass die Namen der normannischen Oberschicht, die England nach der Eroberung von 1066 regierte, immer noch überdurchschnittlich oft in den Immatrikulationslisten von Oxford und Cambridge zu finden sind.

Ich hatte im letzten Newsletter dazu aufgerufen Marx‘ Perspektive des historischen Materialismus zu adaptieren, doch dabei schließe ich Semantik ausdrücklich mit ein.

Warum auch nicht? Schallwellen, Tinte auf Papier, Pixel, Festplatten: jedes „sich Ausdrücken“ ist materiell. Und jede Semantik zeitigt materielle Effekte: Ein falsches oder richtiges Wort, ein bestimmtes Aussehen, ein Song oder ein Buch können enorme materielle Unterschiede ausmachen.

Doch semantische Pfadgelegenheiten bleiben latent und damit immateriell, bis zum Zeitpunkt ihrer Manifestation. Semantiken sind nur materiell in der Relationalität ihrer Artefakte, Sprechakte oder Urherberrechtsverfahren.

Was Semantiken ebenfalls materiell macht, ist, dass sie eingeübt sind. Oberschichts- und Unterschichts-Semantiken zu navigieren, ist ein jahrelang trainierter Skill, dessen LockIn soziale Verortung gleichzeitig signalisiert und enforced, wie Pierre Bourdieu bereits in den 1970er gezeigt hat.

Weil wir alle nur Pfadopportunist*innen sind, die semantische und materielle Pfadgelegenheiten wahrnehmen, die die Infrastrukturen bereitstellen, die halt so um uns herumstehen, gleiten oder grinden wir durchs Leben und reproduzieren im Lockstep-Individualismus die Strukturen, die uns hervorgebracht haben.

Cory Docotorow warnt davor, auf die Urheberrechtsklagen der Verlage gegen die KI-Startups zu hoffen. Der Feind deines Feindes ist nicht immer Dein Freund.

Seit dem Aufkommen von genrativer KI gibt es in der linken techkritischen Szene eine art „Reckoning“ mit alten urheberrechtskritischen Positionen, jetzt, da das Urheberrecht die einzige wirksame Waffe gegen Big Tech zu sein scheint.

Doch die Erzählung ist Kokolores. Einerseits profitiert Big Tech selbst in enormen Maße, weit mehr als die Verlage vom Urheberrecht und anderen Immaterialgüterrechten und zum Anderen wird das Urheberrecht keine der befürchteten Entwicklungen verhindern.

Was passieren wird ist, was immer passiert: die Verlage handeln ihre Deals aus und die Urheber*innen gehen leer aus. Der Grund für das Darben der Kreativen ist nämlich nicht ein impotentes Urheberrecht, sondern die relative Reduktion ihrer Netzwerkzentralität gegenüber einer sich immer stärker konzentrierenden Kulturindustrie.

The biggest predictor of how much money an artist sees from the exploitation of their work isn’t how many exclusive rights we have, it’s how much bargaining power we have. When you bargain against five publishers, four studios or three labels, any new rights you get from Congress or the courts is simply transferred to them the next time you negotiate a contract.
[…]
Giving a creative worker more copyright is like giving your bullied schoolkid more lunch money. No matter how much you give them, the bullies will take it all. Give your kid enough lunch money and the bullies will be able to bribe the principle to look the other way. Keep giving that kid lunch money and the bullies will be able to launch a global appeal demanding more lunch money for hungry kids!

Weil wir keine Individuen sind, die eigene Musikgeschmäcker haben, sondern Dividuen, die sich gegenseitig Musikgeschmäcker beibringen, kann man die Geschichte des Rock n’Roll auch als die Geschichte der kommerziellen Erschließung semantischer Netzwerkmacht erzählen.

Das Verlagswesen hatte bereits den Weg gewiesen, aber mit dem Aufkommen der Tonträgerindustrie und den Massenmedien wurde klar, dass man auf eine Ölquelle gestoßen war. Während die Kosten für die Produktion für Tonträger mit der Skalierung immer Bedeutungsloser wurden (Skaleneffekt), stiegen die Umsätze für virale Hits exponentiell ins Unermessliche.

Das Urheberrecht spielte zu dieser Zeit nur als Spezialrecht eine Rolle, das die Angelegenheiten zwischen Urheber*innen und Verlagen regelt, doch als mit dem Aufkommen des Internets dieses Geschäftsmodell in Frage stand, wurde das Urheberrecht auf Druck der Musikoligarchie zu einem allgegenwärtigen Regime umfunktioniert, mit dem wir alle jeden Tag in Berührung kommen.

Handelsverträge (WTO, TRIPS, TTIP, etc) machten Immaterialgüterrechte (dazu gehören auch Patente und Markenrechte) zu globalen Regimes und erschufen eine neues Paradigma der Ausbeutung, das sich immer mehr auf die Erschaffung und Kontrolle von semantischen Infrastrukturen spezialisierte und die Produktion materieller Güter mehr und mehr in Entwicklungs- und Schwellenländer auslagerte, wo sie Firmen und Arbeiter*innen um abfallenden Brotkrumen konkurrieren ließ.

In meinem Supplychain-Text spreche ich von „relationaler Dematerialisierung“ und meine, dass Arbeitskraft, Energieflüsse, Fabriken und alles Materielle immer austauschbarer gemacht werden, während man gleichzeitig an der Unaustauschbarmachung von immateriellen Gütern arbeitet. Der Anteil immaterieller Wertschöpfung hat in fast allen westlichen Ländern den des Materiellen längst überflügelt und die Machtkonzentration, die wir in den USA und den westlichen Ländern sehen, ist zum Großenteil auf die Privatisierung semantischer Netzwerkzentralitäten zurückzuführen.

Mit den Plattformen wurde schließlich ein ganz neues, rein technisches Regime etabliert, das weniger auf die Rechtedurchsetzung angewiesen war, weil es seine infrastruktureigenen Kontrollapparate einsetzt, um Netzwerkeffekte ausbeutbar zu machen.

Generative KI ist gewissermaßen nur die Zuspitzung eines seit längerem fortschreitenden Prozesses, quasi die endgültige relationale Dematerialisierung kreativer Arbeit. Es sollen künftig nur noch KI-Unternehmen von unserem Wunsch nach Tönen, Bildern und Texten profitieren und die Kulturindustrie verhandelt gerade ihren goldenen Fallschirm. Yeah, Urheberrecht!

Max Read hatte neulich in das Business des Newsletter-Schreibens eingeführt und weil ich gerade die freien 1000 Abonnent*innen bei MailPoet gesprengt habe und ab nun für den Spaß bezahlen muss, hab ich das interessiert gelesen.

Read haut seine wirklich relevanten Takes „for free“ raus, auch weil das Leser*innen gewinnt und seine „Payed Subscriber“ bekommen nur ein paar Literaturempfehlungen.

The paywalled post offers some kind of value-add (shopping guides, book recommendations, link roundups), the contents of which are teased above the paywall. This is the main way you convert your free subscribers to paid–they want access to all the good, valuable stuff you’re offering behind the paywall.

Das Newsletter-Business funktioniert so, dass Du mit einem bestimmten Wissen oder einer bestimmten Perspektive Aufmerksamkeit, also Netzwerkmacht aufbaust, die Du dann teilweise hinter die Infrastrukturen einer Bezahlschranke stellst.

Den Einsatz von Macht, um anderen seinen Willen aufzuzwingen, nennt man Gewalt. Das ist erstmal kein Problem, solange man dafür eine plausible Erlaubnisstruktur unterhält, aber blöderweise funktionieren die Existierenden nur für Individuen?

Klar, ich habe Arbeit, ich will und muss leben, um die Arbeit weiter fortzusetzen, etc. aber das ist halt nicht, wie eine Bezahlschranke funktioniert? Bezahlschranken setzten einen allgemeinen Preis für arm oder reich gleichermaßen und vor allem bleibt der Preis derselbe, wenn ich 100 oder 10.000 Abonnent*innen habe und selbst wenn ich satt bin, soll ich jemandem etwas was er oder sie will vorenthalten, obwohl es mich literally nichts kosten würde, es bereitzustellen. Während also die Einnahmen unabhängig vom Aufwand skalieren, korrumpiert das die Erlaubnisstruktur und macht es zur verdrängten Gewalt und wir wissen wohin das führt: Privatjets, die den Klimawandel beschleunigen.

Als Individuum kann man sagen: ich bin so krass, das habe ich mir verdient aber als pfadopportunistischer Navigator von Semantiken, die eh grad herumlagen ist das weitaus schwieriger. Im Gegensatz zum Individuum verdanke ich meinen moderaten Erfolg nämlich nicht meiner Genialität sondern Leuten, die schmerzfrei genug sind, zu meinem weirden Beats mitzunicken und die per Mouth-to-Mouth-Empfehlung die eigentliche Überzeugungsarbeit leisten. Habt vielen Dank dafür!

Also hier ist mein Deal:

1. Der Newsletter bleibt frei und Du bezahlt mich einfach freiwillig. Aber bitte keine Einmalspenden, sondern monatliche Daueraufträge.
2. Wenn Du weniger als 30.000 Euro im Jahr verdienst, will ich Dein Geld nicht. Es gibt tausend Arten, das Geld besser auszugeben. Kauf Dir lieber ein Eis!
3. Zur Orientierung: nach derzeitigem Stand ich wäre gesundgestoßen, wenn alle 1,50 zahlen, oder 100 Leute 15 Euro, oder 10 Leute 150 Euro. Nein, ich erwarte keine initiale Gesundstoßung.
4. Wenn Du so viel Geld hast, dass Du gar nicht so recht weißt wohin damit, bitte spende nicht über 150 Euro pro Monat. Ich schätze meine Unabhängigkeit.
5. Ansonsten: Denk beim Ausfüllen der Sepa-Lastschrift nicht an mich, sondern an all die Leser*innen, denen Du mit Deiner Spende den Zugang zum Newsletter ermöglichst.

Michael Seemann
IBAN: DE58251900010171043500
BIC: VOHADE2H
Paypal.

Elon Musk telefoniert seit 2022 regelmäßig mit Putin, Donald Trump behgauptet, Tim Cook hätte ihn angerufen und Jeff Bezos killt der Washington Post ihr Kamala Harris-Endorsement.

Wenn meine These, dass das Individuum nur eine Projektion auf die eigene infrastrukturvermittelte Agency ist, stimmt, dann folgt daraus, dass das „Individuum“ skalierbar ist. Je mächtiger die kontrollierten Infrastrukturen sind und je weitreichendere Pfadgelegenheiten sie ermöglichen, desto mehr Agency kann man als „Individualität“ auf das Selbst projizieren.

Hier meine These zu Milliardären: Durch die ungebremste Machtakkumulation im Neoliberalismus entstand die Psychologie des Superindividuums. Menschen, die über so viel infrastukturvermittelte Macht verfügen, dass sie begonnen haben, sich als Superhelden zu erzählen.

Und meine weitergehende These ist, dass Milliardäre in Wirklichkeit gar keine Individuen sind, sondern Dividuen, die sich das Milliardärsein voneinander abschauen, weshalb Trumps ungesühnte Grenzüberschreitungen bei Bezos, Thiel, Sachs, Cook, Ackman, Zuckerberg und vor allem Musk ein Milliardärs-Klassenbewusstsein inspiriert. Sie beginnen zu verstehen, dass Trumps Wahlsieg eine universelle, ungecheckte Erlaubnisstruktur für Superindividuen wie sie in Aussicht stellt.

Da auch Klassenbewusstseine ihre Pfadentscheidungen haben, ist es vielleicht interessant, dass ein relevanter Teil der sich gerade radikalisierenden Milliardäre ihren herrschaftlichen Blick in Appartheits-Süd-Afrika eingeübt hat.

Elon Musk lived in apartheid South Africa until he was 17. David Sacks, the venture capitalist who has become a fundraiser for Donald Trump and a troll of Ukraine, left aged five, and grew up in a South African diaspora family in Tennessee. Peter Thiel spent years of childhood in South Africa and Namibia, where his father was involved in uranium mining as part of the apartheid regime’s clandestine drive to acquire nuclear weapons. And Paul Furber, an obscure South African software developer and tech journalist living near Johannesburg, has been identified by two teams of forensic linguists as the originator of the QAnon conspiracy, which helped shape Trump’s Maga movement. (Furber denies being “Q”.)
[…]
To whites of a certain mindset, this inequality wasn’t due to apartheid. They thought it was inscribed in nature. Certain people were equipped to succeed in capitalism, while others weren’t. That was simply the way it was, and it was pointless to try to mess with nature. Two of Thiel’s contemporaries at Stanford in the 1980s recall him telling them that apartheid “works” and was “economically sound”. His spokesman has denied that he ever supported apartheid.

Dazu passt diese Recherche vom Guardian, dass hinter dem erwachenden Interesse für „race science“ ebenfalls ein Netzwerk von unter anderem Tech-Oligarchen steckt, das über dubiose Think Tanks Journalismus und Wissenschaften beeinflusst. Nicht nur in den USA, auch in Deutschland.

Spencer Ackerman war bei „Tech Won’t Save us“ und erklärt überzeugend, warum Israels Krieg in Gaza Labor und Prototyp einer neuen Form der Kriegsführung ist, die wir bald überall sehen werden: Komplett KI-gestüzt, halbautomatisiert und erbarmungslos.

Roberto J. González schreibt in diesem Paper über die immer engere Verzahnung des Industriellen Militärischen Komplexes mit Silicon Valley. Zwischen 2019 and 2022 vergab das Militär bereits ca. $53 Milliarden und mit KI geht Trend steil nach oben.

Over the past two years, global events have further fueled the Pentagon’s demand for Silicon Valley technologies, including the deployment of drones and AI-enabled weapon systems in Ukraine and Gaza, and fears of a global AI arms race against China. The prospect of Russian cyberwarfare and disinformation campaigns have also motivated Defense Department officials to invest heavily in new digital technologies. Consequently, DoD officials have outlined plans to develop expansive fleets of autonomous aerial, maritime, and terrestrial drones for transportation, surveillance, and combat; acquire commercial cloud computing capabilities for data sharing, data storage, and “seamless connectivity”; bolster America’s cyberdefense systems; and employ AI for training and combat simulation exercises.

Hier, was ich glaube, was passieren wird:

• Die Gen-KI-Blase platzt und das wird einige Startups killen, aber nicht die Großen.
• Die gigantomatischen KI-Rechenzentren stehen aber jetzt in der Landschaft und determinieren und motivieren Anschlussnutzung.
• Während sich die geopolitischen Spannungen überall auf der Welt hochschaukeln und alle sicher sind, dass der nächste Krieg durch KI entschieden wird.
• Während die Tech-Billionär-Kaste von Superindividuen ihr faschistisches Klassenbewusstsein entdeckt und sich immer stärker an den militärisch-industriellen Komplex kuschelt.
• Während wir unsere Erlaubnisstrukturen schneller skalieren, als Elon Musk seine Versprechen.

Fazit: WWIII wird … weird, und: Gaza for the Rest of us.

mspr0.de/krasse-links-no-30/

Warum Geheimdienste lügen – „Curveball“ (2020)

Ein guter Indikator für den Wahrheitsgehalt eines Films, welcher, zum Beispiel, die Arbeit von deutschen Geheimdiensten zum Gegenstand hat, ist darauf zu schauen, wer sich darüber beschwert. Und wenn die „Beschwerde“ etwa vom „Gesprächskreis Nachrichtendienste in Deutschland“ stammt, dann ist das ein Zeichen, dass der Film sich wirklich lohnt!

NexxtPress | Warum Geheimdienste lügen - „Curveball“ (2020)

Ein guter Indikator für den Wahrheitsgehalt eines Films, welcher, zum Beispiel, die Arbeit von deutschen Geheimdiensten zum Gegenstand hat…

^{Mediathekperlen (NexxtPress)}

Alte Männer, Freundschaft, Rock&Roll – „So viel Zeit“ (2018)

Ich bin ja selber einer. Habe die Achtziger überlebt und kann mich erinnern. Wer auch immer zu der Zeit im Ruhrgebiet unterwegs war, der/dem geht es bei diesem Film möglicherweise ganz ähnlich. Das passt hier schon ganz gut. Und… man(n) muss diese alten Männer einfach lieben…

NexxtPress | Alte Männer, Freundschaft, Rock&Roll – „So viel Zeit“ (2018)

Ich bin ja selber einer. Habe die Achtziger überlebt und kann mich erinnern. Wer auch immer zu der Zeit im Ruhrgebiet unterwegs war, der/dem geht es bei…

^{Mediathekperlen (NexxtPress)}

Mads Mikkelsen – „Der Rausch“ (2020)

„Es begann als Film über Alkohol und Freundschaft, und dann hatten wir den Ehrgeiz, ihn zu einem Film über das Leben zu machen. Es geht nicht nur darum, am Leben zu sein, sondern zu leben.“ (Thomas Vinterberg, Regisseur)

NexxtPress | Mads Mikkelsen - „Der Rausch“ (2020)

„Es begann als Film über Alkohol und Freundschaft, und dann hatten wir den Ehrgeiz, ihn zu einem Film über das Leben zu machen. Es geht nicht nur darum…

^{Mediathekperlen (NexxtPress)}