I've been wondering if there's a decentralized, Fediverse-compatible alternative to Pinterest out there.
The idea of a federated platform for sharing and curating visual content, DIY ideas, and inspiration boards seems like it could be a great addition to the Fediverse ecosystem.
Some questions I have:
Does anyone know of an existing project that's similar to Pinterest but Fediverse-compatible?
If not, has anyone considered developing such a platform?
What challenges might be involved?
Perhaps it could be potentially created under the Pixelfed Banner, similar to Loops?
Would there be interest in the community for a Pinterest-like service on the Fediverse?
I personally believe that this could be an exciting project, but personally, I lack the technical knowledge, energy, and time to take it on myself.
However, I'd love to hear your thoughts and see if there's any traction for this idea.
If such a service doesn't exist yet, maybe this post could spark a discussion or inspire someone with the right skills to consider
... mehr anzeigen
I've been wondering if there's a decentralized, Fediverse-compatible alternative to Pinterest out there.
The idea of a federated platform for sharing and curating visual content, DIY ideas, and inspiration boards seems like it could be a great addition to the Fediverse ecosystem.
Some questions I have:
Does anyone know of an existing project that's similar to Pinterest but Fediverse-compatible?
If not, has anyone considered developing such a platform?
What challenges might be involved?
Perhaps it could be potentially created under the Pixelfed Banner, similar to Loops?
Would there be interest in the community for a Pinterest-like service on the Fediverse?
I personally believe that this could be an exciting project, but personally, I lack the technical knowledge, energy, and time to take it on myself.
However, I'd love to hear your thoughts and see if there's any traction for this idea.
If such a service doesn't exist yet, maybe this post could spark a discussion or inspire someone with the right skills to consider developing it.
What do you all think?
Is this something you'd be interested in using or contributing to?
would love to see something along those lines, I was a active user of FFFFound back in the day and would love to see an interface like that for image bookmarking
Eine einfache Reimübung zur Jahreszeit. […] Gegen die Langeweile, die mich doch hin und wieder ereilt, gehe ich mit lockeren Übungen an. Nein, weiß Gott nicht mit sportlichen […]
Last year, I outlined the specific requirements that an app needs to have in order for me to consider it a Signal competitor.
Afterwards, I had several people ask me what I think of a Signal fork called Session. My answer then is the same thing I’ll say today:
Don’t use Session.
The main reason I said to avoid Session, all those months ago, was simply due to their decision to remove forward secrecy (which is an important security property of cryptographic protocols they inherited for free when they forked libsignal).
Lack of forward secrecy puts you in the scope of Key Com
... mehr anzeigen
Don’t Use Session (Signal Fork)
Last year, I outlined the specific requirements that an app needs to have in order for me to consider it a Signal competitor.
Afterwards, I had several people ask me what I think of a Signal fork called Session. My answer then is the same thing I’ll say today:
Don’t use Session.
The main reason I said to avoid Session, all those months ago, was simply due to their decision to remove forward secrecy (which is an important security property of cryptographic protocols they inherited for free when they forked libsignal).
And that observation alone should have been enough for anyone to run, screaming, in the other direction from Session. After all, removing important security properties from a cryptographic security protocol is exactly the sort of thing a malicious government would do (especially if the cover story for such a change involves the introduction of swarms and “onion routing”–which computer criminals might think sounds attractive due to their familiarity with the Tor network).
Unfortunately, some people love to dig their heels in about messaging apps. So let’s take a closer look at Session.
I did not disclose this blog post privately to the Session developers before pressing publish.
I do not feel that cryptographic issues always require coordinated disclosure with the software vendor. As Bruce Schneier argues, full disclosure of security vulnerabilities is a “damned good idea”.
One of the departures of Session from Signal is the use of Ed25519 rather than X25519 for everything.
Ed25519 Keypairs generated from their KeyPairUtilities object only have 128 bits of entropy, rather than the ~253 bits (after clamping) you’d expect from an Ed25519 seed.
fun generate(): KeyPairGenerationResult { val seed = sodium.randomBytesBuf(16) try { return generate(seed) } catch (exception: Exception) { return generate() }}fun generate(seed: ByteArray): KeyPairGenerationResult { val padding = ByteArray(16) { 0 } val ed25519KeyPair = sodium.cryptoSignSeedKeypair(seed + padding)
You might think that clearing the highest 128 bits of the Ed25519 seed is fine for one of the following reasons:
It’s hashed with SHA512 before clamping.
Ed25519 only offers 128 bits of security.
Some secret third (and possibly unreasonable) argument.
It’s true that Ed25519 targets the 128-bit security level, if you’re focused on the security of the Elliptic Curve Discrete Logarithm Problem (ECDLP).
Achieving 128 bits of security in this model requires 256-bit secrets, since the best attack against the ECDLP finds a discrete logarithm in guesses.
Additionally, having 256-bit secrets makes the multi-user security of the scheme easy to reason about, whereas 128-bit secrets makes it a lot harder. (This mostly comes up in criticism of AES, which has a 128-bit block size.)
When your secret only has possible values, your multi-user security is no longer as secure as Ed25519 expects.
Additionally, you can shove the SHA512 + clamping in your attack script (thus negating the first objection) and find the corresponding secret key in queries if you know the top 128 bits were initialized to 0, using a modified version of Pollard’s rho for discrete logarithms.
This means that Session’s KeyPairUtilities class only provides 64 bits of ECDLP security.
What does 64 bits of ECDLP Security actually mean?
I provided a technical definition already, but that’s probably not meaningful to most people outside computer security.
What this means is that a distributed computing effort can find the secret key for a given Ed25519 public key generated from this algorithm in only queries.
Based on this attack, the authors projected that a collision attack on SHA-1 may cost between US$75K and US$120K by renting GPU computing time on Amazon EC2 using spot-instances, which is significantly lower than Schneier’s 2012 estimates.
I don’t know if this was mere stupidity or an intentional NOBUS backdoor that only well-resourced adversaries can crack. (I also don’t have hundreds of thousands of dollars lying around to test this myself.)
How would you exploit this in practice?
If you’re not familiar with Pollard’s rho, then this section might be a bit abstract and difficult to follow.
Instead of directly passing a full 256-bit value to your oracle with each iteration (like you do with a standard Pollard’s rho implementation), you would need mutate the output the same way Session does (n.b., replace 128 bits of the seed with zeroes), hash & clamp that, and then perform the scalar multiplication.
It should be a bit more expensive than a raw ECDLP attack against a 128-bit curve (due to the hashing), but the strategy should succeed in the expected number of queries (average case).
Although this makes the attack totally feasible for a nation state, I do not have the resources to build and test a proof of concept against a candidate keypair. If anyone does, get in touch, it would make for a fun research project.
Alternatively, Pollard’s kangaroo might be a better cryptanalysis technique for Session’s setup.
Note: If there is any classified government algorithm especially suited for cracking Ed25519 keys constructed exactly like Session does, it’s not one I’ve ever heard of. I don’t have any security clearances, nor do I want one.
However, ECDLP security of elliptic curve-based protocols is extremely well-understood in the cryptography literature.
I wasn’t entirely sure whether this belongs in the “gripes” section or not, because it’s so blatantly stupid that there’s basically no way Quarkslab would miss it if it mattered.
When encrypting payloads for onion routing, it uses the X25519 public key… as a symmetric key, for AES-GCM. See, encryptPayloadForDestination().
val result = AESGCM.encrypt(plaintext, x25519PublicKey)deferred.resolve(result)
val plaintext = encode(previousEncryptionResult.ciphertext, payload)val result = AESGCM.encrypt(plaintext, x25519PublicKey)
In case you thought, maybe, that this is just a poorly named HPKE wrapper… nope!
/** * Sync. Don't call from the main thread. */internal fun encrypt(plaintext: ByteArray, symmetricKey: ByteArray): ByteArray { val iv = Util.getSecretBytes(ivSize) synchronized(CIPHER_LOCK) { val cipher = Cipher.getInstance("AES/GCM/NoPadding") cipher.init(Cipher.ENCRYPT_MODE, SecretKeySpec(symmetricKey, "AES"), GCMParameterSpec(gcmTagSize, iv)) return ByteUtil.combine(iv, cipher.doFinal(plaintext)) }}
This obviously doesn’t encrypt it such that only the recipient (that owns the secret key corresponding to the public key) can decrypt the message. It makes it to where anyone that knows the public key can decrypt it.
I wonder if this impacts their onion routing assumptions?
Why should I trust session?
(…)
When using Session, your messages are sent to their destinations through a decentralised onion routing network similar to Tor (with a few key differences) (…)
There are a lot of Session’s design decisions that are poorly specified in their Whitepaper and I didn’t look at. For example, how group messaging keys are managed.
When I did try to skim that part of the code, I did find a component where you can coerce Android clients into running a moderately expensive Argon2 KDF by simply deleting the nonce from the message.
val isArgon2Based = (intermediate["nonce"] == null)if (isArgon2Based) { // Handle old Argon2-based encryption used before HF16
That’s hilarious.
Cryptography nerds should NOT be finding the software that activists trust with their privacy hilarious.
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.
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.
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.
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.
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.
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!
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.
I run a community on my instance called Vegan Home Cooks which is ultimately just pictures of what people cooked that day. I was wondering if there is a way to leverage the new interest in Pixelfed to drive users to it and maybe bridge it some how. I haven't really tried Pixelfed yet and was wondering what your experience has been with it
"Bei der legendären Exit Party bringen die Original DJs den Sound und das Feeling des alten Exits zurück in die Halle der Cobra. Eine Veranstaltung in der die DJs die besten Hits aus vergangenen Zeiten in Müngsten auflegen.
Tickets gibt‘s im Vorverkauf und es empfiehlt sich, diese frühzeitig zu sichern, da diese Veranstaltung immer schnell ausverkauft ist.
Die Exit Party bietet eine hervorragende Gelegenheit, alte Erinnerungen aufleben zu lassen und gemeinsam mit Freunden durch eine unvergessliche Nacht zu rocken."
Die Party am 18.1. ist bereits lange ausverkauft, für die Party im Mai gibt es noch (!) Tickets über Solingen-Live
aus dem Programm: - Ulrike Reutter: "Ihre Route wird neu berechnet - Impulse für die Mobilitäts- und Verkehrswende" - Geprächsrunde 1: "Die Verkehrswende in der kommunalen Praxis: wo und wie findet sie bereits statt" - Gesprächsrunde 2: "Wer sind die Akteure für die Verkehrswende"
"Nach 38 Berufsjahren, davon 10 an der Bergischen Universität Wuppertal, verabschiedet sich Prof. Dr.-Ing. Ulrike Reutter in den Ruhestand. Zu ihrer Abschiedsvorlesung und dem Kolloquium „Bitte wenden! Zur Verkehrswende jetzt abbiegen!“ sind Sie sehr herzlich eingeladen. Wir möchten mit Kolleginnen und Kollegen den Stand der Verkehrswende aus kommunaler Sicht, aus Sicht von Verkehrsunternehmen und aus Sicht der Wissenschaft diskutieren. Die Teilnahme ist kostenfrei.
Um eine Anmeldung über unsere Website wird bis zum 15. Januar 2025 gebeten."
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
... mehr anzeigen
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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?
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.
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.
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.
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.
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.
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.
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.
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!
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.
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 o
... mehr anzeigen
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.
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.
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.
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.
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.
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!
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.
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.
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).
(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.
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”.
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.
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.
Android doesn’t limit you to one Google account per device. As with Windows and macOS, you can set up multiple logins and switch between them — assuming your version of Android includes this feature.
Needless to say, these are somewhat chaotic times.
One topic that has come up several times in the past few days, to the astonishment of many new Mastodon users, is that Direct Messages between users aren’t end-to-end encrypted.
And while that fact makes Mastodon DMs no less safe than Twitter DMs have been this whole time, there is clearly a lot of value and demand in dep
... mehr anzeigen
Towards End-to-End Encryption for Direct Messages in the Fediverse
Needless to say, these are somewhat chaotic times.
One topic that has come up several times in the past few days, to the astonishment of many new Mastodon users, is that Direct Messages between users aren’t end-to-end encrypted.
And while that fact makes Mastodon DMs no less safe than Twitter DMs have been this whole time, there is clearly a lot of value and demand in deploying end-to-end encryption for ActivityPub (the protocol that Mastodon and other Fediverse software uses to communicate).
However, given that Melon Husk apparently wants to hurriedly ship end-to-end encryption (E2EE) in Twitter, in some vain attempt to compete with Signal, I took it upon myself to kickstart the E2EE effort for the Fediverse.
So I’d like to share my thoughts about E2EE, how to design such a system from the ground up, and why the direction Twitter is heading looks to be security theater rather than serious cryptographic engineering.
If one were feeling particularly cavalier about your E2EE designs, they could just generate then dump public keys through a server they control, pass between users, and have them encrypt client-side. Over and done. Check that box.
Every public key would be ephemeral and implicitly trusted, and the threat model would mostly be, “I don’t want to deal with law enforcement data requests.”
If you’re catering to a slightly tech-savvy audience, you might throw in SHA256(pk1 + pk2) -> hex2dec() and call it a fingerprint / safety number / “conversation key” and not think further about this problem.
Look, technical users can verify out-of-band that they’re not being machine-in-the-middle attacked by our service.
An absolute fool who thinks most people will ever do this
From what I’ve gathered, this appears to be the direction that Twitter is going.
Now, if you’re building E2EE into a small hobby app that you developed for fun (say: a World of Warcraft addon for erotic roleplay chat), this is probably good enough.
If you’re building a private messaging feature that is intended to “superset Signal” for hundreds of millions of people, this is woefully inadequate.
If this is, indeed, the direction Musk is pushing what’s left of Twitter’s engineering staff, here is a brief list of problems with what they’re doing.
Twitter Web. How do you access your E2EE DMs after opening Twitter in your web browser on a desktop computer?
If you can, how do you know twitter.com isn’t including malicious JavaScript to snarf up your secret keys on behalf of law enforcement or a nation state with a poor human rights record?
If you can, how are secret keys managed across devices?
If you use a password to derive a secret key, how do you prevent weak, guessable, or reused passwords from weakening the security of the users’ keys?
If you cannot, how do users decide which is their primary device? What if that device gets lost, stolen, or damaged?
Authenticity. How do you reason about the person you’re talking with?
Forward Secrecy. If your secret key is compromised today, can you recover from this situation? How will your conversation participants reason about your new Conversation Key?
Multi-Party E2EE. If a user wants to have a three-way E2EE DM with the other members of their long-distance polycule, does Twitter enable that?
How are media files encrypted in a group setting? If you fuck this up, you end up like Threema.
Is your group key agreement protocol vulnerable to insider attacks?
Cryptography Implementations.
What does the KEM look like? If you’re using ECC, which curve? Is a common library being used in all devices?
Who is reviewing the code that interacts with E2EE?
Is there even a penetration test before the feature launches?
As more details about Twitter’s approach to E2EE DMs come out, I’m sure the above list will be expanded with even more questions and concerns.
My hunch is that they’ll reuse liblithium (which uses Curve25519 and Gimli) for Twitter DMs, since the only expert I’m aware of in Musk’s employ is the engineer that developed that library for Tesla Motors. Whether they’ll port it to JavaScript or just compile to WebAssembly is hard to say.
How To Safely Build E2EE
You first need to decompose the E2EE problem into five separate but interconnected problems.
Client-Side Secret Key Management.
Multi-device support
Protect the secret key from being pilfered (i.e. by in-browser JavaScript delivered from the server)
Public Key Infrastructure and Trust Models.
TOFU (the SSH model)
X.509 Certificate Authorities
Certificate/Key/etc. Transparency
SigStore
PGP’s Web Of Trust
Key Agreement.
While this is important for 1:1 conversations, it gets combinatorially complex when you start supporting group conversations.
On-the-Wire Encryption.
Direct Messages
Media Attachments
Abuse-resistance (i.e. message franking for abuse reporting)
The Construction of the Previous Four.
The vulnerability of most cryptographic protocols exists in the joinery between the pieces, not the pieces themselves. For example, Matrix.
This might not be obvious to someone who isn’t a cryptography engineer, but each of those five problems is still really hard.
To wit: The latest IETF RFC draft for Message Layer Security, which tackles the Key Agreement problem above, clocks in at 137 pages.
Additionally, the order I specified these problems matters; it represents my opinion of which problem is relatively harder than the others.
When Twitter’s CISO, Lea Kissner, resigned, they lost a cryptography expert who was keenly aware of the relative difficulty of the first problem.
You may also notice the order largely mirrors my previous guide on the subject, in reverse. This is because teaching a subject, you start with the simplest and most familiar component. When you’re solving problems, you generally want the opposite: Solve the hardest problems first, then work towards the easier ones.
The Journey of a Thousand Miles Begins With A First Step
Before you write any code, you need specifications.
Before you write any specifications, you need a threat model.
Before you write any threat models, you need both a clear mental model of the system you’re working with and how the pieces interact, and a list of security goals you want to achieve.
If you do not clearly specify your non-goals, they still exist implicitly. However, you may find yourself contradicting them as you change your mind over the course of development.
Being wishy-washy about your security goals is a good way to compromise the security of your overall design.
In my Mastodon E2EE proposal document, I have a section called Design Tenets, which states the priorities used to make trade-off decisions. I chose Usability as the highest priority, because of AviD’s Rule of Usability.
Security at the expense of usability comes at the expense of security.
Avi Douglen, Security StackExchange
Underneath Tenets, I wrote Anti-Tenets. These are things I explicitly and emphatically do not want to prioritize. Interoperability with any incumbent designs (OpenPGP, Matrix, etc.) is the most important anti-tenet when it comes to making decisions. If our end-state happens to interop with someone else’s design, cool. I’m not striving for it though!
Finally, this section concludes with a more formal list of Security Goals for the whole project.
Every component (from the above list of five) in my design will have an additional dedicated Security Goals section and Threat Model. For example: Client-Side Secret Key Management.
You will then need to tackle each component independently. The threat model for secret-key management is probably the trickiest. The actual encryption of plaintext messages and media attachments is comparatively simple.
Finally, once all of the pieces are laid out, you have the monumental (dare I say, mammoth) task of stitching them together into a coherent, meaningful design.
If you did your job well at the outset, and correctly understand the architecture of the distributed system you’re working with, this will mostly be straightforward.
Making Progress
At every step of the way, you do need to stop and ask yourself, “If I was an absolute chaos gremlin, how could I fuck with this piece of my design?” The more pieces your design has, the longer the list of ways to attack it will grow.
You should also be familiar enough with the cryptographic primitives you’re working with before you begin such a journey; because even once you’ve solved the key management story (problems 1, 2 and 3 from the above list of 5), cryptographic expertise is still necessary.
If you’re feeding data into a hash function, you should also be thinking about domain separation. More information.
If you’re feeding data into a MAC or signature algorithm, you should also be thinking about canonicalization attacks. More information.
It’s tempting to call the project “done” once you’ve completed your specifications and built a prototype, and maybe even published a formal proof of your design, but you should first collect data on every important metric:
How easy is it to use your solution?
How hard is it to misuse your solution?
How easy is it to attack your solution? Which attackers have the highest advantage?
How stable is your solution?
How performant is your solution? Are the slow pieces the deliberate result of a trade-off? How do you know the balance was struck corectly?
Where We Stand Today
I’ve only begun writing my proposal, and I don’t expect it to be truly ready for cryptographers or security experts to review until early 2023.
However, my clearly specified tenets and anti-tenets were already useful in discussing my proposal on the Fediverse.
@soatok @fasterthanlime Should probably embed the algo used for encryption in the data used for storing the encrypted blob, to support multiples and future changes.
The direction Twitter appears to be heading with their E2EE work, and why I think it’s a flawed approach
Designing E2EE requires a great deal of time, care, and expertise; getting to market quicker at the expense of a clear and careful design is almost never the right call
Mastodon? ActivityPub? Fediverse? OMGWTFBBQ!
In case anyone is confused about Mastodon vs ActivityPub vs Fediverse lingo:
The end goal of my proposal is that I want to be able to send DMs to queer furries that use Mastodon such that only my recipient can read them.
Achieving this end goal almost exclusively requires building for ActivityPub broadly, not Mastodon specifically.
However, I only want to be responsible for delivering this design into the software I use, not for every single possible platform that uses ActivityPub, nor all the programming languages they’re written in.
I am going to be aggressive about preventing scope creep, since I’m doing all this work for free. (I do have a Ko-Fi, but I won’t link to it from here. Send your donations to the people managing the Mastodon instance that hosts your account instead.)
My hope is that the design documents and technical specifications become clear enough that anyone can securely implement end-to-end encryption for the Fediverse–even if special attention needs to be given to the language-specific cryptographic libraries that you end up using.
This sort of question comes up inevitably, so I’d like to tackle it preemptively.
My answer to every question that begins with, “Why should I trust you” is the same: You shouldn’t.
There are certainly cryptography and cybersecurity experts that you will trust more than me. Ask them for their expert opinions of what I’m designing instead of blanketly trusting someone you don’t know.
I’m not interested in revealing my legal name, or my background with cryptography and computer security. Credentials shouldn’t matter here.
If my design is good, you should be able to trust it because it’s good, not because of who wrote it.
If my design is bad, then you should trust whoever proposes a better design instead. Part of why I’m developing it in the open is so that it may be forked by smarter engineers.
Knowing who I am, or what I’ve worked on before, shouldn’t enter your trust calculus at all. I’m a gay furry that works in the technology industry and this is what I’m proposing. Take it or leave it.
The answer is simple: I do not trust Megolm, the protocol designed for Matrix.
Megolm has benefited from amateur review for four years. Non-cryptographers will confuse this observation with the proposition that Matrix has benefited from peer review for four years. Those are two different propositions.
In fact, the first time someone with cryptography expertise bothered to look at Matrix for more than a glance, they found critical vulnerabilities in its design. These are the kinds of vulnerabilities that are not easily mitigated, and should be kept in mind when designing a new protocol.
So they kind of, after we disclosed to them, they shared with us their timeline. It’s not fixed yet. It’s a, it’s a bigger change because they need to change the protocol. But they always said like, Okay, fair enough, they’re gonna change it. And they also kind of announced a few days after kind of the public disclosure based on the public reaction that they should prioritize fixing that. So it seems kind of in the near future, I don’t have the timeline in front of me right now. They’re going to fix that in the sense of like the— because there’s, notions of admins and so on. So like, um, so authenticating such group membership requests is not something that is kind of completely outside of, kind of like the spec. They just kind of need to implement the appropriate authentication and cryptography.
Martin Albrecht, SCW podcast
From one of the podcast hosts:
I guess we can at the very least tell anyone who’s going forward going to try that, that like, yes indeed. You should have formal models and you should have proofs. And so there’s this, one of the reactions to kind of the kind of attacks that we presented and also to prior previous work where we kind of like broken some cryptographic protocols is then to say like, “Well crypto’s hard”, and “don’t roll your own crypto.” But in a way the thing is like, you know, we need some people to roll their own crypto because that’s how we have crypto. Someone needs to roll it. But we have developed techniques, we have developed formalisms, we have developed methods for making sure it doesn’t have to be hard, it’s not, it’s not a dark art kind of that only kind of a few, a select few can master, but it’s, you know, it’s a science and you can learn it. So, but you need to then indeed employ a cryptographer in kind of like forming, modeling your protocol and whenever you make changes, then, you know, they need to look over this and say like, Yes, my proof still goes through. Um, so like that is how you do this. And then, then true engineering is still hard and it will remain hard and you know, any science is hard, but then at least you have some confidence in what you’re doing. You might still then kind of on the space and say like, you know, the attack surface is too large and I’m not gonna to have an encrypted backup. Right. That’s then the problem of a different hard science, social science. Right. But then just use the techniques that we have, the methods that we have to establish what we need.
Thomas Ptacek, SCW podcast
It’s tempting to listen to these experts and say, “OK, you should use libsignal instead.”
But libsignal isn’t designed for federation and didn’t prioritize group messaging. The UX for Signal is like an IM application between two parties. It’s a replacement for SMS.
It’s tempting to say, “Okay, but you should use MLS then; never roll your own,” but MLS doesn’t answer the group membership issue that plagued Matrix. It punts on these implementation details.
Even if I use an incumbent protocol that privacy nerds think is good, I’ll still have to stitch it together in a novel manner. There is no getting around this.
Maybe wait until I’ve finished writing the specifications for my proposal before telling me I shouldn’t propose anything.
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:
Secret key management. (This is sketched out already, and provides multiple mechanisms for managing secret key material. Yay!)
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.)
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.
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).
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:
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.
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.
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:
[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)
[strong]RevokeKey[/strong] — marks an existing public key as revoked
[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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
Also known as the right to erasure, the GDPR gives individuals the right to ask organizations to delete their personal data. But organizations don’t always have to do it....
Millionen von Standortdaten aus Apps fließen an Datenhändler ab - das zeigen Recherchen des BR mit internationalen Partnermedien. In Deutschland sticht eine populäre Wetter-App besonders hervor. Experten sprechen von "Kontrollverlust".
Imagine you’re a software developer, and you need to authenticate users based on a username and password.
If you’re well-read on the industry standard best practices, you’ll probably elect to use something like bcrypt, scrypt, Argon2id, or PBKDF2. (If you thought to use something else, you’re almost certainly doing it wrong.)
Let’s say, due to technical constraints, that you’re forced to select PBKDF2 out of the above options, but you’re able to use a suitable hash function (i.e. SHA-256 or SHA-512, instead of SHA-1).
Every password is hashed with a unique 256-bit salt, generated from a secure random generator, and has an iteration count in excess of 80,000 (for SHA-512) or 100,000 (for SHA-256). So far, so good.
(Art by
... mehr anzeigen
The Subtle Hazards of Real-World Cryptography
Imagine you’re a software developer, and you need to authenticate users based on a username and password.
If you’re well-read on the industry standard best practices, you’ll probably elect to use something like bcrypt, scrypt, Argon2id, or PBKDF2. (If you thought to use something else, you’re almost certainly doing it wrong.)
Let’s say, due to technical constraints, that you’re forced to select PBKDF2 out of the above options, but you’re able to use a suitable hash function (i.e. SHA-256 or SHA-512, instead of SHA-1).
Every password is hashed with a unique 256-bit salt, generated from a secure random generator, and has an iteration count in excess of 80,000 (for SHA-512) or 100,000 (for SHA-256). So far, so good.
Let’s also say your users’ passwords are long, randomly-generated strings. This can mean either you’re building a community of password manager aficionados, or your users are actually software bots with API keys.
Every user’s password is, therefore, always a 256 character string of random hexadecimal characters.
Two sprints before your big launch, your boss calls you and says, “Due to arcane legal compliance reasons, we need to be able to detect duplicate passwords. It needs to be fast.”
You might might think, “That sounds like a hard problem to solve.”
Your boss insists, “The passwords are all too long and too high-entropy to reliably attacked, even when we’re using a fast hash, so we should be able to get by with a simple hash function for deduplication purposes.”
So you change your code to look like this:
<?phpuse ParagonIE\EasyDB\EasyDB;use MyApp\Security\PasswordHash;class Authentication { private EasyDB $db; public function __construct(EasyDB $db) { $this->db = $db; $this->pwhash = new PasswordHash('sha256'); } public function signUp(string $username, string $password) { // New: $hashed = hash('sha256', $password); if ($db->exists( "SELECT count(id) FROM users WHERE pw_dedupe = ?", $hashed )) { throw new Exception( "You cannot use the same username or password as another user." ); } // Original: if ($db->exists( "SELECT count(id) FROM users WHERE username = ?", $username )) { throw new Exception( "You cannot use the same username or password as another user." ); } $this->db->insert('users', [ 'username' => $username, 'pwhash' => $this->pwhash->hash($password), // Also new: 'pw_dedupe' => $hashed ]); } public function logIn(string $username, string $password): int { // This is unchanged: $user = $this->db->row("SELECT * FROM users WHERE username = ?", $username); if (empty($user)) { throw new Exception("Security Error: No user"); } if ($this->pwhash->verify($password, $user['pwhash'])) { throw new Exception("Security Error: Incorrect password"); } return (int) $user['id']; }}
Surely, this won’t completely undermine the security of the password hashing algorithm?
Is this a face that would mislead you? (Art by Khia.)
Three years later, a bored hacker discovers a read-only SQL injection vulnerability, and is immediately able to impersonate any user in your application.
In order to understand what went wrong in our hypothetical scenario, you have to kinda know what’s under the hood in the monstrosity that our hypothetical developer slapped together.
PBKDF2
PBKDF2 stands for Password-Based Key Derivation Function #2. If you’re wondering where PBKDF1 went, I discussed its vulnerability in another blog post about the fun we can have with hash functions.
PBKDF2 is supposed to be instantiated with some kind of pseudo-random function, but it’s almost always HMAC with some hash function (SHA-1, SHA-256, and SHA-512 are common).
So let’s take a look at HMAC.
HMAC
HMAC is a Message Authentication Code algorithm based on Hash functions. Its definition looks like this:
For the purposes of this discussion, we only care about the definition of K’.
If your key (K) is larger than the block size of the hash function, it gets pre-hashed with that hash function. If it’s less than or equal to the block size of the hash function, it doesn’t.
So, what is PBKDF2 doing with K?
How PBKDF2 Uses HMAC
The RFCs that define PBKDF2 aren’t super helpful here, but one needs only look at a reference implementation to see what’s happening.
If you aren’t fluent in PHP, it’s using the previous round’s output as the message (m in the HMAC definition) and the password as the key (K).
Which means if your password is larger than the block size of the hash function used by HMAC (which is used by PBKDF2 under the hood), it will be pre-hashed.
The Dumbest Exploit Code
Okay, with all of that in mind, here’s how you can bypass the authentication of the above login script.
Since K’ = H(K) when Length(K) > BlockSize(H), you can just take the pre-calculated hash of the user’s password and use that as the password (although not hex-encoded), and it will validate. (Demo.)
This is probably how you feel right now, if you didn’t already know about this. (Art by Khia.)
Above, when HMAC defined K’, it included a variant in its definition. Adding variants to hash function is a dumb way to introduce the risk of collisions. (See also: Trivial Collisions in IOTA’s Kerl hash function.)
Here are a few ways the hypothetical developer could have narrowly avoided this security risk:
Use a different hash function for PBKDF2 and the deduplication check.
e.g. PBKDF2-SHA256 and SHA512 would be impervious
Always pre-hashing the password before passing it to PBKDF2.
Our exploit attempt will effectively be double-hashed, and will not succeed.
Use HMAC instead of a bare hash for the deduplication. With a hard-coded, constant key.
Prefix the password with a distinct domain separation constant in each usage.
Truncate the hash function, treating it as a Bloom filter.
Some or all of the above.
Push back on implementing this stupid feature to begin with.
Subtle problems often (but not always) call for subtle solutions.
Password Security Advice, Revisited
One dumb mitigation technique I didn’t include above is, “Using passwords shorter than the block size of the hash function.” The information security industry almost unanimously agrees that longer passwords are better than short ones (assuming both have the same distribution of possible characters at each position in the string, and are chosen randomly).
But here, we have a clear-cut example where having a longer password actually decreased security by allowing a trivial authentication bypass. Passwords with a length less than or equal to the block size of the hash function would not be vulnerable to the attack.
For reference, if you ever wanted to implement this control (assuming ASCII characters, where 1 character = 1 byte):
64-character passwords would be the upper limit for MD5, SHA-1, SHA-224, and SHA-256.
128-character passwords would be the upper limit for SHA-384 and SHA-512.
(Since the above example used 256-character passwords, it always overflows.)
But really, one of the other mitigation techniques would be better. Limiting the input length is just a band-aid.
Another Non-Obvious Footgun
Converse to the block size of the hash function, the output size of the hash function also affects the security of PBKDF2, because each output is calculated sequentially. If you request more bytes out of a PBKDF2 function than the hash function outputs, it will have to work at least twice as hard.
This means that, while a legitimate user has to calculate the entire byte stream from PBKDF2, an attacker can just target the first N bytes (20 for SHA-1, 32 for SHA-256, 64 for SHA-512) of the raw hash output and attack that instead of doing all the work.
Is Cryptography Hard?
I’ve fielded a lot of questions in the past few weeks, and consequently overheard commentary from folks insisting that cryptography is a hard discipline and therefore only the smartest should study it. I disagree with that, but not for the reason that most will expect.
Many of the people reading this page will tell me, “This is such a dumb and obvious design flaw. Nobody would ship that code in production,” because they’re clever or informed enough to avoid disaster.
Real-world cryptographic work is cognitively demanding. It becomes increasingly mathematically intensive the deeper you study, and nobody knows how to name things that non-cryptographers can understand. (Does anyone intuitively understand what a public key is outside of our field?)
In my opinion, cryptography is certainly challenging and widely misunderstood. There are a lot of subtle ways for secure building blocks to be stitched together insecurely. And today, it’s certainly a hard subject for most people to learn.
However, I don’t think its hardness is unavoidable.
Descending the Mohs Scale
There is a lot of gatekeeping in the information security community. (Maybe we should expect that to happen when people spend too many hours staring at firewall rules?)
“Don’t roll your own crypto” is something you hear a lot more often from software engineers and network security professionals than bona fide cryptographers.
From what I’ve seen, far too many people feel discouraged from learning about cryptography, thinking they aren’t smart enough for it. It would seem A Mathematician’s Lament has an echo.
If it can be said that cryptography is hard today, then that has more to do with incomplete documentation and substandard education resources available for free online than some inherent mystical quality of our discipline that only the christened few can ever hope to master.
Cryptographers and security engineers that work in cryptography need more developers to play in our sandbox. We need more usability experts to discuss improvements to our designs and protocols to make them harder to misuse. We also need science communication experts and a legal strategy to stop idiotic politicians from trying to foolishly ban encryption.
So if you’re reading my blog, wondering, “Will I ever be smart enough to understand this crap?” the answer is probably “Yes!” It might not be easy, but with any luck, it’ll be easier than it was for the forerunners in our field.
If a random furry can grok these topics, what’s stopping you? This dhole believes in you. (Art by Khia.)
I have one request, though: If you’re thinking of learning cryptography, please blog about your journey (even if you’re not a furry). You may end up filling in a pothole that would otherwise have tripped someone else up.
Despite the awesomeness and diversity that the furry fandom offers the world, there is a very narrow subset of furry content creation that has attained popular appeal within our community. If you w…
There are several different methods for securely hashing a password server-side for storage and future authentication. The most common one (a.k.a. the one that FIPS allows you to use, if compliance matters for you) is called PBKDF2. It stands for Password-Based Key Derivation Function #2.
Why #2? It’s got nothing to do with pencils. There was, in fact, a PBKDF1! But PBKDF1 was fatally insecure in a way I find very interesting. This StackOverflow answer is a great explainer on the difference between the two.
Very Hand-Wavy Description of a Hash Function
Let’s defined a hash function as any one-way transformation of some arbitrary-length string () to a fixed-length, deterministic, pseudo-random output.
Note: When in doubt, I err on the side of being easily understood by non-experts over pedantic precision. (Art by Swizz)
For example, this is a dumb hash function (uses SipHash-2-4 with a constant key):
function dumb_hash(string $arbitrary, bool $raw_binary = false): string{ $h = sodium_crypto_shorthash($arbitrary, 'SoatokDreamseekr'); if ($raw_binary) { return $h; } return sodium_bin2hex($h);}
You can see the output of this function with some sample inputs here.
Properties of Hash Functions
A hash function is considered secure if it has the following properties:
Pre-image resistance. Given , it should be difficult to find .
Second pre-image resistance. Given , it should be difficult to find such that
Collision resistance. It should be difficult to find any arbitrary pair of messages () such that
That last property, collision resistance, is guaranteed up to the Birthday Bound of the hash function. For a hash function with a 256-bit output, you will expect to need on average trial messages to find a collision.
If you’re confused about the difference between collision resistance and second pre-image resistance:
Collision resistance is about finding any two messages that produce the same hash, but you don’t care what the hash is as long as two distinct but known messages produce it.
On the other paw, second pre-image resistance is about finding a second message that produces a given hash.
Exploring PBKDF1’s Insecurity
If you recall, hash functions map an arbitrary-length string to a fixed-length string. If your input size is larger than your output size, collisions are inevitable (albeit computationally infeasible for hash functions such as SHA-256).
But what if your input size is equal to your output size, because you’re taking the output of a hash function and feeding it directly back into the same hash function?
Then, as explained here, you get an depletion of the possible outputs with each successive iteration.
But what does that look like?
Without running the experiments on a given hash function, there are two possibilities that come to mind:
Convergence. This is when will, for two arbitrary messages and a sufficient number of iterations, converge on a single hash output.
Cycles. This is when for some integer .
The most interesting result would be a quine, which is a cycle where (that is to say, ).
The least interesting result would be for random inputs to converge into large cycles e.g. cycles of size for a 256-bit hash function.
I calculated this lazily as the birthday bound of the birthday bound (so basically the 4th root, which for is ).
Update: According to this 1960 paper, the average time to cycle is , and cycle length should be , which means for a 256-bit hash you should expect a cycle after about or about 128 bits, and the average cycle length will be about . Thanks Riastradh for the corrections.
Conjecture: I would expect secure cryptographic hash functions in use today (e.g. SHA-256) to lean towards the least interesting output.
An Experiment Design
Since I don’t have an immense amount of cheap cloud computing at my disposal to run this experiments on a real hash function, I’m going to cheat a little and use my constant-key SipHash code from earlier in this post. In future work, cryptographers may find studying real hash functions (e.g. SHA-256) worthwhile.
Given that SipHash is a keyed pseudo-random function with an output size of 64 bits, my dumb hash function can be treated as a 64-bit hash function.
This means that you should expect your first collision (with 50% probability) after only trial hashes. This is cheap enough to try on a typical laptop.
Here’s a simple experiment for convergence:
Generate two random strings .
Set .
Iterate until .
You can get the source code to run this trivial experiment here.
Clone the git repository, run composer install, and then php bin/experiment.php. Note that this may need to run for a very long time before you get a result.
If you get a result, you’ve found a convergence.
If the loop doesn’t terminate even after 2^64 iterations, you’ve definitely found a cycle. (Actually detecting a cycle and analyzing its length would require a lot of memory, and my simple PHP script isn’t suitable for this effort.)
“What do you mean I don’t have a petabyte of RAM at my disposal?”
What Does This Actually Tell Us?
The obvious lesson: Don’t design key derivation functions like PBKDF1.
But beyond that, unless you can find a hash function that reliably converges or produces short cycles (, for an n-bit hash function), not much. (This is just for fun, after all!)
Definitely fun to think about though! (Art by circuitslime)
If, however, a hash function is discovered to produce interesting results, this may indicate that the chosen hash function’s internal design is exploitable in some subtle ways that, upon further study, may lead to better cryptanalysis techniques. Especially if a hash quine is discovered.
NIST opened public comments on SP 800-108 Rev. 1 (the NIST recommendations for Key Derivation Functions) last month. The main thing that’s changed from the original document published in 2009 is the inclusion of the Keccak-based KMAC alongside the incumbent algorithms.
One of the recommendations of SP 800-108 is called “KDF in Counter Mode”. A related document, SP 800-56C, suggests using a specific algorithm called HKDF instead of the generic Counter Mode construction from SP 800-108–even though they both accomplish the same goal.
Isn’t standards compliance fun?
Interestingly, HKDF isn
... mehr anzeigen
Understanding HKDF
NIST opened public comments on SP 800-108 Rev. 1 (the NIST recommendations for Key Derivation Functions) last month. The main thing that’s changed from the original document published in 2009 is the inclusion of the Keccak-based KMAC alongside the incumbent algorithms.
One of the recommendations of SP 800-108 is called “KDF in Counter Mode”. A related document, SP 800-56C, suggests using a specific algorithm called HKDF instead of the generic Counter Mode construction from SP 800-108–even though they both accomplish the same goal.
Isn’t standards compliance fun?
Interestingly, HKDF isn’t just an inconsistently NIST-recommended KDF, it’s also a common building block in a software developer’s toolkit which sees a lot of use in different protocols.
Unfortunately, the way HKDF is widely used is actually incorrect given its formal security definition. I’ll explain what I mean in a moment.
To first understand what HKDF is, you first need to know about HMAC.
HMAC is a standard message authentication code (MAC) algorithm built with cryptographic hash functions (that’s the H). HMAC is specified in RFC 2104 (yes, it’s that old).
HKDF is a key-derivation function that uses HMAC under-the-hood. HKDF is commonly used in encryption tools (Signal, age). HKDF is specified in RFC 5869.
HKDF is used to derive a uniformly-random secret key, typically for use with symmetric cryptography algorithms. In any situation where a key might need to be derived, you might see HKDF being used. (Although, there may be better algorithms.)
If you’re a software developer working with cryptography, you’ve probably seen an API in the crypto module for your programming language that looks like this, or maybe this.
Software developers that work with cryptography will typically think of the HKDF parameters like so:
$algo — which hash function to use
$key — the input key, from which multiple keys can be derived
$length — how many bytes to derive
$info — some arbitrary string used to bind a derived key to an intended context
$salt — some additional randomness (optional)
The most common use-case of HKDF is to implement key-splitting, where a single input key (the Initial Keying Material, or IKM) is used to derive two or more independent keys, so that you’re never using a single key for multiple algorithms.
See also: [url=https://github.com/defuse/php-encryption]defuse/php-encryption[/url], a popular PHP encryption library that does exactly what I just described.
At a super high level, the HKDF usage I’m describing looks like this:
class MyEncryptor {protected function splitKeys(CryptographyKey $key, string $salt): array { $encryptKey = new CryptographyKey(hash_hkdf( 'sha256', $key->getRawBytes(), 32, 'encryption', $salt )); $authKey = new CryptographyKey(hash_hkdf( 'sha256', $key->getRawBytes(), 32, 'message authentication', $salt )); return [$encryptKey, $authKey];}public function encryptString(string $plaintext, CryptographyKey $key): string{ $salt = random_bytes(32); [$encryptKey, $hmacKey] = $this->splitKeys($key, $salt); // ... encryption logic here ... return base64_encode($salt . $ciphertext . $mac);}public function decryptString(string $encrypted, CryptographyKey $key): string{ $decoded = base64_decode($encrypted); $salt = mb_substr($decoded, 0, 32, '8bit'); [$encryptKey, $hmacKey] = $this->splitKeys($key, $salt); // ... decryption logic here ... return $plaintext;}// ... other method here ...}
Unfortunately, anyone who ever does something like this just violated one of the core assumptions of the HKDF security definition and no longer gets to claim “KDF security” for their construction. Instead, your protocol merely gets to claim “PRF security”.
A random oracle is described by the following model:
There is a black box. In the box lives a gnome, with a big book and some dice.
We can input some data into the box (an arbitrary sequence of bits).
Given some input that he did not see beforehand, the gnome uses his dice to generate a new output, uniformly and randomly, in some conventional space (the space of oracle outputs). The gnome also writes down the input and the newly generated output in his book.
If given an already seen input, the gnome uses his book to recover the output he returned the last time, and returns it again.
So a random oracle is like a kind of hash function, such that we know nothing about the output we could get for a given input message m. This is a useful tool for security proofs because they allow to express the attack effort in terms of number of invocations to the oracle.
The problem with random oracles is that it turns out to be very difficult to build a really “random” oracle. First, there is no proof that a random oracle can really exist without using a gnome. Then, we can look at what we have as candidates: hash functions. A secure hash function is meant to be resilient to collisions, preimages and second preimages. These properties do not imply that the function is a random oracle.
Thomas Pornin
Alternatively, Wikipedia has a more formal definition available to the academic-inclined.
Thus, as long as your HMAC key is a secret, the output of HMAC can be generally treated as a PRF for all practical purposes. Your main security consideration (besides key management) is the collision risk if you truncate its output.
A key derivation function (KDF) is exactly what it says on the label: a cryptographic algorithm that derives one or more cryptographic keys from a secret input (which may be another cryptography key, a group element from a Diffie-Hellman key exchange, or a human-memorable password).
Note that passwords should be used with a Password-Based Key Derivation Function, such as scrypt or Argon2id, not HKDF.
Despite what you may read online, KDFs do not need to be built upon cryptographic hash functions, specifically; but in practice, they often are.
A notable counter-example to this hash function assumption: CMAC in Counter Mode (from NIST SP 800-108) uses AES-CMAC, which is a variable-length input variant of CBC-MAC. CBC-MAC uses a block cipher, not a hash function.
Regardless of the construction, KDFs use a PRF under the hood, and the output of a KDF is supposed to be a uniformly random bit string.
The security definition for a KDF has more relaxed requirements than PRFs: PRFs require the secret key be uniformly random. KDFs do not have this requirement.
If you use a KDF with a non-uniformly random IKM, you probably need the KDF security definition.
If your IKM is already uniformly random (i.e. the “key separation” use case), you can get by with just a PRF security definition.
After all, the entire point of KDFs is to allow a congruent security level as you’d get from uniformly random secret keys, without also requiring them.
However, if you’re building a protocol with a security requirement satisfied by a KDF, but you actually implemented a PRF (i.e., not a KDF), this is a security vulnerability in your cryptographic design.
HKDF is an HMAC-based KDF. Its algorithm consists of two distinct steps:
HKDF-Extract uses the Initial Keying Material (IKM) and Salt to produce a Pseudo-Random Key (PRK).
HKDF-Expand actually derives the keys using PRK, the info parameter, and a counter (from 0 to 255) for each hash function output needed to generate the desired output length.
The HKDF paper, written by Hugo Krawczyk, contains the following definition (page 7).
The paper goes on to discuss the requirements for authenticating the salt over the communication channel, lest the attacker have the ability to influence it.
A subtle detail of this definition is that the security definition says that A salt value, not Multiple salt values.
Which means: You’re not supposed to use HKDF with a constant IKM, info label, etc. but vary the salt for multiple invocations. The salt must either be a fixed random value, or NULL.
We stress, however, that the use of salt adds significantly to the strength of HKDF, ensuring independence between different uses of the hash function, supporting “source-independent” extraction, and strengthening the analytical results that back the HKDF design.
Random salt differs fundamentally from the initial keying material in two ways: it is non-secret and can be re-used. As such, salt values are available to many applications. For example, a pseudorandom number generator (PRNG) that continuously produces outputs by applying HKDF to renewable pools of entropy (e.g., sampled system events) can fix a salt value and use it for multiple applications of HKDF without having to protect the secrecy of the salt. In a different application domain, a key agreement protocol deriving cryptographic keys from a Diffie-Hellman exchange can derive a salt value from public nonces exchanged and authenticated between communicating parties as part of the key agreement (this is the approach taken in [IKEv2]).
RFC 5869, section 3.1
Okay, sure. Random salts are better than a NULL salt. And while this section alludes to “[fixing] a salt value” to “use it for multiple applications of HKDF without having to protect the secrecy of the salt”, it never explicitly states this requirement. Thus, the poor implementor is left to figure this out on their own.
Thus, because it’s not using HKDF in accordance with its security definition, many implementations (such as the PHP encryption library we’ve been studying) do not get to claim that their construction has KDF security.
Instead, they only get to claim “Strong PRF” security, which you can get from just using HMAC.
Recall that the HKDF algorithm uses salts in the HDKF-Extract step. Salts in this context were intended for deriving keys from a Diffie-Hellman output, or a human-memorable password.
In the case of [Elliptic Curve] Diffie-Hellman outputs, the result of the key exchange algorithm is a random group element, but not necessarily uniformly random bit string. There’s some structure to the output of these functions. This is why you always, at minimum, apply a cryptographic hash function to the output of [EC]DH before using it as a symmetric key.
HKDF uses salts as a mechanism to improve the quality of randomness when working with group elements and passwords.
Extending the nonce for a symmetric-key AEAD mode is a good idea, but using HKDF’s salt parameter specifically to accomplish this is a misuse of its intended function, and produces a weaker argument for your protocol’s security than would otherwise be possible.
It may seem weird, and defy intuition, but the correct way to introduce randomness into HKDF as most developers interact with the algorithm is to skip the salt parameter entirely (either fixing it to a specific value for domain-separation or leaving it NULL), and instead concatenate data into the info parameter.
Another advantage: This also lets you optimize your HKDF calls by caching the PRK from the HKDF-Extract step and reuse it for multiple invocations of HKDF-Expand with a distinct info. This allows you to reduce the number of hash function invocations from to (since each HMAC involves two hash function invocations).
If it matters, your cryptographer will tell you it matters–which probably means they have a security proof that assumes the KDF security definition for a very good reason, and you’re not allowed to violate that assumption.
Otherwise, probably not. Strong PRF security is still pretty damn good for most threat models.
If your takeaway was, “Wow, I feel stupid,” don’t, because you’re in good company.
I’ve encountered several designs in my professional life that shoved the randomness into the info parameter, and it perplexed me because there was a perfectly good salt parameter right there. It turned out, I was wrong to believe that, for all of the subtle and previously poorly documented reasons discussed above. But now we both know, and we’re all better off for it.
So don’t feel dumb for not knowing. I didn’t either, until this was pointed out to me by a very patient colleague.
“Feeling like you were stupid” just means you learned. (Art: LvJ)
Also, someone should really get NIST to be consistent about whether you should use HKDF or “KDF in Counter Mode with HMAC” as a PRF, because SP 800-108’s new revision doesn’t concede this point at all (presumably a relic from the 2009 draft).
This concession was made separately in 2011 with SP 800-56C revision 1 (presumably in response to criticism from the 2010 HKDF paper), and the present inconsistency is somewhat vexing.
(On that note, does anyone actually use the NIST 800-108 KDFs instead of HKDF? If so, why? Please don’t say you need CMAC…)
Bonus Content
These questions were asked after this blog post initially went public, and I thought they were worth adding. If you ask a good question, it may end up being edited in at the end, too.
Why Does HKDF use the Salt as the HMAC key in the Extract Step? (via r/crypto)
Broadly speaking, when applying a PRF to two “keys”, you get to decide which one you treat as the “key” in the underlying API.
HMAC’s API is HMACalg(key, message), but how HKDF uses it might as well be HMACalg(key1, key2).
The difference here seems almost arbitrary, but there’s a catch.
HKDF was designed for Diffie-Hellman outputs (before ECDH was the norm), which are generally able to be much larger than the block size of the underlying hash function. 2048-bit DH results fit in 256 bytes, which is 4 times the SHA256 block size.
If you have to make a decision, using the longer input (DH output) as the message is more intuitive for analysis than using it as the key, due to pre-hashing. I’ve discussed the counter-intuitive nature of HMAC’s pre-hashing behavior at length in this post, if you’re interested.
So with ECDH, it literally doesn’t matter which one was used (unless you have a weird mismatch in hash functions and ECC groups; i.e. NIST P-521 with SHA-224).
But before the era of ECDH, it was important to use the salt as the HMAC key in the extract step, since they were necessarily smaller than a DH group element.
Thus, HKDF chose HMACalg(salt, IKM) instead of HMACalg(IKM, salt) for the calculation of PRK in the HKDF-Extract step.
Neil Madden also adds that the reverse would create a chicken-egg situation, but I personally suspect that the pre-hashing would be more harmful to the security analysis than merely supplying a non-uniformly random bit string as an HMAC key in this specific context.
My reason for believing this is, when a salt isn’t supplied, it defaults to a string of 0x00 bytes as long as the output size of the underlying hash function. If the uniform randomness of the salt mattered that much, this wouldn’t be a tolerable condition.
In spite of the central role of key derivation functions (KDF) in applied cryptography, there has been little formal work addressing the design and analysis of general multi-purpose KDFs.
As we look upon the sunset of a remarkably tiresome year, I thought it would be appropriate to talk about cryptographic wear-out.
What is cryptographic wear-out?
It’s the threshold when you’ve used the same key to encrypt so much data that you should probably switch to a new key before you encrypt any more. Otherwise, you might let someone capable of observing all your encrypted data perform interesting attacks that compromise the security of the data you’ve encrypted.
My definitions always aim to be more understandable than pedantically correct. (Art by Swizz)
The exact value of the threshold varies depending on how exactly you’re encrypting data (n.b. AEAD modes, block ciphers + cipher modes, etc. each have different wear-out thresholds due to their composition).
Let’s take a look at the wear-out limits of the more popular symmetric encryption methods, and calculate those limits ourselves.
Each block of data encrypted uses J0 + block counter (starting at 1) as a CTR nonce.
J0 is additionally used as the nonce to calculate the final GMAC tag.
AES-GCM is one of the algorithms where it’s easy to separately calculate the safety limits per message (i.e. for a given nonce and key), as well as for all messages under a key.
AES-GCM Single Message Length Limits
In the simplest case (nonce is 96 bits), you end up with the following nonces consumed:
For each key: 00000000 00000000 00000000 00000000
For each (nonce, key) pair:
NNNNNNNN NNNNNNNN NNNNNNNN 000000001 for J0
NNNNNNNN NNNNNNNN NNNNNNNN 000000002 for encrypting the first 16 bytes of plaintext
NNNNNNNN NNNNNNNN NNNNNNNN 000000003 for the next 16 bytes of plaintext…
…
NNNNNNNN NNNNNNNN NNNNNNNN FFFFFFFFF for the final 16 bytes of plaintext.
From here, it’s pretty easy to see that you can encrypt the blocks from 00000002 to FFFFFFFF without overflowing and creating a nonce reuse. This means that each (key, nonce) can be used to encrypt a single message up to blocks of the underlying ciphertext.
Since the block size of AES is 16 bytes, this means the maximum length of a single AES-GCM (key, nonce) pair is bytes (or 68,719,476,480 bytes). This is approximately 68 GB or 64 GiB.
Things get a bit tricker to analyze when the nonce is not 96 bits, since it’s hashed.
The disadvantage of this hashing behavior is that it’s possible for two different nonces to produce overlapping ranges of AES-CTR output, which makes the security analysis very difficult.
However, this hashed output is also hidden from network observers since they do not know the value of H. Without some method of reliably detecting when you have an overlapping range of hidden block counters, you can’t exploit this.
(If you want to live dangerously and motivate cryptanalysis research, mix 96-bit and non-96-bit nonces with the same key in a system that does something valuable.)
Multi-Message AES-GCM Key Wear-Out
Now that we’ve established the maximum length for a single message, how many messages you can safely encrypt under a given AES-GCM key depends entirely on how your nonce is selected.
If you have a reliable counter, which is guaranteed to never repeat, and start it at 0 you can theoretically encrypt messages safely. Hooray!
You probably don’t have a reliable counter, especially in real-world settings (distributed systems, multi-threaded applications, virtual machines that might be snapshotted and restored, etc.).
Confound you, technical limitations! (Art by Swizz)
Additionally (thanks to 2adic for the expedient correction), you cannot safely encrypt more than blocks with AES because the keystream blocks–as the output of a block cipher–cannot repeat.
Most systems that cannot guarantee unique incrementing nonces simply generate nonces with a cryptographically secure random number generator. This is a good idea, but no matter how high quality your random number generator is, random functions will produce collisions with a discrete probability.
If you have possible values, you should expect a single collision(with 50% probability) after (or )samples. This is called the birthday bound.
However, 50% of a nonce reuse isn’t exactly a comfortable safety threshold for most systems (especially since nonce reuse will cause AES-GCM to become vulnerable to active attackers). 1 in 4 billion is a much more comfortable safety margin against nonce reuse via collisions than 1 in 2. Fortunately, you can calculate the discrete probability of a birthday collision pretty easily.
If you want to rekey after your collision probability exceeds (for a random nonce between 0 and ), you simply need to re-key after messages.
AES-GCM Safety Limits
Maximum message length: bytes
Maximum number of messages (random nonce):
Maximum number of messages (sequential nonce): (but you probably don’t have this luxury in the real world)
Maximum data safely encrypted under a single key with a random nonce: about bytes
The IETF version of ChaCha20-Poly1305 uses 96-bit nonces and 32-bit internal counters. A similar analysis follows from AES-GCM’s, with a few notable exceptions.
For starters, the one-time Poly1305 key is derived from the first 32 bytes of the ChaCha20 keystream output (block 0) for a given (nonce, key) pair. There is no equivalent to AES-GCM’s H parameter which is static for each key. (The ChaCha20 encryption begins using block 1.)
Additionally, each block for ChaCha20 is 512 bits, unlike AES’s 128 bits. So the message limit here is a little more forgiving.
Since the block size is 512 bits (or 64 bytes), and only one block is consumed for Poly1305 key derivation, we can calculate a message length limit of , or 274,877,906,880 bytes–nearly 256 GiB for each (nonce, key) pair.
The same rules for handling 96-bit nonces applies as with AES-GCM, so we can carry that value forward.
ChaCha20-Poly1305 Safety Limits
Maximum message length: bytes
Maximum number of messages (random nonce):
Maximum number of messages (sequential nonce): (but you probably don’t have this luxury in the real world)
Maximum data safely encrypted under a single key with a random nonce: about bytes
A significant improvement, but still practically limited. (Art by Khia.)
Cryptographic Limits for XChaCha20-Poly1305
XChaCha20-Poly1305 is a variant of XSalsa20-Poly1305 (as used in libsodium) and the IETF’s ChaCha20-Poly1305 construction. It features 192-bit nonces and 32-bit internal counters.
XChaCha20-Poly1305 is instantiated by using HChaCha20 of the key over the first 128 bits of the nonce to produce a subkey, which is used with the remaining nonce bits using the aforementioned ChaCha20-Poly1305.
This doesn’t change the maximum message length, but it does change the number of messages you can safely encrypt (since you’re actually using up to distinct keys).
Thus, even if you manage to repeat the final ChaCha20-Poly1305 nonce, as long as the total nonce differs, each encryptions will be performed with a distinct key (thanks to the HChaCha20 key derivation; see the XSalsa20 paper and IETF RFC draft for details).
UPDATE (2021-04-15): It turns out, my read of the libsodium implementation was erroneous due to endian-ness. The maximum message length for XChaCha20-Poly1305 is blocks, and for AEAD_XChaCha20_Poly1305 is blocks. Each block is 64 bytes, so that changes the maximum message length to about . This doesn’t change the extended-nonce details, just the underlying ChaCha usage.
XChaCha20-Poly1305 Safety Limits
Maximum message length: bytes (earlier version of this document said )
Maximum number of messages (random nonce):
Maximum number of messages (sequential nonce): (but you probably don’t have this luxury in the real world)
Maximum data safely encrypted under a single key with a random nonce: about bytes
It’s tempting to compare non-AEAD constructions and block cipher modes such as CBC (Cipher Block Chaining), but they’re totally different monsters.
AEAD ciphers have a clean delineation between message length limit and the message quantity limit
CBC and other cipher modes do not have this separation
Every time you encrypt a block with AES-CBC, you are depleting from a universal bucket that affects the birthday bound security of encrypting more messages under that key. (And unlike AES-GCM with long nonces, AES-CBC’s IV is public.)
This is in addition to the operational requirements of AES-CBC (plaintext padding, initialization vectors that never repeat and must be unpredictable, separate message authentication since CBC doesn’t provide integrity and is vulnerable to chosen-ciphertext atacks, etc.).
My canned response to most queries about AES-CBC. (Art by Khia.)
For this reason, most cryptographers don’t even bother calculating the safety limit for AES-CBC in the same breath as discussing AES-GCM. And they’re right to do so!
However, for the sake of completeness, let’s figure out what our practical limits are.
CBC operates on entire blocks of plaintext, whether you need the entire block or not.
On encryption, the output of the previous block is mixed (using XOR) with the current block, then encrypted with the block cipher. For the first block, the IV is used in the place of a “previous” block. (Hence, its requirements to be non-repeating and unpredictable.)
This means you can informally model (IV xor PlaintextBlock) and (PBn xor PBn+1) as a pseudo-random function, before it’s encrypted with the block cipher.
If those words don’t mean anything to you, here’s the kicker: You can use the above discussion about birthday bounds to calculate the upper safety bounds for the total number of blocks encrypted under a single AES key (assuming IVs are generated from a secure random source).
If you’re okay with a 50% probability of a collision, you should re-key after blocks have been encrypted.
If your safety margin is closer to the 1 in 4 billion (as with AES-GCM), you want to rekey after blocks.
However, blocks encrypted doesn’t map neatly to bytes encrypted.
If your plaintext is always an even multiple of 128 bits (or 16 bytes), this allows for up to bytes of plaintext. If you’re using PKCS#7 padding, keep in mind that this will include an entire padding block per message, so your safety margin will deplete a bit faster (depending on how many individual messages you encrypt, and therefore how many padding blocks you need).
On the other extreme (1-byte plaintexts), you’ll only be able to eek encrypted bytes before you should re-key.
Therefore, to stay within the safety margin of AES-CBC, you SHOULD re-key after blocks (including padding) have been encrypted.
Keep in mind: single-byte blocks is still approximately 281 TiB of data (including padding). On the upper end, 15-byte blocks (with 1-byte padding to stay within a block) clocks in at about or about 4.22 PiB of data.
That’s Blocks. What About Bytes?
The actual plaintext byte limit sans padding is a bit fuzzy and context-dependent.
The local extrema occurs if your plaintext is always 16 bytes (and thus requires an extra 16 bytes of padding). Any less, and the padding fits within one block. Any more, and the data:padding ratio starts to dominate.
Therefore, the worst case scenario with padding is that you take the above safety limit for block counts, and cut it in half. Cutting a number in half means reducing the exponent by 1.
But this still doesn’t eliminate the variance. blocks could be anywhere from to bytes of real plaintext. When in situations like this, we have to assume the worst (n.b. take the most conservative value).
Therefore…
AES-CBC Safety Limits
Maximum data safely encrypted under a single key with a random nonce: bytes (approximately 141 TiB)
Yet another reason to dislike non-AEAD ciphers. (Art by Khia.)
Take-Away
Compared to AES-CBC, AES-GCM gives you approximately a million times as much usage out of the same key, for the same threat profile.
ChaCha20-Poly1305 and XChaCha20-Poly1305 provides even greater allowances of encrypting data under the same key. The latter is even safe to use to encrypt arbitrarily large volumes of data under a single key without having to worry about ever practically hitting the birthday bound.
I’m aware that this blog post could have simply been a comparison table and a few footnotes (or even an IETF RFC draft), but I thought it would be more fun to explain how these values are derived from the cipher constructions.
The eXtended-nonce ChaCha cipher construction (XChaCha) allows for ChaCha-based ciphersuites to accept a 192-bit nonce with similar guarantees to the original construction, except with a much lower probability of nonce misuse occurring.
Nor are we talking about what comes to mind for engineers accustomed to classical cryptography when you say Hybrid.
(Such engineers typically envision some combination of asymmetric key encapsulation with symmetric encryption; because too many people encrypt with RSA directly and the sane approach is often described as a Hybrid Cryptosystem in the literature.)
Rather, Hybrid Cryptography in today’s context refers to:
Cryptography systems that use a post-quantum cryptography algorithm, combined with one of the algorithms deployed today that aren’t resistant to quantum computers.
If you need to differentiate the two, PQ-Hybrid might be a better designation.
Why Hybrid Cryptosystems?
At some point in the future (years or decades from now), humanity may build a practical quantum computer. This will be a complete disaster for all of the cryptography deployed on the Internet today.
In response to this distant existential threat, cryptographers have been hard at work designing and attacking algorithms that remain secure even when quantum computers arrive. These algorithms are classified as post-quantum cryptography (mostly to distinguish it from techniques that uses quantum computers to facilitate cryptography rather than attack it, which is “quantum cryptography” and not really worth our time talking about). Post-quantum cryptography is often abbreviated as “PQ Crypto” or “PQC”.
However, a lot of the post-quantum cryptography designs are relatively new or comparatively less studied than their classical (pre-quantum) counterparts. Several of the Round 1 candidates to NIST’s post quantum cryptography project were broken immediately (PDF). Exploit code referenced in PDF duplicated below.:
#!/usr/bin/env python3import binascii, structdef recover_bit(ct, bit): assert bit < len(ct) // 4000 ts = [struct.unpack('BB', ct[i:i+2]) for i in range(4000*bit, 4000*(bit+1), 2)] xs, ys = [a for a, b in ts if b == 1], [a for a, b in ts if b == 2] return sum(xs) / len(xs) >= sum(ys) / len(ys)def decrypt(ct): res = sum(recover_bit(ct, b) << b for b in range(len(ct) // 4000)) return int.to_bytes(res, len(ct) // 4000 // 8, 'little')kat = 0for l in open('KAT_GuessAgain/GuessAgainEncryptKAT_2000.rsp'): if l.startswith('msg = '): # only used for verifying the recovered plaintext. msg = binascii.unhexlify(l[len('msg = '):].strip()) elif l.startswith('c = '): ct = binascii.unhexlify(l[len('c = '):].strip()) print('{}attacking known-answer test #{}'.format('\n' * (kat > 0), kat)) print('correct plaintext: {}'.format(binascii.hexlify(msg).decode())) plain = decrypt(ct) print('recovered plaintext: {} ({})'.format(binascii.hexlify(plain).decode(), plain == msg)) kat += 1
More pertinent to our discussions: Rainbow, which was one of the Round 3 Finalists for post-quantum digital signature algorithms, was discovered in 2020 to be much easier to attack than previously thought. Specifically, for the third round parameters, the attack cost was reduced by a factor of , , and .
That security reduction is just a tad bit more concerning than a Round 1 candidate being totally broken, since NIST had concluded by then that Rainbow was a good signature algorithm until that attack was discovered. Maybe there are similar attacks just waiting to be found?
Given that new cryptography is accompanied by less confidence than incumbent cryptography, hybrid designs are an excellent way to mitigate the risk of attack advancements in post-quantum cryptography:
If the security of your system requires breaking the cryptography used today AND breaking one of the new-fangled designs, you’ll always be at least as secure as the stronger algorithm.
Another pushback on hybrid cryptography comes from Uri Blumenthal of MIT’s Lincoln Labs on the IETF CFRG mailing list (the acronym CRQC expands to “Cryptographically-Relevant Quantum Computer”):
Here are the possibilities and their relation to the usefulness of the Hybrid approach.
1. CRQC arrived, Classic hold against classic attacks, PQ algorithms hold – Hybrid is useless.
2. CRQC arrived, Classic hold against classic attacks, PQ algorithms fail – Hybrid is useless.
3. CRQC arrived, Classic broken against classic attacks, PQ algorithms hold – Hybrid is useless.
4. CRQC arrived, Classic hold against classic attacks, PQ algorithms broken – Hybrid useless.
5. CRQC doesn’t arrive, Classic hold against classic attacks, PQ algorithms hold – Hybrid is useless.
6. CRQC doesn’t arrive, Classic hold against classic attacks, PQ algorithms broken – Hybrid helps.
7. CRQC doesn’t arrive, Classic broken against classic attacks, PQ algorithms hold – Hybrid is useless.
8. CRQC doesn’t arrive, Classic broken against classic attacks, PQ algorithms broken – Hybrid is useless.
Uri Blumenthal, IETF CFRG mailing list, December 2021 (link)
First, Uri’s framing sort of implies that each of the 8 possible outputs of these 3 boolean variables are relatively equally likely outcomes.
It’s very tempting to look at this and think, “Wow, that’s a lot of work for something that only helps in 12.5% of possible outcomes!” Uri didn’t explicitly state this assumption, and he might not even believe that, but it is a cognitive trap that emerges in the structure of his argument, so watch your step.
Second, for many candidate algorithms, we’re already in scenario 6 that Uri outlined! It’s not some hypothetical future, it’s the present state of affairs.
To wit: The advances in cryptanalysis on Rainbow don’t totally break it in a practical sense, but they do reduce the security by a devastating margin (which will require significantly larger parameter sets and performance penalties to remedy).
For many post-quantum algorithms, we’re still uncertain about which scenario is most relevant. But since PQ algorithms are being successfully attacked and a quantum computer still hasn’t arrived, and classical algorithms are still holding up fine, it’s very clear that “hybrid helps” is the world we most likely inhabit today, and likely will for many years (until the existence of quantum computers is finally settled).
Finally, even in other scenarios (which are more relevant for other post-quantum algorithms), hybrid doesn’t significantly hurt security. It does carry a minor cost to bandwidth and performance, and it does mean having a larger codebase to review when compared with jettisoning the algorithms we use today, but I’d argue that the existing code is relatively low risk compared to new code.
From what I’ve read, the NSA didn’t make as strong an argument as Uri; they said hybrid would not be required, but didn’t go so far as to attack it.
Hybrid cryptography is a long-term bet that will protect the most users from cryptanalytic advancements, contrasted with strictly-PQ and no-PQ approaches.
Why The Hybrid Controversy Remains Unsettled
Even if we can all agree that hybrid is the way to go, there’s still significant disagreement on exactly how to do it.
Hybrid KEMs
There are two schools of thought on hybrid Key Encapsulation Mechanisms (KEMs):
Wrap the post-quantum KEM in the encrypted channel created by the classical KEM.
Use both the post-quantum KEM and classical KEM as inputs to a secure KDF, then use a single encrypted channel secured by both.
The first option (layered) has the benefit of making migrations smoother. You can begin with classical cryptography (i.e. ECDHE for TLS ciphersuites), which is what most systems online support today. Then you can do your post-quantum cryptography inside the existing channel to create a post-quantum-secure channel. This also lends toward opportunistic upgrades (which might not be a good idea).
The second option (composite) has the benefit of making the security of your protocol all-or-nothing: You cannot attack the weak now and the strong part later. The session keys you’ll derive require attacking both algorithms in order to get access to the plaintext. Additionally, you only need a single layer. The complexity lies entirely within the handshake, instead of every packet.
Personally, I think composite is a better option for security than layered.
Hybrid Signatures
There are, additionally, two different schools of thought on hybrid digital signature algorithms. However, the difference is more subtle than with KEMs.
Require separate classical signatures and post-quantum signatures.
Specify a composite mode that combines the two together and treat it as a distinct algorithm.
To better illustrate what this looks like, I outlined what a composite hybrid digital signature algorithm could look like on the CFRG mailing list:
Your composite public key would be your Ed25519 public key, followed by your post-quantum public key. Since Ed25519 public keys are always 32 bytes, this is easy to implement securely.
Every composite signature would be an Ed25519 signature concatenated with the post-quantum signature. Since Ed25519 signatures are always 64 bytes, this leads to a predictable signature size relative to the post-quantum signature.
The main motivation for preferring a composite hybrid signature over a detached hybrid signature is to push the hybridization of cryptography lower in the stack so developers don’t have to think about these details. They just select HYBRIDSIG1 or HYBRIDSIG2 in their ciphersuite configuration, and cryptographers get to decide what that means.
TL;DR
Hybrid designs of post-quantum crypto are good, and I think composite hybrid designs make the most sense for both KEMs and signatures.
Creating a fursona is one of the most universal behaviours in the furry fandom. Defined as anthropomorphic animal representations of the self, furries interact with other members of the fandom through the use of these avatars, both in-person (e.g.
Let me state up front that, while we’re going to be talking about an open source project that was recently submitted to Hacker News’s “Show HN” section, the intent of this post is not at all to shame the developer who tried their damnedest to do the right thing. They’re the victim, not the culprit.
It is known that Facebook scans your messages. If you need to keep using Facebook messenger but care about privacy, Zuccnet might help.
It’s pretty simple: you and your friend have Zuccnet installed. Your friend gives you their Zuccnet public key. Then, when you send a message to your friend on Zuccnet, your message is encrypted on your machine before it is sent across Facebook to your friend. Then, your friend’s Zuccnet decrypts the message. Facebook never sees the content of your message.
I’m not a security person and there’s probably some stuff I’ve missed – any contributions are very welcome! This is verybeta, don’t take it too seriously.
From Zuccnet’s very humble README.
So far, so good. Facebook is abysmal for privacy, so trying to take matters into your own hands to encrypt data so Facebook can’t see what you’re talking about is, in spirit, a wonderful idea.
However, there is a problem with the execution of this idea. And this isn’t a problem unique to Zuccnet. Several times per year, I come across some well-meaning software project that makes the same mistake: Encrypting messages with RSA directly is bad.
To the Zuccnet author’s credit, they’re using OAEP padding, not PKCS#1 v1.5 padding. This means their code isn’t vulnerable to Bleichenbacher’s 1998 padding oracle attack (n.b. most of the RSA code I encounter in the wild is vulnerable to this attack).
However, there are other problems with this code:
If you try to encrypt a message longer than 256 bytes with a 2048-bit RSA public key, it will fail. (Bytes matter here, not characters, even for English speakers–because emoji.)
This design (encrypting with a static RSA public key per recipient) completely lacks forward secrecy. This is the same reason that PGP encryption sucks (or, at least, one of the reasons PGP sucks).
There are many ways to work around the first limitation.
Some cryptography libraries let you treat RSA as a block cipher in ECB mode and encrypt each chunk independently. This is an incredibly stupid API deign choice: It’s slow (asymmetric cryptography operations are on the order of tens-to-hundreds-of-thousands times slower than symmetric cryptography) and you can drop/reorder/replay blocks, since ECB mode provides no semantic security.
I have strong opinions about cryptographic library design. (Art by Swizz.)
A much better strategy is to encrypt the data with a symmetric key, then encrypt that key with RSA. (See the end of the post for special treatment options that are especially helpful for RSA with PKCS#1 v1.5 padding.)
Working around the second problem usually requires an Authenticated Key Exchange (AKE), similar to what I covered in my Guide to End-to-End Encryption. Working around this second problem also solves the first problem, so it’s usually better to just implement a forward-secret key exchange protocol than try to make RSA secure.
(You can get forward secrecy without an AKE, by regularly rotating keys, but AKEs make forward secrecy automatic and on-by-default without forcing humans to make a decision to rotate a credential– something most people don’t do unless they have to. AKEs trade user experience complexity for protocol complexity–and this trade-off is almost universally worth taking.)
Although AKEs are extremely useful, they’re a bit complex for most software developers to pick up without prior cryptography experience. (If they were easier, after all, there wouldn’t be so much software that encrypts messages directly with RSA in the first place.)
Note: RSA itself isn’t the reason that this lacks forward secrecy. The problem is how RSA is used.
Libsodium (which you should use) does most of this for you, and can easily be turned into an AKE comparable to the one Signal uses. The less cryptography code you have to write, the less can go catastrophically wrong–especially in production systems.
If jettisoning RSA from your designs is a non-starter, you should at least consider taking the Dhole Moments Pledge for Software Developers:
I will not encrypt messages directly with RSA, or any other asymmetric primitive.
Simple enough, right?
Instead, if you find yourself needing to encrypt a message with RSA, remind yourself that RSA is for encrypting symmetric keys, not messages. And then plan your protocol design accordingly.
Also, I’m pretty sure RSA isn’t random-key robust. Ask your favorite cryptographer if it matters for whatever you’re building.
(But seriously, you’re better off not using RSA at all.)
For Cryptography Libraries
Let’s ask ourselves, “Why are we forcing developers to know or even care about these details?”
Libsodium doesn’t encumber developers with unnecessary decisions like this. Why does the crypto module built into JavaScript? Why does the crypto module built into most programming languages that offer one, for that matter? (Go is a notable exception here, because their security team is awesome and forward-thinking.)
In my opinion, we should stop shipping cryptography interfaces that…
Mix symmetric and asymmetric cryptography in the same API
Allow developers to encrypt directly with asymmetric primitives
Force developers to manage their own nonces/initialization vectors
Allow public/private keys to easily get confused (e.g. lack of type safety)
For example: Dhole Crypto is close to my ideal for general-purpose encryption.
Addendum: Securing RSA with PKCS#1 v1.5
Update: Neil Madden informs me that what I wrote here is actually very similar to a standard construction called RSA-KEM. You should use RSA-KEM instead of what I’ve sketched out, since that’s better studied by cryptographers.
(I’ve removed the original sketch below, to prevent accidental misuse.)
Cryptography Interface Design is a Security Concern
Cryptographers and cryptography engineers love to talk about the latest attacks and how to mitigate them. LadderLeak breaks ECDSA with less than 1 bit of nonce leakage? Raccoon attack brings the Hidden Number attack to finite field Diffie-Hellman in TLS?
And while this sort of research is important and fun, most software developers have much bigger problems to contend with, when it comes to the cryptographic security of their products and services.
So let’s start by talking about Java cryptography.
Cryptography Interface Design is a Security Concern
Cryptographers and cryptography engineers love to talk about the latest attacks and how to mitigate them. LadderLeak breaks ECDSA with less than 1 bit of nonce leakage? Raccoon attack brings the Hidden Number attack to finite field Diffie-Hellman in TLS?
And while this sort of research is important and fun, most software developers have much bigger problems to contend with, when it comes to the cryptographic security of their products and services.
So let’s start by talking about Java cryptography.
In Java, the way you’re supposed to encrypt data using symmetric cryptography is with the javax.crypto.Cipher class. So to encrypt with AES-GCM, you’d call Cipher.getInstance("AES/GCM/NoPadding") and use the resulting object to process your data. javax.crypto.Cipher can be used for a lot of ill-advised modes (including ECB mode) and ciphers (including DES).
Can you guess what class you’d use to encrypt data with RSA in Java?
Fun anecdote: The naming of RSA/ECB/$padding is misleading because it doesn’t actually implement a sort of ECB mode. However, a few projects over the years missed that memo and decided to implement RSA-ECB so they could be “compatible” with what they thought Java did. That is: They broke long messages into equal sized chunks (237 bytes for 2048-bit RSA), encrypted them independently, and then concatenated the ciphertexts together.
GCMParameterSpec s = ...; cipher.init(..., s); // If the GCM parameters were generated by the provider, it can // be retrieved by: // cipher.getParameters().getParameterSpec(GCMParameterSpec.class); cipher.updateAAD(...); // AAD cipher.update(...); // Multi-part update cipher.doFinal(...); // conclusion of operation // Use a different IV value for every encryption byte[] newIv = ...; s = new GCMParameterSpec(s.getTLen(), newIv); cipher.init(..., s); ...
If you fail to perform this kata perfectly, you’ll introduce a nonce reuse vulnerability into your application.
Kludgey, hard-to-use, easy-to-misuse. It doesn’t have to be this way.
Learning From PHP
In 2015, when PHP 7 was being discussed on their mailing list, someone had the brilliant idea of creating a simple, cross-platform, extension-independent interface for getting random bytes and integers.
This effort would become random_bytes() and random_int() in PHP 7. (If you want to see how messy things were before PHP 7, take a look at the appropriate polyfill library.)
However, the initial design for this feature sucked really badly. Imagine the following code snippet:
If your operating system’s random number generator failed (e.g. you’re in a chroot and cannot access /dev/urandom), then the random_int() call would have returned false.
Because of type shenanigans in earlier versions of PHP, chr(false) returns a NUL byte. (This is fixed since 7.4 when strict_types is enabled, but the latest version at the time was PHP 5.6.)
After a heated debate on both the Github issue tracker for PHP and the internal mailing lists, the PHP project did the right thing: It will throw an Exception if it cannot safely generate random data.
Exceptions are developer-friendly: If you do not catch the exception, it kills the script immediately. If you decide to catch them, you can handle them in whatever graceful way you prefer. (Pretty error pages are often better than a white page and HTTP 500 status code, after all.)
In version 7.2 of the PHP programming language, they also made another win: Libsodium was promoted as part of the PHP standard library.
However, this feature isn’t as good as it could be: It’s easy to mix up inputs to the libsodium API since it expects string arguments instead of dedicated types (X25519SecretKey vs X25519PublicKey). To address this, the open source community has provided PHP libraries that avoid this mistake.
(I bet you weren’t expecting to hear that PHP is doing better with cryptography than Java in 2021, but here we are!)
I’d like to propose a set of tenets that cryptography libraries can use to self-evaluate the usability of their own designs and implementations. Keep in mind that these are tenets, not a checklist, so the spirit of the law means more than the literal narrowly-scoped interpretation.
For example: If you’re comparing cryptographic outputs, it should always be done in constant-time–even if timing leaks do not help attackers (i.e. in password hashing validation).
Most developers don’t need to fiddle with RSA and AES to construct their own hybrid public-key encryption designs (as you’d need to with Java). What they really need is a simple way to say, “Encrypt this so that only the recipient can decrypt it, but not the sender.”
This requires talking to your users and figuring out what their needs are instead of just assuming you know best.
3. Logically Separate Algorithm Categories
Put simply: Asymmetric cryptography belongs in a different API than symmetric cryptography. A similar separation should probably exist for specialized algorithms (e.g. multi-party computation and Shamir Secret Sharing).
Java may have got this one horribly wrong, but they’re not alone. The JWE specification (RFC 7518) also allows you to encrypt keys with:
RSA with PKCS#1 v1.5 padding (asymmetric encryption)
RSA with OAEP padding (asymmetric encryption)
ECDH (asymmetric key agreement)
AES-GCM (symmetric encryption)
If your users aren’t using a high-level abstraction, at least give them separate APIs for different algorithm types. If nothing else, it saves your users from having to ever type RSA/ECB again.
N.b. this means we should also collectively stop using the simple sign and verify verbs for Symmetric Authentication (i.e. HMAC) when these verbs imply digital signature algorithms (which are inherently asymmetric). Qualified verbs (verify –> sign_verify, mac_verify) are okay here.
4. Use Type-Safe Interfaces
If you allow any arbitrary string or byte array to be passed as the key, IV, etc. in your cryptography library, someone will misuse it.
Instead, you should have dedicated {structs, classes, types} (select appropriate) for each different kind of cryptography key your library expects. These keys should also provide guarantees about their contents (i.e. an Aes256GcmKey is always 32 bytes).
5. Defaults Matter
If you instantiate a new SymmetricCipher class, its default state should be an authenticated mode; never ECB.
The default settings are the ones that 80% of real world users should be using, if not a higher percentage.
6. Reduce Cognitive Load
If you’re encrypting data, why should your users even need to know what a nonce is to use it safely?
You MAY allow an explicit nonce if it makes sense for their application, but if they don’t provide one, generate a random nonce and handle it for them.
Aside: There’s an argument that we should have a standard for committing, deterministic authenticated encryption. If you need non-determinism, stick a random 256-bit nonce in the AAD and you get that property too. I liked to call this combination AHEAD (Authenticated Hedged Encryption with Associated Data), in the same vein as Hedged Signatures.
The less choices a user has to make to get their code working correctly, the less likely they’ll accidentally introduce a subtle flaw that makes their application hideously insecure.
7. Don’t Fail at Failure
If what you’re doing is sensitive to error oracles (e.g. padding), you have to be very careful about how you fail.
For example: RSA decryption with PKCS#1v1.5 padding. Doing a constant-time swap between the actual plaintext and some random throwaway value so the decryption error can result from the symmetric decryption is better than aborting.
Conversely, if you’re depending on a component to generate randomness for you and it fails, it shouldn’t fail silently and return bad data.
Security is largely about understanding how systems fail, so there’s no one-size-fits-all answer for this. However, the exact failure mechanism for a cryptographic feature should be decided very thoughtfully.
8. Minimize Runtime Negotiation
This is more of a concern for applications than libraries, but it bears mentioning here: The algorithm you’re using shouldn’t be something an attacker can decide. It should be determined at compile-time, not at run-time.
For example: There were several vulnerabilities in JSON Web Tokens where you could swap out the alg header to none (which removed all security) or from RS256 (RSA signed) to HS256…which meant the RSA public key was being used as an HMAC symmetric key. (See tenet 4 above.)
Biogesic/Paracetamol shortage? look no further, get yours here: https://invol.co/cl8i0icLet's all start 2021 on a good note with some positive vibes and enjo...
The ensuing discussion on /r/crypto led to several interesting questions that I thought would be worth capturing and answering in detail.
What’s Significant About the LadderLeak Paper?
This is best summarized by Table 1 from the paper. The sections labeled “This work” are what’s new/significant about this research. The paper authors were able to optimize existing attacks exploiting one-bit leakages against 192-bit and 160-bit elliptic curves. They were further able to exploit leakages of less than one bit in the same curves.
How Can You Leak Less Than One Bit?
We’re used to discrete quantities in computer science, but you can leak less than one bit of information in the case of side-channels.
Biased modular reduction can also create a vulnerable scenario: If you know the probability of a 0 or a 1 in a given position in the bit-string of the one-time number (i.e. the most significant bit) is not 0.5 to 0.5, but some other ratio (e.g. 0.51 to 0.49), you can (over many samples) conclude a probability of a specific bit in your dataset.
If “less than one bit” sounds strange, that’s probably our fault for always rounding up to the nearest bit when we express costs in computer science.
What’s the Cost of the Attack?
Consult Table 3 from the paper for empirical cost data: Table 3 from the LadderLeak paper.
How Devastating is LadderLeak?
First, it assumes a lot of things:
That you’re using ECDSA with either sect163r1 or secp192r1 (NIST P-192). Breaking larger curves requires more bits of bias (as far as we know).
That you’re using a cryptography library with cache-timing leaks.
That you have a way to measure the timing leaks (and not just pilfer the ECDSA secret key; i.e. in a TPM setup). This threat model generally assumes some sort of physical access.
But if you can pull the attack off, you can successfully recover the device’s ECDSA secret key. Which, for protocols like TLS, allow an attacker to impersonate a certificate-bearer (typically the server)… which is pretty devastating.
Is ECDSA Broken Now?
Non-deterministic ECDSA is not significantly more broken with LadderLeak than it already was by other attacks. LadderLeak does not break the Internet.
Fundamentally, LadderLeak doesn’t really change the risk calculus. Bleichenbacher’s attack framework for solving the Hidden Number Problem using Lattices was already practical, with sufficient samples.
As an acquaintance put it, the authors made a time-memory trade-off with a leaky oracle. It’s a neat result worthy of publication, but we aren’t any minutes closer to midnight with this revelation.
Is ECDSA’s k-value Really a Nonce?
Ehhhhhhhhh, sorta.
It’s complicated!
Nonce in cryptography has always meant “number that must be used only once” (typically per key). See: AES-GCM.
Nonces are often confused for initialization vectors (IVs), which in addition to a nonce’s requirements for non-reuse must also be unpredictable. See: AES-CBC.
However, nonces and IVs can both be public, whereas ECDSA k-values MUST NOT be public! If you recover the k-value for a given signature, you can recover the secret key too.
That is to say, ECDSA k-values must be all of the above:
Never reused
Unpredictable
Secret
Unbiased
They’re really in a class of their own.
For that reason, it’s probably better to think of the k-value as a per-signature key than a simple nonce. (n.b. Many cryptography libraries actually implement them as a one-time ECDSA keypair.)
What’s the Difference Between Random and Unpredictable?
The HMAC-SHA256 output of a message under a secret key is unpredictable for anyone not in possession of said secret key. This value, though unpredictable, is not random, since signing the same message twice yields the same output.
A large random integer when subjected to modular reduction by a non-Mersenne prime of the same magnitude will be biased towards small values. This bias may be negligible, but it makes the bit string that represents the reduced integer more predictable, even though it’s random.
What Should We Do? How Should We Respond?
First, don’t panic. This is interesting research and its authors deserve to enjoy their moment, but the sky is not falling.
Second, acknowledge that none of the attacks are effective against EdDSA.
If you feel the urge to do something about this attack paper, file a support ticket with all of your third-party vendors and business partners that handle cryptographic secrets to ask them if/when they plan to support EdDSA (especially if FIPS compliance is at all relevant to your work, since EdDSA is coming to FIPS 186-5).
Reason: With increased customer demand for EdDSA, more companies will adopt this digital signature algorithm (which is much more secure against real-world attacks). Thus, we can ensure an improved attack variant that actually breaks ECDSA doesn’t cause the sky to fall and the Internet to be doomed.
(Seriously, I don’t think most companies can overcome their inertia regarding ECDSA to EdDSA migration if their customers never ask for it.)
Although it is one of the most popular signature schemes today, ECDSA
presents a number of implementation pitfalls, in particular due to the
very sensitive nature of the random value (known as the nonce)
generated as part of the signing algorithm.
Digital signature algorithms are one of the coolest ideas to come out of asymmetric (a.k.a. public-key) cryptography, but they’re so simple and straightforward that most cryptography nerds don’t spend a lot of time thinking about them.
Even though you are more likely to run into a digital signature as a building block (e.g. certificate signatures in TLS) than think about them in isolation (e.g. secure software releases), they’re still really cool and worth learning about.
What’s a Digital Signature?
A digital signature is some string that proves that a specific message was signed by some specific entity in possession of the secret half of an asymmetric key-pair. Digital Signature Algorithms define the process for securely signing and verifying messages with their associated signatures.
Digital signature algorithms are one of the coolest ideas to come out of asymmetric (a.k.a. public-key) cryptography, but they’re so simple and straightforward that most cryptography nerds don’t spend a lot of time thinking about them.
Even though you are more likely to run into a digital signature as a building block (e.g. certificate signatures in TLS) than think about them in isolation (e.g. secure software releases), they’re still really cool and worth learning about.
What’s a Digital Signature?
A digital signature is some string that proves that a specific message was signed by some specific entity in possession of the secret half of an asymmetric key-pair. Digital Signature Algorithms define the process for securely signing and verifying messages with their associated signatures.
Public key: 482b8d3430445cdad6b5ce59778e09ab59d099120f32d316e881db1a6330390b
I can cryptographically sign the message “Dhole Moments: Never a dull moment!” with the above secret key, and it will generate the signature string: 63629779a31b623486145359c6f1d56602d8d9135e4b17fa2ae3667c8947397decd7ae01bfed08645a429f5dee906e87df4e18eefdfff9acb5b1488c9dec800f.
If you only have the message, signature string, and my public key, you can verify that I signed the message. But, very crucially, you cannot sign messages and convince someone else that they came from me. (With symmetric authentication schemes, such as HMAC, you can.)
A digital signature algorithm is considered secure if, in order for anyone else to pass off a different message as being signed by me, they would need my secret key to succeed. When this assumption holds true, we say the scheme is secure against existential forgery attacks.
How Do Digital Signatures Work?
Simple answer: They generally combine a cryptographic hash function (e.g. SHA-256) with some asymmetric operation, and the details beyond that are all magic.
More complicated answer: That depends entirely on the algorithm in question!
For example, with RSA signatures, you actually encrypt a hash of the message with your secret key to sign the message, and then you RSA-decrypt it with your public key to verify the signature. This is backwards from RSA encryption (where you do the totally sane thing: encrypt with public key, decrypt with secret key).
In all cases, the fundamental principle stays the same: You sign a message with a secret key, and can verify it with a public key.
In the interest of time, I’m not going to dive deep into how each signature algorithm works. That can be the subject of future blog posts (one for each of the algorithms in question).
Quick aside: Cryptographers who stumble across my blog might notice that I deviate from convention a bit. They typically refer to the sensitive half of an asymmetric key pair as a “private key”, but I instead call it a “secret key”.
The main reason for this is that “secret key” can be abbreviated as “sk” and public key can be abbreviated as “pk”, whereas private/public doesn’t share this convenience. If you ever come across their writings and wonder about this discrepancy, I’m breaking away from the norm and their way is more in line with the orthodoxy.
If you find yourself asking this question, you’re probably dangerously close to rolling your own crypto. If so, you’ll want to hire a cryptographer to make sure your designs aren’t insecure. (It’s extremely easy to design or implement otherwise-secure cryptography in an insecure way.)
EdDSA comes in two variants: Ed25519 (widely supported in a lot of libraries and protocols) and Ed448 (higher security level, but not implemented or supported in as many places).
The IETF standardized EdDSA in RFC 8032, in an effort related to the standardization of RFC 7748 (titled: Elliptic Curves for Security).
Formally, EdDSA is derived from Schnorr signatures and defined over Edwards curves. EdDSA’s design was motivated by the real-world security failures of ECDSA:
Whereas ECDSA requires a per-signature secret number () to protect the secret key, EdDSA derives the per-signature nonce deterministically from a hash of the secret key and message.
ECDSA with biased nonces can also leak your secret key through lattice attacks. To side-step this, EdDSA uses a hash function twice the size as the prime (i.e. SHA-512 for Ed25519), which guarantees that the distribution of the output of the modular reduction is unbiased (assuming uniform random inputs).
ECDSA implemented over the NIST Curves is difficult to implement in constant-time: Complicated point arithmetic rules, point division, etc. EdDSA only uses operations that are easy to implement in constant-time.
Hooray for EdDSA adoption even in federal hellscapes.
This is kind of a big deal! The FIPS standards are notoriously slow-moving, and they’re deeply committed to a sunk cost fallacy on algorithms they previously deemed acceptable for real-world deployment.
RFC 6979: Deterministic ECDSA
Despite EdDSA being superior to ECDSA in virtually every way (performance, security, misuse-resistance), a lot of systems still require ECDSA support for the foreseeable future.
If ECDSA is here to stay, we might as well make it suck less in real-world deployments. And that’s exactly what Thomas Pornin did when he wrote RFC 6979: Deterministic Usage of DSA and ECDSA.
(Like EdDSA, Deterministic ECDSA is on its way to FIPS 186-5. Look for it in FIPS-compliant hardware 5 years from now when people actually bother to update their implementations.)
Acceptable Digital Signature Algorithms
ECDSA Signatures
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the incumbent design for signatures. Unlike EdDSA, ECDSA is a more flexible design that has been applied to many different types of curves.
This is more of a curse than a blessing, as Microsoft discovered with CVE-2020-0601: You could take an existing (signature, public key) pair with standard curve, explicitly set the generator point equal to the victim’s public key, and set your secret key to 1, and Windows’s cryptography library would think, “This is fine.”
For this reason, cryptographers were generally wary of proposals to add support for Koblitz curves (including secp256k1–the Bitcoin curve) or Brainpool curves into protocols that are totally fine with NIST P-256 (and maybe NIST P-384 if you need it for compliance reasons).
For that reason, if you can’t use EdDSA or RFC 6979, your fallback option is ECDSA with one of those two curves (secp256r1, secp384r1), and making sure that you have access to a reliable cryptographic random number generator.
Not just for the reasons that Trail of Bits is arguing (which I happen to agree with), but more importantly:
Replacing RSA with EdDSA (or Deterministic ECDSA) also gives teams an opportunity to practice migrating from one cryptography algorithm suite to another, which will probably be a much-needed experience when quantum computers come along and we’re all forced to migrate to post-quantum cryptography.
Encryption is a bigger risk of being broken by quantum computers than signature schemes: If you encrypt data today, a quantum computer 20 years down the line can decrypt it immediately. Conversely, messages that are signed today cannot be broken until after a quantum computer exists.
That being said, if you only need signatures and not encryption, RSA is still acceptable. If you also need encryption, don’t use RSA for that purpose.
If you can, use PSS padding rather than PKCS#1 v1.5 padding, with SHA-256 or SHA-384. But for signatures (i.e. not encryption), PKCS#1 v1.5 padding is fine.
Dishonorable Mention
DSA Signatures
There’s really no point in using classical DSA, when ECDSA is widely supported and has more ongoing attention from cryptography experts.
If you’re designing a system in 2020 that uses DSA, my only question for you is…
Although it is far too early to consider adopting these yet, cryptographers are working on new designs that protect against wider ranges of real-world threats.
Let’s briefly look at some of them and speculate wildly about what the future looks like. For fun. Don’t use these yet, unless you have a very good reason to do so.
Digital Signature Research Topics
Hedged Signatures
Above, we concluded that EdDSA and Deterministic ECDSA were generally the best choice (and what I’d recommend for software developers). There is one important caveat: Fault attacks.
A fault attack is when you induce a hardware fault into a computer chip, and thereby interfere with the correct functioning of a cryptography algorithm. This is especially relevant to embedded devices and IoT.
The IETF’s CFRG is investigating the use of additional randomization of messages (rather than randomizing signatures) as a safeguard against leaking secret keys through fault injection.
If this technique is proven successful at mitigating fault injection attacks, then libsodium users will be able to follow the technique outlined in Dhole Crypto to safeguard their own protocols against fault attacks. Until then, they’re at least as safe as deterministic EdDSA today.
Threshold ECDSA Signatures
Suppose you have a scenario where you want 3-or-more people to have to sign a message before it’s valid. That’s exactly what Threshold ECDSA with Fast Trustless Setup aspires to provide.
Although this is mostly being implemented in cryptocurrency projects today, the cryptography underpinnings are fascinating. At worst, this will be one good side-effect to come from blockchain mania.
Post-Quantum Digital Signatures
Hash-Based Signatures
The best hash-based signature schemes are based on the SPHINCS design for one simple reason: It’s stateless.
In earlier hash-based digital signatures, such as XMSS, you have to maintain a state of which keys you’ve already used, to prevent attacks. Google’s Adam Langley previously described this as a “huge foot-cannon” for security (although probably okay in some environments, such as an HSM).
Lattice-Based Signatures
There are a lot of post-quantum signature algorithm designs defined over lattice groups, but my favorite lattice-based design is called FALCON. FALCON stands for FAst-Fourier Lattice-based COmpact Signatures Over NTRU.
Sign Here, Please
Who knew there would be so much complexity involved with such a simple cryptographic operation? And we didn’t even dive deep on how any of them work.
That’s the problem with cryptography: It’s a fractal of complexity. The more you know about these topics, the deeper the complexity becomes.
But if you’re implementing a protocol today and need a digital signature algorithm, use (in order of preference):
Ed25519 or Ed448
ECDSA over NIST P-256 or P-384, with RFC 6979
ECDSA over NIST P-256 or P-384, without RFC 6979
RSA (as a last resort)
But most importantly: make sure you have a cryptographer audit your designs.
On October 9th, 2018, at San Francisco Blockchain Week’s Epicenter conference, Keep’s very own Piotr Dyraga gave a talk on Threshold Elliptic Curve Digital Signature Algorithm (t-ECDSA). This past…
Their techniques are also applicable to Deterministic ECDSA (RFC 6979), and potentially work against any deterministic signature scheme (n.b. the Fiat-Shamir or Schnorr distinction isn’t meaningful in this context).
Although that might seem alarming, fault attacks aren’t especially useful for software applications running on general-purpose computers. They’re mostly in the threat models for smartcards and embedded devices.
Their techniques are also applicable to Deterministic ECDSA (RFC 6979), and potentially work against any deterministic signature scheme (n.b. the Fiat-Shamir or Schnorr distinction isn’t meaningful in this context).
Although that might seem alarming, fault attacks aren’t especially useful for software applications running on general-purpose computers. They’re mostly in the threat models for smartcards and embedded devices.
Let’s just consult the formal definition given by Aranha, et al. in the paper I linked above! Totally human-readable, right? (Dark mode edit made by me.) Okay, if you’re not a cryptographer, this is probably clear as mud.
Let’s try a different approach (one that most software engineers will find more intuitive). We’ll start with non-hedged signatures, and then tweak them to become hedged.
Libsodium: Non-Hedged Signatures
Libsodium’s crypto_sign_detached() (which implements Ed25519) accepts two arguments:
The message being signed.
The secret key held by the signer.
Libsodium’s congruents crypto_sign_verify_detached() accepts three arguments:
The detached signature.
The message.
The public key (corresponds to the secret key from the other function).
Since libsodium uses Ed25519 under-the-hood, the signature algorithm is deterministic: If you sign the same message with the same secret key, it will always produce the same signature.
Last year when I wrote Dhole Cryptography (in PHP and JavaScript), I decided to implement what would later come to be called “hedged signatures” by cryptographers.
Instead of just signing a message, Dhole Crypto first generates a 256-bit per-message nonce and then signs the nonce and the message together. Then, it appends the nonce to the generated signature (and encodes this as one binary-safe string).
That is to say, the major hack is to change a procedure from this:
If you pay careful attention to the placement of the nonce in this updated procedure, you’ll notice that it’s backwards compatible with the original libsodium API for Ed25519: crypto_sign() and crypto_sign_open().
Of course, these details are totally abstracted away from the user. Instead, the API looks like this (PHP):
<?phpuse Soatok\DholeCrypto\Asymmetric;use Soatok\DholeCrypto\Key\AsymmetricSecretKey;// Key generation$secret = AsymmetricSecretKey::generate();$public = $secret->getPublicKey();// Signing a message$message = "I certify that you have paid your $350 awoo fine";$sig = Asymmetric::sign($message, $secret);// Verifying a message and signatureif (!Asymmetric::verify($message, $public, $sig)) { die('AWOO FINE UNPAID');}
For JavaScript developers, this may be more intuitive to read:
const { Asymmetric, AsymmetricSecretKey} = require('dhole-crypto');(async function () { let wolfSecret = await AsymmetricSecretKey.generate(); let wolfPublic = wolfSecret.getPublicKey(); let message = "Your $350 awoo fine has been paid UwU"; let signature = await Asymmetric.sign(message, wolfSecret); if (!await Asymmetric.verify(message, wolfPublic, signature)) { console.log("Invalid signature. Awoo not authorized."); }})();
Do Hedged Signatures Protect Against Fault Attacks?
Sort of. It really depends on the kind of fault attack the attacker uses.
See Section 5 of the paper for a detailed break-down of the provable security of hedged signatures against XEdDSA (a variant of EdDSA used by the Signal protocol; the EdDSA variants specified in RFC 8032 were not studied in that paper).
However, the exploit explored by Kudelski using simple voltage glitches to break EdDSA in an Arduino device does become significantly more difficult with hedged signatures versus classical EdDSA.
Additionally, if you combine the existing techniques for mitigating fault attacks in embedded software with a protocol that uses hedged signatures, you may push the cost of a successful fault attack to become economically impractical for attackers.
However, it’s demonstrable that Hedged Signatures are at least as secure as Deterministic Signatures:
Even if your hedging suffers from a catastrophic randomness failure and generates the same nonce twice, the actual nonce used within Ed25519 will be derived from the SHA-512 hash of this value, the message, and a secret key.
Consequently, the only way for the internal nonce to repeat is for the message to be the same–which is the same scenario as a Deterministic Signature, which doesn’t let attackers steal your secret key.
Safe-by-default cryptography makes my heart shine. Art by Kerijiano.
What Does This All Mean?
Hedged signatures are at least as safe as Deterministic Signatures, and in some scenarios, offer a greater degree of protection than Deterministic Signatures.
Additionally, it’s very easy to convert a Deterministic Signature scheme into a Hedged Signature Scheme: Just add additional randomness that gets signed as part of the message, then append this randomness to the signature (so the signature can be successfully verified later).
Or, if you’re using a programming language that I publish open source software in, you can just use Dhole Cryptography and not worry about these details.
We’ve succesfully conducted a fault attack against EdDSA that allowed us to recover enough secret key material to produce fake signatures for any message in a way a verifier cannot detect.
Digital signature algorithms are one of the coolest ideas to come out of asymmetric (a.k.a. public-key) cryptography, but they’re so simple and straightforward that most cryptography nerds don’t spend a lot of time thinking about them.
Even though you are more likely to run into a digital signature as a building block (e.g. certificate signatures in TLS) than think about them in isolation (e.g. secure software releases), they’re still really cool and worth learning about.
What’s a Digital Signature?
A digital signature is some string that proves that a specific message was signed by some specific entity in possession of the secret half of an asymmetric key-pair. Digital Signature Algorithms define the process for securely signing and verifying messages with their associated signatures.
Public key: 482b8d3430445cdad6b5ce59778e09ab59d099120f32d316e881db1a6330390b
I can cryptographically sign the message “Dhole Moments: Never a dull moment!” with the above secret key, and it will generate the signature string: 63629779a31b623486145359c6f1d56602d8d9135e4b17fa2ae3667c8947397decd7ae01bfed08645a429f5dee906e87df4e18eefdfff9acb5b1488c9dec800f.
If you only have the message, signature string, and my public key, you can verify that I signed the message. But, very crucially, you cannot sign messages and convince someone else that they came from me. (With symmetric authentication schemes, such as HMAC, you can.)
A digital signature algorithm is considered secure if, in order for anyone else to pass off a different message as being signed by me, they would need my secret key to succeed. When this assumption holds true, we say the scheme is secure against existential forgery attacks.
How Do Digital Signatures Work?
Simple answer: They generally combine a cryptographic hash function (e.g. SHA-256) with some asymmetric operation, and the details beyond that are all magic.
More complicated answer: That depends entirely on the algorithm in question!
For example, with RSA signatures, you actually encrypt a hash of the message with your secret key to sign the message, and then you RSA-decrypt it with your public key to verify the signature. This is backwards from RSA encryption (where you do the totally sane thing: encrypt with public key, decrypt with secret key).
In all cases, the fundamental principle stays the same: You sign a message with a secret key, and can verify it with a public key.
In the interest of time, I’m not going to dive deep into how each signature algorithm works. That can be the subject of future blog posts (one for each of the algorithms in question).
Quick aside: Cryptographers who stumble across my blog might notice that I deviate from convention a bit. They typically refer to the sensitive half of an asymmetric key pair as a “private key”, but I instead call it a “secret key”.
The main reason for this is that “secret key” can be abbreviated as “sk” and public key can be abbreviated as “pk”, whereas private/public doesn’t share this convenience. If you ever come across their writings and wonder about this discrepancy, I’m breaking away from the norm and their way is more in line with the orthodoxy.
If you find yourself asking this question, you’re probably dangerously close to rolling your own crypto. If so, you’ll want to hire a cryptographer to make sure your designs aren’t insecure. (It’s extremely easy to design or implement otherwise-secure cryptography in an insecure way.)
EdDSA comes in two variants: Ed25519 (widely supported in a lot of libraries and protocols) and Ed448 (higher security level, but not implemented or supported in as many places).
The IETF standardized EdDSA in RFC 8032, in an effort related to the standardization of RFC 7748 (titled: Elliptic Curves for Security).
Formally, EdDSA is derived from Schnorr signatures and defined over Edwards curves. EdDSA’s design was motivated by the real-world security failures of ECDSA:
Whereas ECDSA requires a per-signature secret number () to protect the secret key, EdDSA derives the per-signature nonce deterministically from a hash of the secret key and message.
ECDSA with biased nonces can also leak your secret key through lattice attacks. To side-step this, EdDSA uses a hash function twice the size as the prime (i.e. SHA-512 for Ed25519), which guarantees that the distribution of the output of the modular reduction is unbiased (assuming uniform random inputs).
ECDSA implemented over the NIST Curves is difficult to implement in constant-time: Complicated point arithmetic rules, point division, etc. EdDSA only uses operations that are easy to implement in constant-time.
Hooray for EdDSA adoption even in federal hellscapes.
This is kind of a big deal! The FIPS standards are notoriously slow-moving, and they’re deeply committed to a sunk cost fallacy on algorithms they previously deemed acceptable for real-world deployment.
RFC 6979: Deterministic ECDSA
Despite EdDSA being superior to ECDSA in virtually every way (performance, security, misuse-resistance), a lot of systems still require ECDSA support for the foreseeable future.
If ECDSA is here to stay, we might as well make it suck less in real-world deployments. And that’s exactly what Thomas Pornin did when he wrote RFC 6979: Deterministic Usage of DSA and ECDSA.
(Like EdDSA, Deterministic ECDSA is on its way to FIPS 186-5. Look for it in FIPS-compliant hardware 5 years from now when people actually bother to update their implementations.)
Acceptable Digital Signature Algorithms
ECDSA Signatures
The Elliptic Curve Digital Signature Algorithm (ECDSA) is the incumbent design for signatures. Unlike EdDSA, ECDSA is a more flexible design that has been applied to many different types of curves.
This is more of a curse than a blessing, as Microsoft discovered with CVE-2020-0601: You could take an existing (signature, public key) pair with standard curve, explicitly set the generator point equal to the victim’s public key, and set your secret key to 1, and Windows’s cryptography library would think, “This is fine.”
For this reason, cryptographers were generally wary of proposals to add support for Koblitz curves (including secp256k1–the Bitcoin curve) or Brainpool curves into protocols that are totally fine with NIST P-256 (and maybe NIST P-384 if you need it for compliance reasons).
For that reason, if you can’t use EdDSA or RFC 6979, your fallback option is ECDSA with one of those two curves (secp256r1, secp384r1), and making sure that you have access to a reliable cryptographic random number generator.
Not just for the reasons that Trail of Bits is arguing (which I happen to agree with), but more importantly:
Replacing RSA with EdDSA (or Deterministic ECDSA) also gives teams an opportunity to practice migrating from one cryptography algorithm suite to another, which will probably be a much-needed experience when quantum computers come along and we’re all forced to migrate to post-quantum cryptography.
Encryption is a bigger risk of being broken by quantum computers than signature schemes: If you encrypt data today, a quantum computer 20 years down the line can decrypt it immediately. Conversely, messages that are signed today cannot be broken until after a quantum computer exists.
That being said, if you only need signatures and not encryption, RSA is still acceptable. If you also need encryption, don’t use RSA for that purpose.
If you can, use PSS padding rather than PKCS#1 v1.5 padding, with SHA-256 or SHA-384. But for signatures (i.e. not encryption), PKCS#1 v1.5 padding is fine.
Dishonorable Mention
DSA Signatures
There’s really no point in using classical DSA, when ECDSA is widely supported and has more ongoing attention from cryptography experts.
If you’re designing a system in 2020 that uses DSA, my only question for you is…
Although it is far too early to consider adopting these yet, cryptographers are working on new designs that protect against wider ranges of real-world threats.
Let’s briefly look at some of them and speculate wildly about what the future looks like. For fun. Don’t use these yet, unless you have a very good reason to do so.
Digital Signature Research Topics
Hedged Signatures
Above, we concluded that EdDSA and Deterministic ECDSA were generally the best choice (and what I’d recommend for software developers). There is one important caveat: Fault attacks.
A fault attack is when you induce a hardware fault into a computer chip, and thereby interfere with the correct functioning of a cryptography algorithm. This is especially relevant to embedded devices and IoT.
The IETF’s CFRG is investigating the use of additional randomization of messages (rather than randomizing signatures) as a safeguard against leaking secret keys through fault injection.
If this technique is proven successful at mitigating fault injection attacks, then libsodium users will be able to follow the technique outlined in Dhole Crypto to safeguard their own protocols against fault attacks. Until then, they’re at least as safe as deterministic EdDSA today.
Threshold ECDSA Signatures
Suppose you have a scenario where you want 3-or-more people to have to sign a message before it’s valid. That’s exactly what Threshold ECDSA with Fast Trustless Setup aspires to provide.
Although this is mostly being implemented in cryptocurrency projects today, the cryptography underpinnings are fascinating. At worst, this will be one good side-effect to come from blockchain mania.
Post-Quantum Digital Signatures
Hash-Based Signatures
The best hash-based signature schemes are based on the SPHINCS design for one simple reason: It’s stateless.
In earlier hash-based digital signatures, such as XMSS, you have to maintain a state of which keys you’ve already used, to prevent attacks. Google’s Adam Langley previously described this as a “huge foot-cannon” for security (although probably okay in some environments, such as an HSM).
Lattice-Based Signatures
There are a lot of post-quantum signature algorithm designs defined over lattice groups, but my favorite lattice-based design is called FALCON. FALCON stands for FAst-Fourier Lattice-based COmpact Signatures Over NTRU.
Sign Here, Please
Who knew there would be so much complexity involved with such a simple cryptographic operation? And we didn’t even dive deep on how any of them work.
That’s the problem with cryptography: It’s a fractal of complexity. The more you know about these topics, the deeper the complexity becomes.
But if you’re implementing a protocol today and need a digital signature algorithm, use (in order of preference):
Ed25519 or Ed448
ECDSA over NIST P-256 or P-384, with RFC 6979
ECDSA over NIST P-256 or P-384, without RFC 6979
RSA (as a last resort)
But most importantly: make sure you have a cryptographer audit your designs.
On October 9th, 2018, at San Francisco Blockchain Week’s Epicenter conference, Keep’s very own Piotr Dyraga gave a talk on Threshold Elliptic Curve Digital Signature Algorithm (t-ECDSA). This past…
Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022
Earlier this year, Cendyne published A Deep Dive into Ed25519 Signatures, which covered some of the different types of digital signature algorithms, but mostly delved into the Ed25519 algorithm. Truth in advertising.
This got me thinking, “Why isn’t there a better comparison of different elliptic curve signature algorithms available online?”
Most people just defer to SafeCurves, but it’s a little dated: We have
... mehr anzeigen
Guidance for Choosing an Elliptic Curve Signature Algorithm in 2022
Earlier this year, Cendyne published A Deep Dive into Ed25519 Signatures, which covered some of the different types of digital signature algorithms, but mostly delved into the Ed25519 algorithm. Truth in advertising.
This got me thinking, “Why isn’t there a better comparison of different elliptic curve signature algorithms available online?”
For the purpose of simplicity, I’m not going to focus on a general treatment of Elliptic Curve Cryptography (ECC), which includes pairing-based cryptography, Elliptic-Curve Diffie-Hellman, and (arguably) isogeny cryptography.
Instead, I’m going to focus entirely on elliptic curve digital signature algorithms.
Note: The content of this post is a bit lower-level than most programmers ever need to be concerned with. If you’re a programmer and interested in learning cryptography, start here. If you’re looking for library recommendations, libsodium is a good safe default.
Compliance Rules Everything Around Me
If you have to meet some arbitrary compliance requirements (i.e. FIPS 140-3, CNSA, etc.), your decision is already made for you, and you shouldn’t waste your time reading blogs like this that will only get your hopes up about the options available to you.
Choose the option your compliance officer demands, and hope it’s good enough.
Let’s start with the same curve Cendyne analyzed: Ed25519.
Ed25519 (EdDSA, Curve25519)
Ed25519 is one of the two digital signature algorithms today that use the EdDSA algorithm framework. The other is Ed448, which targets a higher security level (224-bit vs 128-bit) but is also slower and uses SHAKE256 (which is overkill and not great for performance).
Ed25519 is a safe default choice for most applications where a digital signature is appropriate, for many reasons:
Ed25519 uses deterministic nonces, which means you’re severely unlikely to ever reproduce the Sony ECDSA k-reuse bug in your system. The deterministic nonce is calculated from the SHA512 hash of the secret key and message. Two invocations to crypto_sign_ed25519() with the same message and secret key will produce the same signature, but the intermediate nonce value is never revealed to an attacker.
Ed25519 includes the public key in the data hashed to produce the signature (more specifically s from the (R,s) pair). This offers a property that ECDSA lacks: Exclusive Ownership. I’ve written about this property before. Without Exclusive Ownership, it’s possible to create a single signature value that’s valid for multiple different (message, public key) pairs.
Years ago, there would have an additional list item: Ed25519 uses Edward Curves, which have complete addition formulas and are therefore safer to implement in constant-time than Weierstrass curves (i.e. the NIST curves). However, we now have complete addition formulas for Weierstrass curves, so this has become a moot point (assuming your implementation uses complete addition formulas).
For systems that want the security of Ed25519 and its various well-studied implementations, but still need a prime-order group for their protocol, cryptographers have developed the Ristretto Group to meet your needs.
Additionally, Ed25519 is not approved for many government applications, although it did make the latest draft revision of FIPS 186 in 2019. If you care about compliance (see above), you cannot use Ed25519. Yet.
A niche Internet meme for cryptography engineers
Guidance for Ed25519
Unless legally prohibited, Ed25519 should be your default choice, unless you need a prime-order group. In that case, build your desired protocol atop Ristretto255.
If you’re not sure if you need a prime-order group, you probably don’t. It’s a specialized requirement for uncommon use cases (ring signatures, password authenticated key exchange protocols, zero-knowledge proofs, etc.).
There is no specified reason why Bitcoin chose secp256k1 over another elliptic curve at the time of its inception, but we can speculate:
The author was a pseudonymous contributor to the Metzdowd mailing list for cypherpunks, and probably didn’t trust the NIST curves. Since Ed25519 didn’t exist at the time, the only obvious choice for a hipster elliptic curve parameter selection was to rely on the SECG recommendations, which specify the NIST and Koblitz curves. If you cross the NIST curves off the list, only the Koblitz curves remained.
Therefore, the selection of secp256k1 is likely an artefact of computer history and not a compelling reason to select secp256k1 in new designs. Please look elsewhere.
Fact: Imgflip didn’t have a single secp256k1 meme until I made this one.
Secp256k1 targets the 128-bit security level.
Guidance for secp256k1
Don’t bother, there are better options. (i.e. Ed25519)
If you’re writing software for a cryptocurrency-related project, and you feel compelled to use secp256k1 for the sake of reducing your code footprint, please strongly consider the option of burning everything to the proverbial ground.
As we noted above, secp256k1 isn’t widely used outside of cryptocurrency.
As a direct consequence of this (as we’ll discuss in the NIST P-256 section), most cryptography libraries don’t offer optimized, side-channel-resistant implementations of secp256k1; even if they do offer optimized implementations of NIST P-256.
(Meanwhile, Ed25519 is designed to be side-channel and misuse-resistant, partly due to its Schnorr construction and constant-time ladder for scalar multiplication, so any library that implements Ed25519 is overwhelmingly likely to be constant-time.)
Therefore, any secp256k1 library for most programming languages that isn’t an FFI wrapper for libsecp256k1 will have worse performance than the other 256-bit curves.
The previously linked article was about BouncyCastle’s implementation (which covers Java and .NET), but there’s still plenty of secp256k1 implementations that don’t FFI libsecp256k1.
From a quick Google Search:
Python (uses EEA rather than Binary GCD for modular inverse)
Go (uses Numbers, which weren’t designed for cryptography)
If you’re using secp256k1, and you’re not basing your choice on cybercash-interop, you’re playing with fire at the implementation and ecosystem levels–even if there are no security problems with the Koblitz curve itself.
You are much better off choosing any different curve than secp256k1 if you don’t have a Bitcoin/Ethereum/etc. interoperability requirement.
NIST P-256 is the go-to curve to use with ECDSA in the modern era. Unlike Ed25519, P-256 uses a prime-order group, and is an approved algorithm to use in FIPS-validated modules.
Most cryptography libraries offer optimized assembly implementations of NIST P-256, which makes it less likely that your signing operations will leak timing information or become a significant performance bottleneck.
P-256 targets the 128-bit security level.
Why Not Use P-256?
Once upon a time, P-256 was riskier than Ed25519 (for signatures) and X25519 (for Diffie-Hellman), due to the incomplete addition formulas that led to timing-leaky implementations.
If you’re running old software, you may still be vulnerable to timing attacks that can recover your ECDSA secret key. However, there is a good chance that you’re on a modern and secure implementation in 2022, especially if you’re outsourcing this to OpenSSL or its derivatives.
ECDSA requires a secure randomness source to sign data. If you don’t have one available, and you sign anything, you’re coughing up your secret key to any attacker capable of observing multiple signatures.
Guidance for P-256
P-256 is an acceptable choice, especially if you’re forced to cope with FIPS and/or the CNSA suite requirements when using cryptography.
Of course, if you can get away with Ed25519, use Ed25519 instead.
If you use P-256, make sure you’re using it with SHA-256. Some implementations may default to something weaker (e.g. SHA-1).
If you’re also going to be performing ECDH with P-256, make sure you use compressed points. There used to be a patent; it died in 2018.
If you can afford it, make sure you use deterministic ECDSA (RFC 6979) or hedged signatures (if fault attacks are relevant to your threat model).
NIST P-384 has a larger field than the curves we’ve previously examined, which allows P-384 to target the 192-bit security level. That’s the primary reason why anyone would choose P-384.
Naturally, elliptic curve security is more complicated than merely security against the Elliptic Curve Discrete Logarithm Problem (ECDLP).
P-384 is most often paired with SHA-384, which is the most widely used flavor of the SHA-2 family hash functions that isn’t susceptible to length-extension attacks. (There are also truncated SHA-512 variants specified later, but that’s also what SHA-384 is under-the-hood.)
If you’re aiming to build a “secure-by-default” tool for a system that the US government might one day become a customer of, with minimal cryptographic primitive choice, using NIST P-384 with SHA-384 makes for a reasonably minimalistic bundle.
Why Not Use P-384?
Unlike P-256, most P-384 implementations don’t use constant-time, optimized, and/or formally verified assembly code. (Notable counter-examples: AWS-LC and Go x/crypto.)
Like P-256, P-384 also requires a secure randomness source to sign data. If you aren’t providing one, expect your signing key to end up on fail0verflow one day.
Guidance for P-384
If you use P-384, make sure you’re using it with SHA-384.
The standard NIST curve advice of RFC 6979 and point compression and/or hedged signatures applies here too.
Systems that choose P-521 often have an interesting threat model, even though said threat model is rarely formally specified.
It’s overwhelmingly likely that what eventually breaks the 256-bit elliptic curves will also break P-521 in short order: Cryptography Relevant Quantum Computers.
The only thing P-521 does against CRQCs that P-256 doesn’t is require more quantum memory. If you’re worried about QRQCs, you might want to look into hybrid post-quantum signature schemes.
If you’re choosing P-521 in your designs, you’re basically saying, “I want to have 256 bits of asymmetric cryptographic security, come hell or high water!” even though the 128-bit security level is likely just fine for your actual threats.
Aside: P-521 and 512-bit ECC Security
P-521 is not a typo, although people sometimes think it is. P-521 uses the Mersenne prime instead of a 512-bit near-Mersenne prime.
This has led to an unfortunate trend in cryptography media to map ECC key sizes to symmetric security levels that misleads people as to the relationship between the two. For example:
Regrettably, this is misleading, because plotting the ECC Key Size versus equivalent Symmetric Security isn’t a how ECDLP security works. The ratio of the exponents involved is totally linear; it doesn’t suddenly increase beyond 384-bit curves for a mysterious mathematical reason.
256-bit Curves target the 128-bit security level
384-bit Curves target the 192-bit security level
512-bit Curves target the 256-bit security level
521-bit Curves actually target the 260-bit security level, but that meets or exceeds the 256-bit security level, so that’s how the standards are interpreted
The reason for this boils down entirely to the best attack against the Elliptic Curve Discrete Logarithm Problem: Pollard’s Rho, which recovers the secret key from an -bit public key (which has a search space) in guesses.
Taking the square root of a number is the same as halving its exponent, so the security level is half: .
Takeaway: If someone tells you that you need a 521-bit curve to meet the 256-bit security level, they are mistaken and it’s not their fault.
It’s slow. Much slower than P-256 and Ed25519. Modestly slower than P-384.
Unlike P-384, you’re less likely to find an optimized, constant-time P-521 implementation.
Guidance for P-521
First, make a concerted effort to figure out the motivation for P-521 in your designs. Chances are, someone is putting too much emphasis on the wrong things for security.
If you use P-521, make sure you’re using it with SHA-512.
The standard NIST curve advice of RFC 6979 and point compression and/or hedged signatures applies here too.
Ed448 is the P-521 of the Edwards curves: It mostly exists to give standards committees a psychological comfort for the unlikely event that 256-bit ECC is desperately broken but ECC larger than 384 bits is somehow still safe.
The very concept of having multiple “security levels” for raw cryptography primitives is mostly an artefact of the historical military roots of cryptography, rather than a serious consideration in the modern world.
Unfortunately, this leads to implementations that prioritize runtime algorithm selection negotiation, which maximizes the risk of protocol-level vulnerabilities. See also: JWT.
Ed448 was specified to use SHAKE256, which is a needlessly conservative decision which leads to an unnecessary performance bottleneck.
Why Not Use Ed448?
Aside from the performance hit mentioned previously, there’s no compelling reason to avoid Ed448 that isn’t also true of either Ed25519 or P-384.
Guidance for Ed448
If you want more speed, go with Ed25519. In addition to being faster, Ed25519 is also very widely supported.
If you need a prime-order field, use Decaf with Ed448 or consider P-384.
The Brainpool Curves
The main motivation for the Brainpool curves is that the NIST curves were not generated in a “verifiable pseudo-random way”.
The only reasons you’d ever want to support the Brainpool curves include:
You think the NIST curves are somehow backdoored by the NSA
You don’t appreciate small attack surfaces in cryptography libraries
The German government told you to (see: compliance)
Most of the advice for the NIST Curves at each security level can be copy/pasted for the Brainpool curves, with one important caveat:
When considering real-world implementations, Brainpool curves are more likely to use the general purpose Big Number procedures (which aren’t always constant-time), rather than optimized assembly code, than the NIST curves are.
Therefore, my general guidance for the Brainpool curves is simply:
Proceed at your own peril
Consider hiring a cryptography engineer to study the implementation you’re relying on, especially with regard to timing attacks
The NIST curves do not meet this requirement. If you care about whether or not the standards were manipulated to insert a backdoor, rigidity matters to you. Otherwise, it’s not a deal-breaker.
All relevant curves satisfy the requirements, as of 2014.
SafeCurves continues to be a useful resource, especially if you stray from the guidance on this page.
For example: You wouldn’t want to use pairing-friendly curves for general purpose ECC digital signatures, because they’re suitable for specialized problems. SafeCurves correctly recommends not using BN(2,254).
Ed25519 is great. NIST P-256 and P-384 are okay (with caveats). Anything else is questionable, and their parameter selection should come with a clear justification.
AWS-LC is a general-purpose cryptographic library maintained by the AWS Cryptography team for AWS and their customers. It іs based on code from the Google BoringSSL project and the OpenSSL project....
A question I get asked frequently is, “How did you learn cryptography?”
I could certainly tell everyone my history as a self-taught programmer who discovered cryptography when, after my website for my indie game projects kept getting hacked, I was introduced to cryptographic hash functions… but I suspect the question folks want answered is, “How would you recommend I learn cryptography?” rather than my cautionary tale about poorly-implemented password hash being a gateway bug.
The Traditional Ways to Learn
There are two traditional ways to learn cryptography.
If you want a book to augment your journey in either traditional path, I recommend Serious Cryptography by Jean-Philippe Aumasson.
Academic Cryptography
The traditional academic way to learn cryptography involves a lot of self-study about number theory, linear algebra, discrete mathematics, probability, permutations, and field theory.
You’d typically start off with classical ciphers (Caesar, etc.) then work your way through the history of ciphers until you finally reach an introduction to the math underpinning RSA and Diffie-Hellman, and maybe taught about Schneier’s Law and cautioned to only use AES and SHA-2… and then you’re left to your own devices unless you pursue a degree in cryptography.
The end result of people carelessly exploring this path is a lot of designs like Telegram’s MTProto that do stupid things with exotic block cipher modes and misusing vanilla cryptographic hash functions as message authentication codes; often with textbook a.k.a. unpadded RSA, AES in ECB, CBC, or some rarely-used mode that the author had to write custom code to handle (using ECB mode under the hood), and (until recently) SHA-1.
People who decide to pursue cryptography as a serious academic discipline will not make these mistakes. They’re far too apt for the common mistakes. Instead, they run the risk of spending years involved in esoteric research about homomorphic encryption, cryptographic pairings, and other cool stuff that might not see real world deployment (outside of novel cryptocurrency hobby projects) for five or more years.
That is to say: Academia is a valid path to pursue, but it’s not for everyone.
If you want to explore this path, Cryptography I by Dan Boneh is a great starting point.
Security Industry-Driven Cryptography
The other traditional way to learn cryptography is to break existing cryptography implementations. This isn’t always as difficult as it may sound: Reverse engineering video games to defeat anti-cheat protections has led several of my friends into learning about cryptography.
For security-minded folks, the best place to start is the CryptoPals challenges. Another alternative is CryptoHack.
There are also plenty of CTF events all year around, but they’re rarely a good cryptography learning exercise above what CryptoPals offers. (Though there are notable exceptions.)
If you’re coming from a computer programming background and want to learn cryptography, the traditional approaches carry the risk of Reasoning By Lego.
Instead, the approach I recommend is to start gaining experience with the safest, highest-level libraries and then slowly working your way down into the details.
This approach has two benefits:
If you have to implement something while you’re still learning, your knowledge and experience is stilted towards “use something safe and secure” not “hack together something with Blowfish in ECB mode and MD5 because they’re familiar”.
You can let your own curiosity guide your education rather than follow someone else’s study guide.
To illustrate what this looks like, here’s how a JavaScript developer might approach learning cryptography, starting from the most easy-mode library and drilling down into specifics.
Super Easy Mode: DholeCrypto
Disclaimer: This is my project.
Dhole Crypto is an open source library, implemented in JavaScript and PHP and powered by libsodium, that tries to make security as easy as possible.
I designed Dhole Crypto for securing my own projects without increasing the cognitive load of anyone reviewing my code.
If you’re an experienced programmer, you should be able to successfully use Dhole Crypto in a Node.js/PHP project. If it does not come easy, that is a bug that should be fixed immediately.
Easy Mode: Libsodium
Using libsodium is slightly more involved than Dhole Crypto: Now you have to know what a nonce is, and take care to manage them carefully.
Advantage: Your code will be faster than if you used Dhole Crypto.
Libsodium is still pretty easy. If you use this cheat sheet, you can implement something secure without much effort. If you deviate from the cheat sheet, pay careful attention to the documentation.
If you’re writing system software (i.e. programming in C), libsodium is an incredibly easy-to-use library.
Moderate Difficulty: Implementing Protocols
Let’s say you’re working on a project where libsodium is overkill, and you only need a few cryptography primitives and constructions (e.g. XChaCha20-Poly1305). A good example: In-browser JavaScript.
Instead of forcing your users to download the entire Sodium library, you might opt to implement a compatible construction using JavaScript implementations of these primitives.
Since you have trusted implementations to test your construction against, this should be a comparatively low-risk effort (assuming the primitive implementations are also secure), but it’s not one that should be undertaken without all of the prior experience.
Note: At this stage you are not implementing the primitives, just using them.
Hard Difficulty: Designing Protocols and Constructions
Repeat after me: “I will not roll my own crypto before I’m ready.” Art by AtlasInu.
To distinguish: TLS and Noise are protocols. AES-GCM and XChaCha20-Poly1305 are constructions.
Once you’ve implemented protocols and constructions, the next step in your self-education is to design new ones.
Maybe you want to combine XChaCha20 with a MAC based on the BLAKE3 hash function, with some sort of SIV to make the whole shebang nonce-misuse resistant?
You wouldn’t want to dive headfirst into cryptography protocol/construction design without all of the prior experience.
Very Hard Mode: Implementing Cryptographic Primitives
It’s not so much that cryptography primitives are hard to implement. You could fit RC4 in a tweet before they raised the character limit to 280. (Don’t use RC4 though!)
The hard part is that they’re hard to implement securely. See also: LadderLeak.
Usually when you get to this stage in your education, you will have also picked up one or both of the traditional paths to augment your understanding. If not, you really should.
Nightmare Mode: Designing Cryptography Primitives
A lot of people like to dive straight into this stage early in their education. This usually ends in tears.
If you’ve mastered every step in my prescribed outline and pursued both of the traditional paths to the point that you have a novel published attack in a peer-reviewed journal (and mirrored on ePrint), then you’re probably ready for this stage.
Bonus: If you’re a furry and you become a cryptography expert, you can call yourself a cryptografur. If you had no other reason to learn cryptography, do it just for pun!
This blog is enjoyed by a few people (mostly technologists, furries, and furry technologists), but it’s not really providing a service that anyone would pay for. There is no “team” behind it. There is no monetization strategy or business plan. It’s just some nerd with “cringe” hobbies/interests that likes to write things far too long for Twitter.
I’m not telling you all this to be self-deprecating. I’m saying it to level out expectations.
Every once in a while, one of my blog posts reaches escape velocity and gets noticed by a larger Internet community. This leads to a stark increase in comments from people wanting to “debate” me. There is no more prominent example of this than my blog post
... mehr anzeigen
My Blog Isn’t a Platform for Internet Randos
In the grand scheme of things, I’m a nobody.
This blog is enjoyed by a few people (mostly technologists, furries, and furry technologists), but it’s not really providing a service that anyone would pay for. There is no “team” behind it. There is no monetization strategy or business plan. It’s just some nerd with “cringe” hobbies/interests that likes to write things far too long for Twitter.
I’m not telling you all this to be self-deprecating. I’m saying it to level out expectations.
Every once in a while, one of my blog posts reaches escape velocity and gets noticed by a larger Internet community. This leads to a stark increase in comments from people wanting to “debate” me. There is no more prominent example of this than my blog post about the dumb “sigma male” grift that became a meme.
The dumb comments on that post–which I will never approve–became so tiring that I left a comment at the bottom to ward off would-be debate-bros.
I’ve received a lot of inappropriate comments on this blog post, in particular. If you disagree, write your own blog post to rebut what I wrote instead of expecting me to approve your comments.
This prompted another rando to leave the comment featured prominently in the header:
You could just approve the comments. I’m sure nobody is trying to hurt your feelings; a civil conversation of disagreement should be allowed. Peace brother 👍
Fucking incredible. I’m having flashbacks of the sealioning on Twitter back when the anti-feminist movement “GamerGate” was in full swing.
Since some people are confused, allow me to clear up some misconceptions about this blog–and the comment policy it adheres to.
Comment Moderation Policy
This blog is not a public service provided by any country’s government. It is not the work of any company or business.
Nobody has the right or privilege to have their words platformed here, except myself.
I pay roughly $100/year for the privilege of being able to write about things that interest me without having to fuss over hosting infrastructure or secure application design. (Like hell I would self-host WordPress and be responsible for maintenance! I’d never find time to write anything!)
One big motivator for this blog–instead of, say, a Medium page–is that I can write the things I want without being pressured to paywall my content, and without advertisers getting their filthy hands all over my ideas. Having no real incentives allows me to write what I want, how I want, and when I want.
It doesn’t matter if it’s a “civil conversation of disagreement”, or the hundreds of comments I get every year (post spam filter) telling me to kill myself for being gay and/or a furry.
Whether a comment gets approved or not is decided at my sole discretion, and my answer will almost always be, “No.”
If you believe you have a right to Free Speech that this policy might hypothetically violate, you’re more than welcome to start your own goddamn blog and write your opinions there. I don’t owe you or anyone a damn thing.
This isn’t censorship, it’s called having personal boundaries.
If you can’t tell the difference between personal boundaries and an attack on your “rights”, please do the world a favor and permanently remove yourself from the dating pool before you hurt someone.
Starting a blog is easy. Maintaining one can be challenging.
If you believe what you have to say is important enough to get published somewhere, go put the time and money into building your own platform instead of demanding access to the one I built.
That being said, by all means, continue to write your comments. Just don’t expect me to blindly approve them all just because you wrote them. The overwhelming majority of comments I receive get chucked in the trash bin.
Before I get into this story, I feel it’s important that you know where I’m coming from. But if you don’t care about that, feel free to skip the Background section.
The ability to freely share my knowledge and experience with others is one of the privileges granted to me by modern technology. I’m further privileged to be able to afford to live through my career in computer security, and to never be desperate enough to have to choose between personal integrity and survival.
To be clear: My resistance to compensation here is simply to avoid perverse incentives, not to throw shade at people who lack the privileges I do.
It has to be known that I’ve been pretty open about my stance against paid promotions, from my 2020 year in review blog post to the absence of any payment information (Ko-Fi, PayPal.me, Patreon, etc.) on my blog. I certainly have those things, but they’re utterly divorced from what I’m doing here.
My attitude about gratitude towards anything useful I write on this blog (e.g. the Furward Momentum series) is simple: Pay it forward. (And if you can’t pay it forward, what good would a sense of debt do you? People care. You’re worth caring about.)
An Internet Marketer Offered Me $100 to Betray Myself and My Community
In March 2021, I received an email from someone named CJ Hankins, who purported to be an Outreach Executive of Wise Marketing (although their name is suspiciously absent from their “Meet the Team” page).
In this email, CJ Hankins offered to pay me $100 to publish an article on this blog.
Hi,
We have read your content on soatok.blog and would very much like to contribute an original article for your consideration. The said content would be exclusively written for your site.
Within the article, we would place a reference to one of our clients and for this request, we are able to pay $100 (via PayPal).
Please let us know if this is something you would be interested in.
We are ready to send a draft or a sample piece for your perusal.
Yours sincerely, CJ
[signature snipped]
P.S. Message sent through Gmail due to technical issues with my primary work email account.
If I were anyone else blogging about cryptography, I’d probably ignore the email entirely. If I felt generous, I might politely decline. If they persisted, I might reply with a hearty “fuck off” and setup a filter to ensure any subsequent emails from their company skip my inbox.
That’s the mature, professional, adult thing to do.
But wouldn’t it be funny if they tried to write an article in my usual style–complete with my usual smattering of art of my fursona throughout the prose?
If you’ll notice, I didn’t commit to any sort of agreement in my reply. I asked if they had a sample available and expressed curiosity.
Their reply came nearly a week later, and I need to emphasize something in their next email, so I’ll make it bold. (In the original email, it isn’t.)
Hi Soatok,
We are very happy you have gotten in touch. Here are the details of the next steps.
A professionally written and edited draft will be sent for your approval in the next few weeks. Please let us know if you have specific editorial requests or guidelines you want us to follow. Or if you feel the topic needs some work or adjusting. We will be ready to make any changes you see fit.
In the article we will need to mention our Online Gaming client. Another point is that the live article cannot have any label. If this is in breach of your guidelines, don’t hesitate to get in contact so we can figure out if there is any other way forward.
Warm regards, CJ
P.S. Message sent through Gmail due to technical issues with my primary work email account.
Up until this point, I had already suspected that this outreach was an attempt at what marketers call native advertising. What I didn’t expect was for them to try to get their targets to deceive their audience.
If you’re not familiar with native advertising, this Last Week Tonight video is worth watching for a primer.
Even when clearly labelled, native advertising is deceptive, but in sort of a gray area way: If you’re keen enough to notice the label, you’ll realize you’re reading an ad. If you’re not, you might get fooled, but you only have yourself to blame for not being perceptive enough. This is kind of a bullshit argument, but humans are good at rationalizing their misdeeds.
Native advertising without any sort of label? That’s indefensible, even by the above bullshit argument’s standards.
I did not reply to CJ’s email, and they went quiet for a few weeks, until they finally delivered the proposed article for me to publish.
Hi Soatok,
I hope you are well and have had a good week. The reason for this email is that I now have the article to put on your site. Please see attached Word document file.
Please make any small changes to the text that you see fit, but we do ask that you keep the tone of the article and do not alter any of the anchor text. This article was written exclusively for your website and is not a duplicate.
If you agree to put this article on your blog/homepage, please do so as you usually would so that it appears at the top of the page before eventually being replaced by a newer article.
Please publish the content if everything meets your satisfaction. We will then do a final check and immediately transfer the agreed fee via Paypal.
If you have any concerns or questions let me know.
Cheers,
The attached word document was titled, How Cryptocurrency is Making Online Gaming Safer. The purpose of the deceptive advertisement was to promote an online gambling platform from a company called Foxy Games. (The document is included with the emails if you’re curious.)
“Sick fursona, bro.” (Cropped screenshot of the Foxy Games website, which breaks archive.org.)
Who’s Running This Shitshow?
Foxy Games is operated by ElectraWorks Limited, which (in a twist that will surprise no one) was hit with a fine in 2018 for repeatedly breaching advertising standards.
However, Foxy Games is also a brand owned by the Entain Group. This split ownership model makes it difficult to pin down who’s exactly responsible for the unethical behavior we’re seeing here.
To make matters more frustrating, as noted above, CJ claims to work for a marketing firm (Wise Marketing) that doesn’t list them on their personnel page.
Even if we assume CJ is an actual employee of Wise Marketing, there’s no evidence that ElectraWorks Limited or the Entain Group is aware of the unethical behavior of their vendors.
But let’s be real (and, disclaimer, what follows is just my speculation):
This sort of corporate model, combined with the use of third parties, sure seems carefully constructed to minimize legal liability without actually complying with regulations.
The vendors do the dirty work. If one gets caught, then, at worst, the client simply terminates their contract and maybe issues a banal press release insisting they didn’t know and do not condone this behavior, and then proceed to change nothing else.
The fact that CJ Hankins isn’t listed could be explained by any of the following hypotheses:
The webmaster is lazy and doesn’t update the team page frequently.
CJ doesn’t actually work for them (either as an employee or contractor).
Wise Marketing wants some sort of legal deniability to keep their contract with e.g. their client related to Foxy Games.
I don’t know which one is more likely to be true; it’s anyone’s guess, really. I’m sure the “my work email isn’t working so I’m using gmail” is totally legit.
Is Cryptocurrency Making Online Gaming Safer, Though?
Cryptocurrency is not making online gaming safer. Also, there’s a huge difference between online gaming (e.g. World of Warcraft) and online gambling (which they insist on referring to with “gaming” as a euphemism for gambling, which is stupid and I refuse to do that).
I could speculate further on many reasons why cryptocurrency would be an attractive subject for gambling companies, but I ultimately think it has a lot more to do with blockchain hype and reaching new audiences than anything more strategic (e.g. avoiding retributive chargebacks from gambling addicts who bleed their bank accounts dry and run up a massive credit card debt trying to win big).
Bloggers Beware
For reasons I’ve explained above, I have no temptation to accept their offer of $100 to deceptively promote an online gambling client through an unmarked native advertisement on this blog.
However, I’m certainly not the only blogger they approached with this sort of offer. And I certainly won’t be the last.
A lot of people do blog because they want to make money online, and these kind of marketing opportunities can be incredibly enticing especially if you’re in a financially desperate situation.
But is $100 really worth sacrificing your personal integrity forever?
Personally, I’d rather pursue a career drawing erotic furry art for random people with increasingly specific kinks than deal with this nonsense.
Closure
As I started writing the draft for this blog post, CJ sent me another email.
Hi Soatok,
How are you? I sent our proposed article “How Cryptocurrency is Making Online Gaming Safer” last week. Did you receive it? If not, kindly let me know and I’ll be happy to resend the copy.
I look forward to hearing from you again. Have a great day!
My response (which will be sent as soon as this post goes live) is as follows.
Hi CJ,
In my previous response I had expressed curiosity and asked for a sample. I didn’t expect you to deliver the entire completed article for review without further discussion.
Upon review of this article, I must admit that it doesn’t live up to my strict editorial standards of bad furry puns or fursona art between paragraphs.
Given the reason above, I don’t wish to move forward with this transaction, and I’m not interested in the $100. However, since you put forth the time to write this post, I just might share it with the world for free.
Regards, Soatok
Here’s hoping the entire internet marketing industry puts me on a “do not contact” list after this.
One of the funniest concepts for a YouTube channel has to be TierZoo, which treats the animal kingdom as an MMORPG and animal species as different classes within this hypothetical game, and then proceeds to analyze it the same way gamers analyze the “meta” for a given season of a game.
Tier lists are just one expression of a mental model called a hierarchy. Hierarchies can be useful concepts in science (e.g. Maslow’s Hierarchy of Needs), but they’re woefully deceptive and should not be used socially.
Why Hierarchies Are A Poor Fit for Social Purposes
In video game terms (for the TierZoo fans in the audience), the PvP meta rarely implies the PvE meta. This is the essence of the problems with viewing society through the lens of a hierarchy.
Using hierarchies for any social purpose is li
... mehr anzeigen
Against Hierarchies
One of the funniest concepts for a YouTube channel has to be TierZoo, which treats the animal kingdom as an MMORPG and animal species as different classes within this hypothetical game, and then proceeds to analyze it the same way gamers analyze the “meta” for a given season of a game.
Tier lists are just one expression of a mental model called a hierarchy. Hierarchies can be useful concepts in science (e.g. Maslow’s Hierarchy of Needs), but they’re woefully deceptive and should not be used socially.
Why Hierarchies Are A Poor Fit for Social Purposes
In video game terms (for the TierZoo fans in the audience), the PvP meta rarely implies the PvE meta. This is the essence of the problems with viewing society through the lens of a hierarchy.
Using hierarchies for any social purpose is like comparing two individual frames from different videos of people speaking. If you select an unflattering frame from one person mid-word and juxtapose it with a frame of the other person pausing for dramatic effect, you can bias your audience’s perceptions of the two people.
Without knowing the personalities involved, which person looks like an utter blowhard in this framing?
Some people like hierarchies because they seem real and “natural”: If you worked hard in school, you might graduate in the top 10% of your class.
“Wouldn’t it naturally follow that scholastic achievements yield a hierarchy that reveals both intellect and diligence? Shouldn’t the top performers earn the most rewards?”
No, and no. Academic grading isn’t a robust scientific model for measuring capability, it’s an ad hoc tool for scaling up one teacher to many dozens or even hundreds of students. People with economic advantages (e.g. not needing to work 2-3 different jobs just to afford college) are also more likely to have time to prepare for tests, and therefore earn higher grades.
But more importantly, we’re still talking about narrowly scoped snapshots of reality that miss entire dimensions. How many mathletes in school were loathe to put out an essay on some arbitrary prompt in under an hour? How many prolific writers left school thinking, “I suck at math”?
Hierarchies Can Be Real, But Still Useless
The social hierarchies people talk about the most are usually about power–which either means money, violence, or social connections with others more capable of wielding money and/or violence.
This video from Innuendo Studios explains this concept rather well, especially as it pertains to how political conservatives (and, indeed, most people living in capitalist societies) tend to view them:
If you only measure one variable across a population, a hierarchy will likely emerge. And it might seem very much like a fact.
If you collect a diverse sample of many independent variables, this hierarchy will begin blur and everyone will tend towards mediocrity.
Jeff Bezos and Bill Gates certainly have more wealth than I do, but I’m probably better at mathematics and cryptography than both of them. Which variable matters in a given situation is heavily context-dependent.
At the end of the day, social hierarchies are lazy oversimplifications, and the people who rely on them when they think about the world are lying to themselves through omission.
Listicles Considered Harmful
The worst offenders in using simple-minded hierarchies to analyze societies are the bloggers and YouTubers who create “Top 10” articles and videos.
It isn’t enough for these jerks to just enjoy the plot twists and betrayals in their favorite works of fiction; they have to pit them against each other so they can rank them.
Responsible Use of Hierarchies
It’s particularly difficult to get away from hierarchies in our society, especially when it’s staring you in the face. (“Why can’t we complete a Mythic Plus 10 on our favorite characters?” “Because they’re not this season’s meta.”)
“So what are we supposed to do then? Lie to ourselves?” Nope.
You can acknowledge that hierarchies exist (when they actually do) while also acknowledging that they’re only parts of the whole picture.
Additionally, some hierarchies only exist because of correctable sources of corruption and bias within our society, and those should be resisted.
Hierarchies Beget Depression
One of the quickest and surest ways to make yourself feel depressed or anxious is to compare your behind-the-scenes footage to other people’s highlight reels. This is one of the great ills of social media.
Hierarchies exacerbate this problem by introducing numbers and metrics that appear to be objective, but really aren’t.
Need an example? Here’s two videos that, I think, illustrate what I’m talking about perfectly.
RL has only had a YouTube channel since 2017, and already has nearly 1000 more subscribers than Doon (3.97k vs 3.19k).
RL’s video has more views than Doon’s (608 vs 488).
RL’s video has more upvotes than Doon’s (100 vs 98).
Does this mean RL is more successful than Doon? The numbers sure say so! And yet, RL is clearly unsatisfied, while Doon seems perfectly content with his channel and its growth over the years.
Who appears to be happier in these videos?
In Conclusion
Hierarchies can lie, and they always lie through omission.
Humans are complex creatures that have many dimensions to our lives, and cannot be reliably compressed to a few bits of information. Any attempt to do so loses something; and what it loses, is often our humanity.
That doesn’t mean I don’t write about it when it’srelevant, but I’m always less happy with any of my writing that touches on these subjects. I usually feel obligated to condemn these pieces to Draft status in perpetuity.
It’d be great if we lived in a world where I could opt out of political discourse entirely, but that only exists when you have the systemic advantage in our imperfect society. And since me being LGBTQIA+ is
... mehr anzeigen
Politics? In My Fandom?
I dislike politics in general.
That doesn’t mean I don’t write about it when it’srelevant, but I’m always less happy with any of my writing that touches on these subjects. I usually feel obligated to condemn these pieces to Draft status in perpetuity.
It’d be great if we lived in a world where I could opt out of political discourse entirely, but that only exists when you have the systemic advantage in our imperfect society. And since me being LGBTQIA+ is unavoidably political, and we’re a minority, opting out of politics means submitting to whatever dark fate toxic people decide I deserve.
Now, you’d think that the furry fandom–a community that is at least 80% LGBTQIA+— would be loudly and consistently opposed to bigotry in all forms.
(Drumroll, please?)
The creator of the Rexouium species in VRChat is strongly anti-gay, and in the species’ official Discord you can discuss lots of things, but not homosexuality (this isn’t about NSFW or not, that’s a separate rule).
I tried bringing this up privately, but most folks said “…so?”
And then (if that weren’t vexing enough) some random furry decided–in response to Silver complaining about that dude’s conduct–to spite-buy a model from the homophobic bottom-feeder, thereby rewarding the dude because “cancel culture” or something.
As I’m writing this, we’re also a few weeks away from another election in the United States, and on day two of Senate hearings to nominate yet another conservative to the highest court in the land.
So, to my chagrin, let’s talk about politics–a necessary evil because there’s so much unnecessary evil when we don’t talk about it.
My Political Positions
Rather than leave divining my political values as an exercise to the reader, let’s just get some of this out of the way up front. If you don’t particularly care, feel free to skip to the next header.
I’m in favor of responsible gun ownership and the right to self-defense, science-directed education efforts, decriminalization and legalization (but regulation!) of most controlled substances, restorative justice for past criminal offenders, universal health care, reducing police funding to funnel it into social workers to care for our communities in ways that armed cops can never provide, legal and social recognition of polyamory as a valid relationship style, racial and gender equality, encryption and online privacy protections, and equal rights and necessary legal protections for LGBTQIA+ people.
I’ll cover what I’m opposed to later, but if you’re looking to pigeonhole me into some convenient label, the answer you’re looking for is whatever the sum of all that is.
I personally don’t care for labels. That isn’t to say I don’t take sides in a conflict, but that I don’t anchor my personal identity and sense of purpose in life to an ideological tribe. And most of the labels people use are a poor fit for my opinions at any given snapshot of my life.
Note: This summary is current for October 2020 and I’m at liberty to change my mind about this topic at my sole discretion and without explanation. If some jerk-off tries to refer back to this post years down the road, make sure you also point to this paragraph while calling them a dishonest dipshit.
In a Nutshell: Fuck Tradition!
I really don’t like tradition.
Tradition is often defined as, “a long-established custom or belief that has been passed on from one generation to another.”
But what tradition in practice really means is, “We’ve always done things this way, so why do things differently?”
Relying on tradition to solve life’s problems and codify one’s beliefs means abandoning the possibility of creative thought. It means relying on the default choice to make decisions, rather than trying to improve upon the world we inherited from past generations, and solve problems more effectively.
Why use AES when we already have a perfectly serviceable block cipher–DES–to build our software atop? Nevermind the tiny security margin! My parents used DES in their software and their parents used Vigenere ciphers. So you see, we’ve already compromised on a modern solution. Pushing for AES is just leftist extremism and postmodernism.
What appeals for tradition sound like to cryptography nerds.
Love for tradition is what makes a lot of very religious people vulnerable to the Siren song of right-wing extremism (which includes, but is not limited to, fascism).
Tradition is toxic, and the only way we can make it non-toxic is to severely reduce the dose we all intake.
Let me be clear: It’s fine to have traditions. Humans are habitual creatures, and at their core, traditions are just habits and ideas you inherited.
A lot of your traditions are probably even fun and wholesome! And I applaud you for practicing them if it makes you happy.
The problem comes from people who rely on tradition to inform their political beliefs. They base their decisions on adhering to the mistakes of the past instead of learning from history.
“I’m not homophobic, I just believe in the traditional definition of marriage,” says the person whose knowledge of the history of marriage is extremely limited by a recency bias, right before they vote to deprive gay people of the same civil rights they enjoy.
If you’re relying on tradition because a newer, better idea hasn’t come along yet, that’s also fine. Provided, of course, you’re open to new ideas and actively exploring your curiosity.
Systems and Models
There are two incompatible mental models for how society should be organized: Flat and hierarchical.
A flat structure is typically more aligned with politically far-left ideals. Even if they’re not outright in favor of egalitarianism, they’d prefer equal opportunity and for justice to be blind to things like color and sex.
A hierarchical structure is typically more aligned with politically conservative ideals. “There’s always a bigger fish.”
This incompatibility in the core worldview of liberal-leaning and conservative-leaning people shines through in most of the points they argue about.
And if you pause for a moment and reflect on this, it’s abundantly clear why the left and the right never seem to agree on anything. To a liberal, social and economic inequality is a problem to be solved. To a conservative, this is the way things should be.
“CLOSED. WONTFIX. Works as intended.”
Here’s the rub: In any particular area, some of us will score higher on an arbitrary metric than others.
I might be better at writing robust and reliable PHP code than you, but you’re almost certainly far better than me at anything musical in nature. Odds are, neither of us can hold a candle to Michael Phelps in a swimming competition.
This isn’t a bug, this is a feature.
Diversity and specialization are one of humanity’s superpowers.
However, depending on how you’re collecting your data, this also naturally leads to the creation of hierarchies in our society. It doesn’t matter what you’re measuring, the hierarchical structure usually emerges. To wit:
This phenomenon is a deception from bad data modelling and poor systemic thinking.
Ask yourself this: Does scoring higher on some arbitrary metric make you a superior person to anyone else?
When you look in a vacuum, hierarchies seem natural. When you look at the whole system with lots of independent measurements, we tend to average out to mediocrity.
And when you consider the reason that conservatives love hierarchies is that the measurements that the powerful have agreed are important are also the same ones that puts them and people like them on the top of the pyramid, it’s difficult to justify the hierarchical worldview.
If you ignore all other factors–ceteris paribus–and only look at this single variable, me and people that look and talk like me are superior to everyone else. There has to be an alpha, so it naturally falls upon us to lead society and benefit from our leadership.
The essence of hierarchical worldviews
The other reason conservatives love hierarchies is because they’re reinforced by tradition.
But just as driving a lifted pick-up truck won’t make your dick bigger, being wealthy and powerful doesn’t make you more enlightened or better at critical thinking.
Mass Manipulation
A lot of political disagreements result from propaganda, rather than the actual state of affairs.
For example, let’s look at the conflict about women’s right to abort a pregnancy. This is a contentious issue (and the primary motivation for the Republican Party’s court-stuffing initiatives), but here’s the truth of it:
Regardless of what you believe on this issue, we actually want the same thing. We want there to be no abortions. How we plan to achieve this outcome is what differs.
The conservatives believe in making abortions illegal (for reasons that vary from person to person and aren’t exclusively religious).
The liberals believe in preventing pregnancies from happening in the first place, but also keeping the procedures legal and readily available for medical emergencies that threaten the life of the mother.
Some people love to twist these positions around and give each camp cute names that serve their political purposes, but that’s the core position of each side.
Being pro-choice doesn’t mean you want there to be more abortions.
There are many pro-choice women that would personally never elect to have one unless their life was in immediate peril, and would find the experience psychologically traumatizing.
Abortions suck. Criminalizing them just makes them suck worse, and puts more women’s lives in danger.
If we could prevent unplanned pregnancies from happening in the first place–without attempting to suppress healthy human sexuality–we could get the number of abortions to near-zero. With better investment in the sciences and especially medical research, there may even be hope to one day reach the goal.
But if you pay attention to the discourse on this topic, this nuance is papered over. Conservatives call liberals godless baby-killers. Liberals call conservatives women-hating puritans.
Nobody wins.
There are, of course, some people whose involvement in the political discourse is to maximize cruelty. A good example of this is the Republicans who pass legislation forcing women to listen to their fetus’s heartbeat before aborting it. There’s no medical reason for such a requirement. It only exists to increase the psychological trauma the woman experiences; to punish them for being forced to choose. These ghouls aren’t what I’m talking about above. Fortunately, sociopaths are somewhat rare compared to the rest of the population.
Against Tired Narratives
Everyone is the protagonist in their own story. And while society’s problems are far more complicated than “good vs. evil”, you hear the same tired narratives echoing from all directions all the time.
Is an economic hierarchy nigh-inevitable under systems which have trade and commerce (as opposed to central planning)? As far as I know, yes! After all, there aren’t enough factors that lead to wealth to yield a flat structure.
Does that mean we shouldn’t strive to shrink the distance between the top of the hierarchy and the bottom? No, and fuck every tradition that insists otherwise.
Do not let other people’s narratives dictate what you think and feel. Especially mine!
The best cure for propaganda is also a remedy for tradition: Questioning things.
People who decry cancel culture are advocating for negative peace.
Negative peace is toxic, because it reinforces the status quo (which was largely engineered by bigots that died a long time ago) and ignores the reality of the human experience.
One of the consequences of diversity is that social friction is inevitable. This almost always leads to some form of conflict. Conflict can be healthy.
Valuing your escapism over the safety and well-being of the rest of your community is the epitome of being self-centered. (Need I remind everyone that narcissism is a personality disorder?)
If you want things to “go back” to the days “before cancel culture”, the only way we’re going to get there is if you help us take out the trash today.
Stop living in the past.
We can achieve so much more if we focus on the present and strive towards a brighter future.
A Brighter Tomorrow
I’m not going to pretend that voting blue will solve all the world’s ills. Setting aside how fucked up the DNC is, a lot of democrats are too conservative to ever let real change happen. (They’re also allergic to strategy and fetishize “bipartisanship” when their opponents are only interested in domination and power at all costs.)
However, the other major political party in the United States is so much worse on all fronts that we’re pretty much forced to vote for harm reduction instead of supporting the leadership that we really want.
I don’t expect anyone to change how they vote because of the words I wrote here today, and that’s not my goal.
Real change often happens between elections. Gay marriage was the result of thousands of activists, not the generosity of our sitting President at the time.
Deplatform all of the bigots. Make them feel unwelcome in our spaces.
Make them choose: You can either be a member of our community, or a hateful piece of shit, but not both.
Aside: Anyone who finds themselves dealing with right-wing, Trump-supporting bigots–whether or not they’re also furries–should check out this series on the alt-right playbook before engaging with them at all.
At the same time, keep the opportunity for restorative justice in mind: People who want to get away from hate need an exit strategy.
If you’re racist, sexist, transphobic, homophobic, or otherwise prejudiced against people who aren’t hurting anyone, you don’t deserve the warmth and positivity of the furry fandom.
This means risking being accused of being part of “cancel culture”, but fuck it. I sleep better knowing my friends don’t secretly pray for me to stop being me, and who I am is a very gay furry.
Nerd and online communities are a ripe harvesting ground for neo-Nazism. Bigotry festers like a wound and preventing society and subcultures from going gangrene is about knowing the warning signs…
As America prepares for record-breaking infection statistics on a daily basis, many of us are looking at other countries safely reopening and wondering, “Why can’t we have nice things?”
What you see if you type “COVID-19 statistics” into a search engine. Data sourced from Wikipedia.
Of course, everyone has their favorite target to blame for this catastrophe. Democrats blame Republicans. Republicans blame Democrats.
I’m not interested in blame. Regardless of who takes the blame in the end, the responsibility for fixing this problem is shared among everyone. Instead, I’m more interested in answering the “Why?” question.
There are a lot of popular theories–many of them politically useful–about why the COVID-19 crisis is particularly bad in the United States.
A Failure of Trump’s Leadership?
Let’s get this one out of the way:
Was the current hellscape we found ourselves in a direct consequence of Donald J Trump’s failure to ethically and responsibly use his power as President of the United States in the best interest of the people?
That is not to say that Trump is without fault! Just that the problem is bigger than one idiot in a three piece suit.
Challenges Due to Scale?
A lot of the countries that performed better at responding to COVID-19 had smaller populations and occupied smaller land masses than the United States. Is that a reasonable explanation for why the USA suffers?
Per-capita analyses and samples from other countries with similar populations and occupied surface area would be consistent with the USA if that was the reason. This problem is mostly uniquely American.
The first signs of an uptick in COVID-19 infections was visible early into the nationwide Black Lives Matter protests, which implicates an earlier cause. The most likely one was the Memorial Day weekend celebrations that took place before George Floyd’s murder sparked widespread outrage.
Indeed, a further analysis did not show an uptick of COVID-19 infections even 4 weeks into the nationwide protests (which is two incubation periods).
Instead, the sharp spike in COVID-19 infections–factoring in the incubation period–coincided with states reopening their bars and restaurants. (Especially Florida.)
Why Things Are So Bad Today
The problem that America faces is the same one we’ve been faced with for many decades: Rampant Anti-Intellectualism.
Tweet is also archived in case it gets deleted. Anti-intellectualism takes many forms:
Every single time y'all tell me you're not ready to submit a talk on a subject you've been researching for months, I want you to think about "I don't actually ride in Ubers" internet-commentator guy. pic.twitter.com/aK2LAcFtzb
People are so willing to die on the hill of their ignorance that even literally dying doesn’t deter them from campaigning for self-destruction.
RIGHT NOW: Dozens are marching in Sanford chanting “My body. My choice.” They are protesting after a mask order went into place in Seminole County today. pic.twitter.com/kMT7EebDKN
— Stephanie Buffamonte (@StephBuffamonte) July 1, 2020
The reason that things are so bad in the United States of America boils down to the following:
Too many Americans are proud to be ignorant, and in many cases, argue in support of “my ignorance is just as good as your facts”.
Too many Americans are susceptible to bullshit conspiracy theories.
Too many Americans are so selfish and short-sighted that they’d rather go to bars and waste money they don’t have on alcohol and shallow conversation than save the lives of the people they profess to love and care about.
Conservative politics and media is a death cult that literally turned “wearing a mask to stop COVID-19” into a culture war issue.
The people I’ve described in points 1-4 vote in every election, to make sure someone representing their bullshit has a seat at the political table.
It’s far too tempting to scapegoat the sitting President–especially when they’re as terrible as Donald J Trump. But if you do that, you’re ignoring the reason that he’s in the oval office to begin with.
Willful Ignorance Kills
I’ve talked about this before, when I used to write on Medium:
The only way to get out of the mess we’re in today is to stop tolerating ignorance and bullshit in your daily life. (Yes, this means you too, furry fandom! It’s not “all fun and games” anymore.)
Even if we manage to get out of the current COVID-19 hellscape without addressing these flaws, the next catastrophe will hit us just as hard.
Can People’s Minds Be Changed?
No. I don’t think most of the willfully ignorant assholes currently living in America that favor Trump’s presidency today are willing and capable of redemption.
There will be exceptions, and we should remain open to the possibility of some people coming around, but in general most of these jerks will dig their heels in when pressured.
Instead, we’re going to have to wait for them to die off naturally.
What we can do in the meantime is promote better education for the American kids.
A nation of enlightened free-thinkers fully capable of critical thought would be a good thing (even if Carlin thinks it will never happen). And we can get there, eventually.
All it takes is everyone deciding to be humble and actually verify what other people tell them (n.b. by referencing reputable sources).
It might not make a difference today, but in 10 or 20 years, a consistent effort to enable younger Americans to become smarter, wiser, and more empathetic than their parents and grandparents will change the political landscape of our country–and maybe even the world–for the better.
Of course, the Powers That Be know that, which is why we see bullshit like this keep happening during a pandemic:
With a stroke of his veto pen, Gov. Ron DeSantis wiped out the entire $29.4 million budget for a suite of online education services that have become critical to students and faculty during the Covid-19 outbreak t.co/6PMop4SIPv
Remember, DeSantis is the governor of the state whose COVID-19 infections-per-day graph looks like this:
You can see a clear data pattern with Florida's COVID-19 with a lull each Sunday. I've computed the baseline for this week (Sunday's numbers) and the last two weeks' increase relative to Sunday. We're easily on track to hit 10,000 new cases Friday-ish, maybe even higher. pic.twitter.com/8pnXF5uEwR
It won’t be easy. Bullshit is everywhere. But it’s doable.
Addendum: A Carnival of Stupid
In case you still had any doubt about the potent lethality of American anti-intellectualism, look no further than this story:
Florida teen dies after conspiracy theorist mom takes her to church ‘COVID party’ and tries to treat her with Trump-approved drug: report – t.co/Bw3SMVitxx
A Florida mother allegedly took her high-risk teenage daughter to a youth group event at their church, tried treating the girl at home with unproven drugs when she got sick -- and then hailed her as a patriot after she died.
“Sigma Male” is a ploy to recruit insecure young men into the same involuntary celibate (incel) / anti-feminist / pick-up artist trifecta that’s been making the Internet a worse place for everyone since at least 2005, and an evolution of the widely debunked “alpha male” myth.
... mehr anzeigen
No, You’re Not a “Sigma Male”
The year 2021 has taught us, if nothing else, that we can be sure that lies, misinformation, and bullshit are post-scarce resources in modern society.
In such an information economy, it should come as no surprise–yet an abundance of disappointment–that ideas like the “Sigma Male” even exist.
“Sigma Male” is a ploy to recruit insecure young men into the same involuntary celibate (incel) / anti-feminist / pick-up artist trifecta that’s been making the Internet a worse place for everyone since at least 2005, and an evolution of the widely debunked “alpha male” myth.
Trust me on this one, guys: I’m a gay furry. The whole alpha/beta dynamic gets referenced a lot by neophytes to furry/kink culture. Sometimes we entertain it as harmless fun, but practically no one (especially with a canid fursona) takes it remotely seriously.
When the career date-rapists and grifters behind the pick-up artist and “alpha male” circle-jerk realized that their audience was becoming disillusioned by the fact that their attempts to act “more alpha” was not resulting in healthy sexual or romantic relationships with women, they decided to invent a totally new concept–divorced of any psychological basis, of course–in order to keep their audience faithful to their bullshit and ensnare additional desperate, insecure young men.
Since trying to act “more alpha” just makes most people total jerks, which results in women running away as fast as they can, they decided to invent a more-hipster alternative for the failures in their revenue base to aspire to: One of silent edginess and marked by deliberate rejection of social structures. Since nothing comes before alpha in Greek, but video game culture places S-Rank above A-Rank, they decided to opt for the label “Sigma”.
Naturally, this results in a litany of book deals, YouTube videos, and public relations to sell their audience the idea that achieving this fictional aspiration is “what women really want”. The proposition here is, “If you know what women really want, you can get what you really want from them.” (i.e. sexual gratification).
It’s not just gross. It’s also a kind of exploitative that begets more exploitative behavior.
The same crowd that invented “Sigma Male” also conceived “negging”.
Here’s an actual list of “qualities” ascribed to a so-called Sigma Male, according to one of the peddlers of this moronic belief, only rearranged to emphasize the contradictions and meaninglessness of this description:
“SIgma Males” are…
…but also apparently…?
10. He’s Incredibly Self-Aware
14. He Can’t Be Told What To Do When It Comes To Anything
13. He Could Be an Alpha If He Wanted
4. He Treats Everyone Around Him The Same Way
2. He Is a Silent Leader
9. His Social Skills Could Use Some Work
6. He Understands the Importance of Silence
12. It’s Hard To Understand Him
1. He Loves Being Alone, But He Values Other People
3. He Knows How To Adapt To Different Situations
11. He’s the Master of His Own Fate
8. He Hates Living Life Safely
5. He Doesn’t Need a Social Circle To Be Himself
7. He’s Morally Grey, Or Worse
A lot of words could be written about these contradictory or vacuous statements.
How can you be a leader with inadequate social skills? If he really understands the importance of silence, why is it hard to understand him? Sure sounds like he’s misusing silence to me. Who isn’t a master of their own destiny? Who does need a social circle to be themselves?
The “Sigma Male” con is what happens if you take the tactics of cold reading and apply them in reverse:
Instead of starting general and drilling down to more specific based on your audience’s response, you start specific (“rarest type of male”) and then generalize the definition to become completely meaningless while also maximizing the relatability of the label to catch unaware rubes off-guard.
While we’re on the subject of some of the sleaziest pieces of shit to ever walk the earth, let’s examine some more crimes against culture by these self-aggrandizing embarrassments to the male gender.
The “Friend Zone”
If you want to doom someone to a lifetime of unhealthy relationships, convince them that there’s this tragic place called the “Friend Zone” wherein, if someone you’re attracted to views you as a “friend”, you’re doomed to never have sexual relations with them.
If you’ll notice, I omitted gender in the previous paragraph. This one is so pernicious that I occasionally encounter it in the LGBT community.
For adherents to this particular cognitive distortion, relationships exist in a linear hierarchy:
Spouse–You want to be here
Significant Other
Friends with Benefits / Sexual Partner
Friend (Platonic)–You don’t want to be here
Acquaintance
Stranger
Friendship isn’t valued on its own merits. Instead, it’s a stepping stone; a mere transitional fossil between where you are and where you want things to be. I’ve talked about this before.
When someone adheres to this belief, it shapes the way they interact with people they’re attracted to, and often creates a negative feedback loop. This in turn gives rise to the incel (involuntary celibate) mentality–except now, it’s almost always by men against women.
Failure to become an “alpha” leaves you delegated as a “beta”–or worse, a “cuck”.
Let’s put a pin on that point for a moment.
Interlude: On the Modern Usage of the Word “Cuck”
Right-wingers love to use the word “cuck” to describe someone they dislike.
It became a meme during the 2016 Election in the United States, with some labels (“cuckservative”) being used to demonize Republicans who weren’t reactionary enough.
The origins of the insult began with a term for a sexual fetish called cuckoldry: The enjoyment of watching other people have sex with your significant other.
Most bloggers treat this as a clinical subject and stop there. I am not most bloggers.
An under-reported and unfortunate truth of cuckold fetishists is that there’s often a significant racial component to their fantasy: White couples almost always seek out a black man to be the “bull” (the person whom displaces the cuckold) of the scene. (This is as much a problem within the LGBT community as it is outside of it.)
If you thought the depraved minds of 4chan users wouldn’t pick up on this cue, you haven’t been paying attention to the Internet since 2007.
The insult “cuck” has less to do with the fetish, tangibly, than it does to do with a white supremacist worldview.
To white supremacists, white women are the “property” of white men, and any man who “allows” white women to have sex with a person of color is a cuck.
Thus, there are two kinds of people who use the word “cuck”: Those who know its intent and mean it, and the oblivious masses who mask the dog-whistle. Propagandists call the latter useful idiots.
If you want to find the truth behind a person’s actions, you need to first discover their incentives. This is the “follow the money” approach, but generalized: Some people don’t need money, they want power. Political power, specifically.
It should come as no surprise that pick-up artists, anti-feminists, and incels all subscribe vehemently to the “friend zone” mythos. Additionally, incels, in particular, are prone to self-loathing and projection around the “cuck” insult.
This ultimately leads to a very dark place.
The Fascist Event Horizon
Most of us, in our youth, are varying degrees of socially awkward. This leads to anxiety, insecurity, and a sense of listlessness in most young adults.
Typically, we grow out of this by building relationships, learning through a litany of easily avoidable mistakes, and acquire the understanding we lack.
Pick-up artists prey on the rest of us, convincing them that the reason they don’t have a fulfilling sex life is because they’re not adhering to some aggressive social stereotype that gives them superpowers over women.
The ones that “succeed” go on to perpetuate that cycle. The ones that fail become self-loathing incels that stew in their own awkwardness and contempt.
Once you start to head down this path, you’re almost guaranteed to internalize a lot of the beliefs that are espoused:
“Women want strong alpha males.”
“Alpha males are dominant, assertive, adhere strongly to evangelical Christian values, and embody tradition.”
“Women would rather sleep with a jerk than a nice guy.”
“If you’re friend-zoned, that makes you a cuck to the girl you deserve.”
It’s here that two competing interests will clash.
Incentives Rule Everything Around Me
People who want money and influence are incentivized to find some mental framework that allows a diverse set of personality types to somehow succeed at their relationship goals. This is why they went on to invent the Sigma Male, and insist “they’re equal to alphas, but separate from the hierarchy”.
People who want political power and true believers to perform political violence and stochastic terrorism on their behalf are incentivized to set the bar high and make everyone feel inadequate.
That’s why, immediately after the end of Donald Trump’s presidency and a general shunning of his rabid supporters, the Sigma Male meme is suddenly on a rise in popularity.
Preventing the Poisonous Patriarchy
If you want to prevent a friend or family member from falling into the trappings of abusive con men, white nationalist recruiters, and toxic masculinity, there are a few things you can do to stop them from going down this road.
Consent is sexy. Establish good habits. “Yes means Yes” is a better framework than “No means No”, because it implies a negative default in the absence of a specific answer. There’s a lot of literature on BDSM culture and sex work that you can pull inspiration from.
Emphasize healthy friendships. Fuck the hierarchy worldview; friends are amazing. Whatever it takes, make sure you can appreciate your friends for who they are, not what they might later become. If you’re struggling to make friends, I recommend reading this article.
The only thing we have to cringe is cringe itself. Fuck what other people think: If you’re having fun with an activity, who cares if it’s “cringe”? Authentic enjoyment becomes fleeting for many adults once you progress through puberty; and while I’m not sure if that’s nature or nurture, I do know that being shamelessly yourself at all times maximizes your enjoyment.
Abandon tradition, embrace modernity. Tradition is stupid. It’s literally doing what people have always done because a better idea hasn’t yet come along–even when a better idea does come along! Instead of relying on traditions, practice creative and imaginative thinking every chance you get. Step out of your comfort zone from time to time. Introspect and plan differently for the next time you’re in a similar situation. That’s how you grow as a person.
If you practiced all of the above and are still bewildered by “what women want” and worried you’ll be alone forever, here’s my final bit of advice: Ask them! Especially if you’re close enough friends that they’ll answer in earnest, because they know that you’re trustworthy and not trying to objectify them.
Literally nobody knows what a given woman is looking for in a partner more than she does. Anyone who claims otherwise is full of shit or dangerously manipulative.
If you ask 100 women what they want in a partner, you’ll get 100 different answers. Gender roles aren’t a symptom of a homogeneous population. People are people.
If anyone is truly your friend, they’re already emotionally invested in seeing you find someone that will make you happy. Trust them more than you’d trust me, or anyone who confidently claims to know “what women want” and then proceeds to totally misunderstand everything women say.
Additionally, everything I said above is also true of men and enbies. People are people, dammit!
What Do I Do if Someone Calls Themselves a “Sigma Male”?
Reply “Sigma balls“.
Ridicule might not adequately discourage participation (after all, the unscientific Myers-Brigg Type Indicator is still prevalent everywhere), but it’s cathartic.
Since I first published this article, I’ve received a lot of feedback. I’m going to attempt to respond to some of the questions I’ve received over the past few month in order to save everyone time asking the same questions.
The goal of the “sigma male” idea is to capture more of the “desperate and lonely single man” market segment–in particular, the ones that don’t buy the whole “alpha male” shtick. It’s pure bullshit and it’s bad for you.
Is Sigma Male “Cringe”?
Cringe culture is stupid, but I’m willing to make an exception for the whole “sigma male” meme (but only insofar as we also treat “alpha male” with the same level of earned contempt).
Science has shown that biological sex is not binary. Furthermore, sex isn’t the same thing as gender identity, which can be different from your biological sex and has to do with your role within society. This is what science has to say about the subject; it’s not up for debate.
So, with all that in mind, why do the same crowds of people who insist that sex is binary and assigned at birth (in spite of what science actually suggests) turn around and invent multiple kinds of male that someone can be, only to then arrange them in an imaginary hierarchy?
I’m not, and you have to be acting in bad faith to think listing two groups together is the same as equivocating the two.
Both groups are the consequence of the same harmful and false beliefs about gender, sex, and masculinity. Their beliefs about women are disgusting and they prey on the insecurity of other men to secure book deals and speaking gigs.
Pick-up artists are predators that spread predatory ideas. Incels are the desperate dregs that don’t buy the PUA books but still internalize the same values, usually expressed through self-deprecation. These are clearly not the same thing, but both groups are the consequence of the same delusional bullshit rooted in anti-feminism.
The people who purport that “being alpha” is a meaningful descriptor of humans rather than incomplete software are either delusional or trying to pull one over on you.
The unproven hypothesis of “sigma male” is predicated on debunked pseudoscience. Why bother believing something whose entire foundation is false?
The science of personality (a discipline of psychology) is extremely complicated. The people peddling the [Greek Letter Here] Male are trying to sell you on the belief that masculinity is a hierarchy of tribes. It’s just as stupid as the Myers-Brigg Type Indicators.
If you want an actual model for personality based on real cognitive science, look at HEXACO. Notably, your personality scores do not yield a reliable partitioning (“Are you an T or a P?”) nor is a hierarchy proposed.
Anything that says your entire personality or existence can be summarized as belonging to one of N groups (with N less than 100), or by a ranking in an imaginary social ladder, is bullshit–pure and simple.
Note: The header for this section is from one of the many unapproved comments submitted to this blog post with a fake email address. Comments like this aren’t an expression of introverted personalities. The word you’re looking for is “cowardice”.
Why aren’t you approving my comments on this blog post?
Today, I got blocked on Twitter, after having my replies hidden, by a rather popular furry with a largely-young audience because I pointed out he was spreading bullshit pseudoscience. Silver lining…
Nearly Everyone Underestimates the Importance of Good Friendships
If living through the COVID-19 pandemic has taught us anything–and it surely hasn’t–it would be the importance of friendship and community to our physical and emotional well-being.
For more on the subject of People Who Ought to Know Better Not Learning the Obvious Lessons from Misfortune, one needs look no further than social media.
Popularity
One of the reoccurring topics of the Discourse on Furry Twitter is those gosh-darned popufurs–loosely defined as “anyone with a higher follower account than you”.
I’ve written an analysis post back when I posted on Medium that covered friendship and popufurs, which inspired Stormi to create a YouTube video about the topic:
I’ve never experienced popularity, but I’ve been close personal friends with a few people who do, and I’ve witnessed the fallout of parasocial relationships. Archantael did a really good video on that subject:
One of the most dangerous falsehoods that too many furries believe about popularity is that you can’t be popular and lonely at the same time.
Loneliness was already an epidemic before COVID-19, and the prolonged social isolation has led to a lot of relationship strain, to say the least.
In the past year, we’ve seen a lot of long-term, loving relationships end abruptly. We’ve seen people who were coping with mental health issues suddenly succumb to them. Tempers hasten. Patience shorten. It’s been a royal clusterfuck, and at least in America, there’s no end to it in sight.
Friendship
I think a big problem that rarely gets talked about is that our society is plagued by weird beliefs about what friendship is or ought to be.
The “Friend Zone” Myth
One of the most deplorable myths about friendship is the so-called “friend zone”. The story goes something like this:
When you meet someone, they’re a stranger. No arguments there.
Once you and them start to gain familiarity, they become an acquaintance.
After you’ve spent some time as an acquaintance, they become a friend.
At this point, if your gender identities and sexual orientations are compatible, you’re expected to move onto some sort of romantic interest–be it a friendship “with benefits”, romantic partner, or something in-between.
Once you’ve courted a number of flings, you progress towards a higher caliber of relationship. Namely: Marriage.
The reasoning goes: If you befriend a potential romantic partner, and remain friends, you’re somehow stuck on a less valuable step than what you should desire, and therefore should feel bad about it.
That’s what people say when they accuse someone of being in the “friend zone” by another person.
This mental model of viewing relationships is just dripping with the sort of hetero-normative patriarchy that feminists famously oppose, but not enough people actually listen to long enough to realize they also have your best interests in heart when they levy their critiques.
The belief in the Friend Zone leads to the cheapening of friendships in pursuit of sexual and romantic fulfillment. It’s inherently exclusionary to platonic expressions of love, asexuality, and polyamory.
Just say “no” to the entire concept of a Friend Zone.
Toxic Positivity
Life sometimes sucks.
Sometimes, the only way to cope with the suckage of life is to commiserate to your friends.
A good friend will listen, empathize with your experiences, and maybe even share their own. Friendship is rooted in shared vulnerability and appreciation.
But sometimes you encounter one of the Toxic Positivity proponents. “You’re bringing me down.” “Why are you depressed all the time?” We’ve heard it all before.
But toxic positivity is often more subtle than that. I’ll give you an example:
A good friend will tell you when you’re being an asshole, and try to talk you down from making foolish mistakes that will only hurt your future happiness.
Sometimes these conversations are tense and stressful. Sometimes you have to seem cruel to be kind. People are complicated.
And while I can understand not wanting to deal with high levels of stress all the damn time, there comes a time when you have to deal with the problems in front of you. Negative peace leads to a net negative.
Social Climbing and Disposable Friends
This one’s straight out of the “Actions Speak Louder Than Words” genre, and often follows from toxic positivity.
It doesn’t take a lot of imagination to see where that goes. (Art by Khia.)
Some people try to walk the social graph in order to position themselves near popular members of the community so they might benefit from others’ popularity.
Some people treat their friends as disposable and temporary, moving from group to group over the years, rather than face accountability for their own terrible behavior.
Friendship and community are essential for humans to be happy. This is the conclusion of The Happiness Hypothesis.
Happiness does not come from within. It’s not something that you can summon into existence through sheer force of will.
Happiness does not come from without. It’s not a lost treasure that you have to go forth and dig up somewhere.
Happiness comes from in-between; from the strong and weak bonds in our lives. It’s our sense of closeness and vulnerability to others within our close friendships and broader communities that lead to happiness.
Why do people pursue romance at the expense of friendships?
Why do people construct filter bubbles based on superficial positivity?
Why do people try to use others as stepping stones towards their ambitions or treat their friendships as disposable and temporary?
Why do we as a social species do all of this when we need friendships and communal bonds to be happy?
I think a lot of the time, the answer boils down to “ego”.
Ego
We as a species pay lip-service to friendship when it serves our self-interest, but discard its importance the second friendship becomes inconvenient.
Our ego–especially if we practice monogamous relationships–dictate that the only way to be “successful” in sex and love is to be in a committed relationship and friendship is just a stepping stone on the way to the real goal.
Our ego gets bruised when our friends show us tough love by speaking the truth.
Our ego drives us to strive for bigger numbers and stronger dopamine hits, even if it means using and abusing people along the way.
That’s what I take it to mean when Buddhists say that desire and ignorance lie at the root of suffering.
We want things, and we don’t know why we want them, but we do. And we will destroy ourselves and everyone we profess to love in pursuit of it. We’ll even destroy the habitability of our only planet in service to these desires.
Or we could, simply, not do that. If there’s one thing our ego loves, it’s to be reminded that we have a choice. That we’re in control.
As a hacker, exploiting a mechanism to undermine its normal goals is something I find a lot of beauty in. Hijacking the self-destructive nature of your own ego in service of your better nature is a masterpiece.
Choice
You are the protagonist of your own story. You can’t control what the universe throws as you, but you do get to decide what it means for you. Why not choose a better lesson?
And that’s usually enough to lead us to making better decisions, showing greater affection and appreciation for the people in our lives, and being more capable at coping with the endless hellscape that is other, often shitty, people.
I’m fortunate to know a lot of excellent people, both within and without the furry fandom. Most of my closest friends don’t have enormous social media followings. Some of my friends do!
I believe it’s important for friendships to be genuine and not transactional.
Belmont / Doomalorian
My oldest friend recently made a fursona, so he can be more involved with my participation in the furry fandom.
Most of you don’t know him yet, but if you think I’m cool, you’ll almost certainly like him too. We’ve been friends for over 12 years and live together.
In the future, I’ll be picking up Twitch streaming again. I’ll probably play a bunch of games with my friends and generally just have a lot of fun with it. If that sort of thing interests you, stop by his streams and maybe give him a follow.
Some of my friends have a sizable platform. We’re talking quarter-million Twitter followers sizable; or tens of thousands of YouTube subscribers. A handful are even Twitch partners (or on the cusp of…
Last year, I wrote about cryptographic wear-out for symmetric encryption. That post has attracted quite a bit of feedback from folks requesting comparisons against other block cipher modes, etc. One topic that I didn’t see requested much, but is equally interesting, is how this reasoning can be applied to asymmetric cryptography (if at all).
Let’s get one thing clear: Cryptography keys don’t “wear out” in the same sense as a physical key might. What we’re talking about is an ever-increasing risk of a collision occurring in random nonces.
ECDSA Key Wear-Out
ECDSA signatures involve a one-time secret, k. The scalar multiplication of k and the base point for the curve is encoded as half of the signature (r), while its modular inverse is multiplied by the sum of the truncated message hash and the product of r and the secret key to produce the other half of the signature (s).
If your selection of k is biased, or k is ever reused for two different messages, you can leak the secret key.
Strictly speaking, for any given ECDSA curve, there is only one k value that corresponds to a given r for all users (n.b it’s not distinct per keypair).
This means that all users of e.g. ECDSA over NIST P-256 have to worry about a shared cryptographic wear-out: After 2^112 signatures, there is a 2^-32 chance of a single collision occurring.
Fortunately, the search space of possible k-values is enormous, and this will not impose a real-world operational risk in the near future. If you’re worried about multi-user attacks, P-384 gives you a wear-out threshold of 2^176 messages, which we’re probably never going to achieve.
RSA Key Wear-Out
In order to calculate the wear-out for an RSA message, you first have to begin with an attack model. Previously, we were looking at algorithms that would become brittle if a nonce was reused.
RSA doesn’t have nonces. You can’t attack RSA this way.
But let’s assume that such an attack did exist. What might the safety limit look like? There are two remaining possible considerations for RSA’s security against cryptographic wear-out: Key size and padding mode.
RSA private keys are two prime numbers (p, q). RSA public keys are the product of the two primes (n) and a public exponent (e) that must be coprime to (p-1)(q-1). (In practice, e is usually set to 3, 65537, or some other small prime.)
The security of RSA is subexponential to key size, based on the difficulty of integer factoring attacks and the requirement for p and q to be prime numbers.
This primeness restriction doesn’t apply to your message. The padding mode dictates your upper limit on message size; e.g., PKCS#1 v1.5 padding will take up at least 3 bytes:
For encryption, x = 0x00 || 0x02 || r || 0x00 || m, where r is random padding bytes (minimum 8 bytes).
For signatures, x = 0x00 || 0x01 || 0xFF..FF || 0x00 || m.
In either case, the padding is always at least 11 bytes long.
So if you have 2048-bit RSA keys, you can encrypt or sign up to 245 bytes (1960 bits) with PKCS#1 v1.5 padding. This corresponds to a safety limit of 2^974 messages.
To keep things simple, the security of HMAC can be reduced to the collision risk of the underlying hash function.
If you’re trying to estimate when to rotate symmetric keys used for HMAC, take the birthday bound of the underlying hash function as your starting point.
For SHA-256, you have a 50% chance of a collision after 2^128 messages. For a 2^-32 chance, you can get 2^112 messages out of a single key.
For SHA-384, this is 2^176 messages.
For SHA-512, this is 2^240 messages.
In either case, however, these numbers might as well be infinity.
Did you know that fast MACs such as GHASH and Poly1305 aren’t random-key robust? This property can matter in surprising ways.
Did you know that ECDSA and RSA don’t qualify for this property either? This is related to the topics of malleability and exclusive ownership. You can learn more about this in the CryptoGotchas page.
Essentially, if a signature scheme is malleable or fails to provide exclusive ownership, it’s possible to construct two arbitrary (m, pk) pairs that produce the same signature.
Any nonmalleable signature scheme with exclusive ownership (i.e. Ed25519 with low-order point rejection and canonical signature checks, as provided by the latest version of libsodium) provides sufficient commitment–mostly due to how it uses a collision-resistant cryptographic hash function. (It’s also worth noting: HashEdDSA doesn’t. Isn’t cryptography fun?)
Underage furries calling themselves “fluffies” is a bad idea, for two reasons.
Divide and Conquer
The first reason is tactical, and not specific to what they’re calling themselves: If you label yourselves separately from the larger furry community, you make it much easier to be targeted–especially by propaganda. There’s a severely disturbed alt-right fringe to the furry fandom (dubbed alt-furry, the Furry Raiders, and so many other names) that would love nothing more than to sink their claws into younger furs.
It’ll start innocently enough (“Yay, you have your own space!”), but it will quickly accelerate (“Congrats on kicking those degenerates to the curb!”) to horrible places (“All LGBTQIA+ people are degenerates”), gliding on the wings of edgy humor.
This descent into madness is also known as the PewDiePipeline and all parents of furries should be made aware of it, lest it happen to their child:
It bears emphasizing: This existence of a PewDiePipeline within the “fluffy” space is not predicated on the intentions of the proponents. They can have all the best intentions in the world and it will still happen to their microcosm.
Preventing this from happening will require an almost inhuman degree of vigilance and dedication to correcting discourse from going sour. None of us are omniscient, so I wouldn’t take that bet.
Pre-Existing Terminology
The second reason the “fluffies” label is a bad idea is more specific to the word “fluffies” in particular: It already refers to a very disturbing meme on 4chan from not-very-many years ago: Fluffy Abuse Threads.
I’m intentionally not including any videos or images of this topic. There just aren’t enough content warnings for how gross this content is.
By calling yourselves “fluffies”, the most deranged 4chan-dwellers and/or Kiwi Farms lurkers on the Internet will begin associate you with the “fluffy abuse” memes, and may even act accordingly. In their twisted minds, they may even rationalize their conduct as if somehow you’re consenting to the abuse, by virtue of what you call yourselves.
Look, I get it: When you’re young, the over-sexualization of the media can be very uncomfortable, and it’s natural to want to avoid it. Additionally, it’s only human to want your own special club with a special name to hang out with your exclusive (n.b. same-age) community.
But please think carefully about what you’re doing, how you’re doing it, and which adults you decide to trust.
Also: maybe talk to older queers and/or furries about the history of the Furry Fandom, Pride, and kink before you make dangerous moves that make you more vulnerable to the worst humanity has to offer? Even if you don’t agree with us, we don’t want to see you get hurt.
There definitely is room in the furry fandom for people who are not comfortable with sexual content, or simply don’t want to be inundated with it all the damn time. It doesn’t need to be an exclusive thing or concept; instead, it should be normalized.
Ultimately, there’s probably a lot of work to be done to ensure kids and families have a safe and enjoyable furry con experience during daylight hours without repressing the queer and sexual identities of consenting adults at night. The best way to get from here to there is to talk, not to isolate.
Otherwise, we’ll keep seeing occurrences like this:
The onus here is going to be largely on furry convention staff and chatroom moderators to actually listen to people reporting abusive behavior. They haven’t always been good about that, and it’s time for change.
There is nothing manlier than being your authentic self. Even if that means liking some “girly” things. Even if that means being soft and vulnerable at times. Even if that means actually conforming to some stereotypes perpetuated by toxic masculinity when it coincides with your likes and interests. You do you.
But this isn’t just true of the male gender. Authenticity is the epitome of humanity. There’s nothing that stops women and enbies from being ruthlessly themselves.
You can’t be authentic when you’re participating in Cringe Culture, which blindly tears large swaths of people down to stoke the feelings of superiority in the people who evade its blast.
People are weird. I’m weird. I don’t expect everyone to like me, nor do I want them to. (Parasocial relationships suck!)
It’s okay to be a little obsessed about something other people look down on just because you happen to like it. Just make sure you’re not eschewing your adult responsibilities. (We all have bills to pay and promises to keep to the people that matter to us.)
If people don’t like you because you suddenly revealed your fondness for classic video games, rock-tumbling, or linear algebra? Fuck ’em. May the bridges you burn light the way to people who will appreciate you for who you truly are.
I’ve been told my blog is “weapons grade cringe” before, because I dared talk about encryption while having what, to most adults, comes across as little more than a cartoon brand or company mascot.
I sympathize with most queer people and/or furries for not wanting to subject themselves to the bigotry that runs rampant in Red States, but the ones who are jerks to other members of their community for living in those states, I can do without.
Being an asshole to someone because they live in, or are moving to, a state whose politics you dislike is equal parts stupid, selfish, and self-defeating:
It’s stupid because there’s no reason for expressing prejudice or painting with broad brushes. For example: “Florida Furs are bad people” is an attack on the author of this blog.
It’s selfish because not everyone who wants to leave these states has the resources or opportunity to do so, so all you’re doing is shining a spotlight on your own privilege. Way to show your entire ass to the community.
It’s self-defeating because of the way the U.S. political system is architected: If you wished for a genie to move every LGBTQIA+ person to the west coast of the United States, within a few years you’d essentially reduce support for LGBTQIA+ rights to approximately 6 out of 100 votes in the US Senate and 68 out of 435 in the House of Representatives.
When you factor in who owns the land in the big tech cities (San Francisco, Seattle, etc.) and how much political and economic power they wield, it becomes very clear that your shaming of others for not boarding the bandwagon serves the interests of the worst of humanity: Landlords and venture capitalists.
Not a good move for people who claim to be progressive, and want to achieve progressive political outcomes nationwide.
The fact that some states have horrendous laws on the books, even worse bastards enforcing these laws, and somehow even more terrible politicians gatekeeping any meaningful progress from changing the system isn’t ever going to be improved from the outside.
I say all this, and I acknowledge Florida does suck in a lot of obvious ways: Our governor (Ron DeSantis) has a disposition that would actually be improved if he wore clown make-up to press appearances. We also have far too many furries that are anti-maskers, anti-vaxxers, or both.
But when furries go out of their way to shame someone, simply for living here? You’re not helping. Seriously stop and think about your priorities.
And maybe–just maybe–be surgically precise when you decide insults are warranted.
Now that I’ve flushed the blog post topic buffer, I’m fresh out of ideas. Let me know some topics that interest you in my Telegram group so I don’t get bored and eventually write Buzzfeed-quality crap like this:
In hindsight, ideas like this are 90% of the reason Cringe Culture refuses to die.
As we look upon the sunset of a remarkably tiresome year, I thought it would be appropriate to talk about cryptographic wear-out.
What is cryptographic wear-out?
It’s the threshold when you’ve used the same key to encrypt so much data that you should probably switch to a new key before you encrypt any more. Otherwise, you might let someone capable of observing all your encrypted data perform interesting attacks that compromise the security of the data you’ve encrypted.
My definitions always aim to be more understandable than pedantically correct. (Art by Swizz)
The exact value of the threshold varies depending on how exactly you’re encrypting data (n.b. AEAD modes, block ciphers + cipher modes, etc. each have different wear-out thresholds due to their composition).
Let’s take a look at the wear-out limits of the more popular symmetric encryption methods, and calculate those limits ourselves.
Each block of data encrypted uses J0 + block counter (starting at 1) as a CTR nonce.
J0 is additionally used as the nonce to calculate the final GMAC tag.
AES-GCM is one of the algorithms where it’s easy to separately calculate the safety limits per message (i.e. for a given nonce and key), as well as for all messages under a key.
AES-GCM Single Message Length Limits
In the simplest case (nonce is 96 bits), you end up with the following nonces consumed:
For each key: 00000000 00000000 00000000 00000000
For each (nonce, key) pair:
NNNNNNNN NNNNNNNN NNNNNNNN 000000001 for J0
NNNNNNNN NNNNNNNN NNNNNNNN 000000002 for encrypting the first 16 bytes of plaintext
NNNNNNNN NNNNNNNN NNNNNNNN 000000003 for the next 16 bytes of plaintext…
…
NNNNNNNN NNNNNNNN NNNNNNNN FFFFFFFFF for the final 16 bytes of plaintext.
From here, it’s pretty easy to see that you can encrypt the blocks from 00000002 to FFFFFFFF without overflowing and creating a nonce reuse. This means that each (key, nonce) can be used to encrypt a single message up to blocks of the underlying ciphertext.
Since the block size of AES is 16 bytes, this means the maximum length of a single AES-GCM (key, nonce) pair is bytes (or 68,719,476,480 bytes). This is approximately 68 GB or 64 GiB.
Things get a bit tricker to analyze when the nonce is not 96 bits, since it’s hashed.
The disadvantage of this hashing behavior is that it’s possible for two different nonces to produce overlapping ranges of AES-CTR output, which makes the security analysis very difficult.
However, this hashed output is also hidden from network observers since they do not know the value of H. Without some method of reliably detecting when you have an overlapping range of hidden block counters, you can’t exploit this.
(If you want to live dangerously and motivate cryptanalysis research, mix 96-bit and non-96-bit nonces with the same key in a system that does something valuable.)
Multi-Message AES-GCM Key Wear-Out
Now that we’ve established the maximum length for a single message, how many messages you can safely encrypt under a given AES-GCM key depends entirely on how your nonce is selected.
If you have a reliable counter, which is guaranteed to never repeat, and start it at 0 you can theoretically encrypt messages safely. Hooray!
You probably don’t have a reliable counter, especially in real-world settings (distributed systems, multi-threaded applications, virtual machines that might be snapshotted and restored, etc.).
Confound you, technical limitations! (Art by Swizz)
Additionally (thanks to 2adic for the expedient correction), you cannot safely encrypt more than blocks with AES because the keystream blocks–as the output of a block cipher–cannot repeat.
Most systems that cannot guarantee unique incrementing nonces simply generate nonces with a cryptographically secure random number generator. This is a good idea, but no matter how high quality your random number generator is, random functions will produce collisions with a discrete probability.
If you have possible values, you should expect a single collision(with 50% probability) after (or )samples. This is called the birthday bound.
However, 50% of a nonce reuse isn’t exactly a comfortable safety threshold for most systems (especially since nonce reuse will cause AES-GCM to become vulnerable to active attackers). 1 in 4 billion is a much more comfortable safety margin against nonce reuse via collisions than 1 in 2. Fortunately, you can calculate the discrete probability of a birthday collision pretty easily.
If you want to rekey after your collision probability exceeds (for a random nonce between 0 and ), you simply need to re-key after messages.
AES-GCM Safety Limits
Maximum message length: bytes
Maximum number of messages (random nonce):
Maximum number of messages (sequential nonce): (but you probably don’t have this luxury in the real world)
Maximum data safely encrypted under a single key with a random nonce: about bytes
The IETF version of ChaCha20-Poly1305 uses 96-bit nonces and 32-bit internal counters. A similar analysis follows from AES-GCM’s, with a few notable exceptions.
For starters, the one-time Poly1305 key is derived from the first 32 bytes of the ChaCha20 keystream output (block 0) for a given (nonce, key) pair. There is no equivalent to AES-GCM’s H parameter which is static for each key. (The ChaCha20 encryption begins using block 1.)
Additionally, each block for ChaCha20 is 512 bits, unlike AES’s 128 bits. So the message limit here is a little more forgiving.
Since the block size is 512 bits (or 64 bytes), and only one block is consumed for Poly1305 key derivation, we can calculate a message length limit of , or 274,877,906,880 bytes–nearly 256 GiB for each (nonce, key) pair.
The same rules for handling 96-bit nonces applies as with AES-GCM, so we can carry that value forward.
ChaCha20-Poly1305 Safety Limits
Maximum message length: bytes
Maximum number of messages (random nonce):
Maximum number of messages (sequential nonce): (but you probably don’t have this luxury in the real world)
Maximum data safely encrypted under a single key with a random nonce: about bytes
A significant improvement, but still practically limited. (Art by Khia.)
Cryptographic Limits for XChaCha20-Poly1305
XChaCha20-Poly1305 is a variant of XSalsa20-Poly1305 (as used in libsodium) and the IETF’s ChaCha20-Poly1305 construction. It features 192-bit nonces and 32-bit internal counters.
XChaCha20-Poly1305 is instantiated by using HChaCha20 of the key over the first 128 bits of the nonce to produce a subkey, which is used with the remaining nonce bits using the aforementioned ChaCha20-Poly1305.
This doesn’t change the maximum message length, but it does change the number of messages you can safely encrypt (since you’re actually using up to distinct keys).
Thus, even if you manage to repeat the final ChaCha20-Poly1305 nonce, as long as the total nonce differs, each encryptions will be performed with a distinct key (thanks to the HChaCha20 key derivation; see the XSalsa20 paper and IETF RFC draft for details).
UPDATE (2021-04-15): It turns out, my read of the libsodium implementation was erroneous due to endian-ness. The maximum message length for XChaCha20-Poly1305 is blocks, and for AEAD_XChaCha20_Poly1305 is blocks. Each block is 64 bytes, so that changes the maximum message length to about . This doesn’t change the extended-nonce details, just the underlying ChaCha usage.
XChaCha20-Poly1305 Safety Limits
Maximum message length: bytes (earlier version of this document said )
Maximum number of messages (random nonce):
Maximum number of messages (sequential nonce): (but you probably don’t have this luxury in the real world)
Maximum data safely encrypted under a single key with a random nonce: about bytes
It’s tempting to compare non-AEAD constructions and block cipher modes such as CBC (Cipher Block Chaining), but they’re totally different monsters.
AEAD ciphers have a clean delineation between message length limit and the message quantity limit
CBC and other cipher modes do not have this separation
Every time you encrypt a block with AES-CBC, you are depleting from a universal bucket that affects the birthday bound security of encrypting more messages under that key. (And unlike AES-GCM with long nonces, AES-CBC’s IV is public.)
This is in addition to the operational requirements of AES-CBC (plaintext padding, initialization vectors that never repeat and must be unpredictable, separate message authentication since CBC doesn’t provide integrity and is vulnerable to chosen-ciphertext atacks, etc.).
My canned response to most queries about AES-CBC. (Art by Khia.)
For this reason, most cryptographers don’t even bother calculating the safety limit for AES-CBC in the same breath as discussing AES-GCM. And they’re right to do so!
However, for the sake of completeness, let’s figure out what our practical limits are.
CBC operates on entire blocks of plaintext, whether you need the entire block or not.
On encryption, the output of the previous block is mixed (using XOR) with the current block, then encrypted with the block cipher. For the first block, the IV is used in the place of a “previous” block. (Hence, its requirements to be non-repeating and unpredictable.)
This means you can informally model (IV xor PlaintextBlock) and (PBn xor PBn+1) as a pseudo-random function, before it’s encrypted with the block cipher.
If those words don’t mean anything to you, here’s the kicker: You can use the above discussion about birthday bounds to calculate the upper safety bounds for the total number of blocks encrypted under a single AES key (assuming IVs are generated from a secure random source).
If you’re okay with a 50% probability of a collision, you should re-key after blocks have been encrypted.
If your safety margin is closer to the 1 in 4 billion (as with AES-GCM), you want to rekey after blocks.
However, blocks encrypted doesn’t map neatly to bytes encrypted.
If your plaintext is always an even multiple of 128 bits (or 16 bytes), this allows for up to bytes of plaintext. If you’re using PKCS#7 padding, keep in mind that this will include an entire padding block per message, so your safety margin will deplete a bit faster (depending on how many individual messages you encrypt, and therefore how many padding blocks you need).
On the other extreme (1-byte plaintexts), you’ll only be able to eek encrypted bytes before you should re-key.
Therefore, to stay within the safety margin of AES-CBC, you SHOULD re-key after blocks (including padding) have been encrypted.
Keep in mind: single-byte blocks is still approximately 281 TiB of data (including padding). On the upper end, 15-byte blocks (with 1-byte padding to stay within a block) clocks in at about or about 4.22 PiB of data.
That’s Blocks. What About Bytes?
The actual plaintext byte limit sans padding is a bit fuzzy and context-dependent.
The local extrema occurs if your plaintext is always 16 bytes (and thus requires an extra 16 bytes of padding). Any less, and the padding fits within one block. Any more, and the data:padding ratio starts to dominate.
Therefore, the worst case scenario with padding is that you take the above safety limit for block counts, and cut it in half. Cutting a number in half means reducing the exponent by 1.
But this still doesn’t eliminate the variance. blocks could be anywhere from to bytes of real plaintext. When in situations like this, we have to assume the worst (n.b. take the most conservative value).
Therefore…
AES-CBC Safety Limits
Maximum data safely encrypted under a single key with a random nonce: bytes (approximately 141 TiB)
Yet another reason to dislike non-AEAD ciphers. (Art by Khia.)
Take-Away
Compared to AES-CBC, AES-GCM gives you approximately a million times as much usage out of the same key, for the same threat profile.
ChaCha20-Poly1305 and XChaCha20-Poly1305 provides even greater allowances of encrypting data under the same key. The latter is even safe to use to encrypt arbitrarily large volumes of data under a single key without having to worry about ever practically hitting the birthday bound.
I’m aware that this blog post could have simply been a comparison table and a few footnotes (or even an IETF RFC draft), but I thought it would be more fun to explain how these values are derived from the cipher constructions.
The eXtended-nonce ChaCha cipher construction (XChaCha) allows for ChaCha-based ciphersuites to accept a 192-bit nonce with similar guarantees to the original construction, except with a much lower probability of nonce misuse occurring.
Rather than continue to ruminate on the current mess, I’d like to instead take a moment of everyone’s present to look into the future, because we’re actually in a unique position to make a lot of good changes to the world; or, at least, to make something hilarious out of a bad situation.
This matters for everyone, but especially for furries, sex workers, and porn artists.
It should go without saying, but my standard disclaimer applies:
The contents of this blog post are the sole opinions of a 30-something gay furry who presents as an anthropomorphic dhole on the Internet. Do not confuse the opinion or satire contained within for either a) fact, b) professional advice, or c) the opinions of any company or entity; especially the author’s current or past employers.
How to Make a Larger Impact Than Deleting Your Account
If you’re considering deleting your Twitter account and moving to an alternative platform, I encourage you to move but not delete your account. There’s something much cooler you can do with your existing account than delete it.
Twitter’s operations costs are currently fairly predictable. Well, predictable enough to lay off a lot of the workers necessary to keep the lights on, anyway.
Wouldn’t it be great if, instead of deleting their accounts in protest, we decided to make our accounts cost more in storage and compute costs?
I posed a similar question to Twitter the other day.
Here are some of the more fun and interesting ideas that were shared with me:
Block and Search with Wild Abandon
(I can’t find a record of who suggested this idea. Maybe I imagine someone suggesting it, and it was actually my own idea, but I’m misremembering. Who even knows anymore?)
Filtering blocked/muted accounts from your timeline requires a small amount of server-side CPU.
Searching for trending topics and common words in your native language will likely hit many thousands of accounts.
If you ask Twitter’s search engine for all tweets that contain certain common words or phrases, and then the application has to filter out hundreds of thousands of blocked and/or muted accounts, this is going to become computationally expensive.
Especially if you systematically mute or block every single account that promotes a tweet.
Especially if you’re already using an adblocker, such as uBlock Origin (which you can install in Firefox for Android, by the way).
To be clear: The goal of this idea is NOT to degrade the platform or perform a Denial of Service attack. It’s simply to make Musk pay more for useless processing that won’t increase Twitter’s ad revenue.
Bonus points if you somehow manage to work this into the video reply idea, and it actually inflates their storage costs significantly.
Bad Suggestion: Reply to Brands with Yiff
There were a few people who suggested posting adult furry art in reply to brand tweets. The idea being that this will make Twitter less marketable for advertisers.
This is a terrible idea for two reasons:
Optics. Regardless of your goals, you’re going to expose a lot of unsuspecting users to unsolicited pornographic art. This is not how you make friends. This will make a lot of undecided people form a negative opinion of the furry fandom.
Underage users. The minimum age to sign up for Twitter is 13. Parents who might be comfortable with their young teenager following a household name Twitter account will not want their child being exposed to hardcore pornography.
Too often, I see some furries reach for this tactic. You should consider it the nuclear option, because the small tactical gain is largely outsized by collateral damage.
The only thing you’ll accomplish is giving ammo to right-wingers who loudly proclaim all LGBT people are groomers (meanwhile they vote down laws that would stop child marriage; how so very curious of them).
With any luck, we can make Twitter the most expensive $44 Billion that Elon Musk will ever spend.
An Opinionated Summary of Alternate Platforms
Where should we go when Twitter dies? There are a lot of opinions to be had.
Rumors of Tumblr’s Sex Positivity Are Wildly Exaggerated
Shortly after Elon Musk purchased Twitter, Tumblr had announced updated Community Guidelines that, allegedly, permit the naked human form to appear in Tumblr content.
This apparently doesn’t include cartoon nudity. To wit:
Cohost is a somewhat new platform for posting. I have an account there (@soatok).
You can think of Cohost as the best parts of Twitter’s user experience, with the best parts of Tumblr, without any ads, tracking, or recommendation system (The Algorithm).
The premise of Cohost is to build around users, not profit.
Cohost is brought to you by a group calling themselves the Anti Software Software Club–a software company that hates the software industry:
we are a group of three developers and designers—and maybe more soon!—with very strong opinions about how to operate a software company. we’ve all left jobs at conventional tech companies to build cohost and we’re thrilled we finally get to share it with the world. you can read more about us, including our manifesto, on our main website. ASSC is not-for-profit and 100% worker owned.
It’s worth emphasizing that “not-for-profit” is most likely an aspiration and a tenet, not a legal designation. Cohost is an LLC. It would be an error to mistake it for a non-profit organization. The legal term “non-profit” almost always refers to 501(c)(3) organizations.
Personally, I don’t care at all about these distinctions. Some people do. I’m not a lawyer, and I actually find legal topics exhausting to the point of being physically painful. That’s not at an exaggeration.
It’s a neat project. If you want a centralized replacement for Twitter, Cohost is probably your best bet.
Mastodon
Mastodon is federated software, which feels in some ways more like Email or RSS than Twitter does. Moderation is local to your instance, rather than top-down like a centralized platform. Discovery is based on which instances peer with which instances.
There’s a lot to like about Mastodon. However, if you’re an artist that’s looking for a centralized watering hole where all your customers already are, Mastodon… is not that.
Personally, I used to have a Mastodon account, but I didn’t really use it much, and then the instance that hosted my account shut down and I lost all my data. That experience killed my interest in Mastodon.
There are probably other platforms that are worth considering, but there are only so many hours in a day, and I have a day job.
If you find yourself deeply dissatisfied with the options presented, please feel free to explore others. Alternatively, you may wish to build a new platform in line with your own vision.
If you lack the skills to build your vision, grab a few friends and read through Furward Momentum together.
How to Architect the Porn-Friendly Social Media of Tomorrow
What do sex workers, porn artists, and fantasy sex toy companies have in common?
What would it take to build a social media platform that actually supports sex workers and NSFW artists? Well, a lot. But I’d like to at least provide a sketch for how such a platform might be architected.
Your platform should use WebAuthn instead of password authentication.
I recognize that this makes onboarding users difficult (due to a lack of availability of FIDO2-compatible hardware keys), but the security benefits are immensely worthwhile.
The best thing about WebAuthn is, when implemented correctly, your users become extremely phishing-resistant without requiring any diligence on their part.
We don’t need more surveillance capitalism. The less you know about your users, the better.
Consider An Invite-Only Design
Lobste.rs requires new users be invited by an existing user.
This is a great way to reduce the blast radius of platform abusers and their subsequent attempts at ban evasion: If the same person keeps inviting bad people, take away their invite privileges.
I chose a similar approach when I designed FAQ Off.
Don’t Mix Payments With Platforms
Simply put: The platform that users interact with should be mostly independent from the component that processes payments for the users of the platform.
By “mostly independent”, I mean they should be distinct legal entities, with no overlap in ownership, that operate in different countries. The only things that should be exchanged between the two are HTTP messages (over TLS) and API keys.
The payment gateway should accept multiple options (credit cards, PayPal, etc.), but never provide a custom “memo” field. Where possible, the invoice feature should be used (with the possibility of tipping left open).
If you permit users to fill in custom memos, they will inevitably leave a remark that flags the recipient’s account as porn/sex related.
This payment gateway will not just process payments and subscriptions; it will also act as a payment escrow service and amortize the risk of chargeback fraud over multiple content creators. (To that end, it should have a name that isn’t embarrassing on a bank statement.)
The incumbent payment gateways used by the porn industry should be avoided, for multiple reasons:
They’re expensive
The transactions they process get flagged a lot as fraud
They’re often used by spammers, scammers, computer criminals, and deplatformed hate groups
Instead, you’d want your value proposition to be more about social media and payments between friends. The fact that you allow porn and sex work on your platform (which should be one of many platforms that use this payment gateway) needs to be a mere footnote.
These are just some considerations I can think of off-hand when imagining what a sex-positive social media platform would look like, if it were built in 2022.
The biggest challenges any platform faces will not be legal or technical; they will be social.
Twitter exploded in popularity after a few celebrities started using it. I don’t know how to replicate their success with a greenfield project, and I doubt anyone else does either.
In Summary
Elon Musk is probably going to kill Twitter. It would be really funny if we made this cataclysmically expensive for Elon Musk, personally.
There are a handful of alternative platforms that folks are already migrating to in anticipation of Twitter’s demise, but none is a clear winner.
Twitter’s death will put a lot of artists (especially porn artists) and sex workers in peril, so I sketched some ideas that would enable a Twitter alternative to better serve them.
Ultimately, the future remains uncertain. I don’t pretend to have answers, just ideas. If you think you know, or can do, better, I wish you the best of luck.
Some of you may be surprised to learn that my fursona is not a fox, nor a wolf; nor is it a fictitious fox-wolf hybrid popular within the furry fandom (which is usually called a “folf”).
Dholes are very social creatures that live and hunt in large packs. But how they hunt is needlessly awesome: Where other canids (e.g. wolves) try to chase and then surround their prey, dholes spread out and use high-pitched whistles to coordinate their strikes over large distances.
Some other interesting notes from animal conservationalists over the years: Dholes have very low sexual dimorphism (so you generally cannot tell whether a dhole selected at random is male or female at a glance), and they’re known to do a handstand when they’re urinating.
You can learn more about dholes and dhole conservation efforts here.
The Symbolism of Dhole Fursonas
If you’re trying to pick a species for your fursona, how do you know if a dhole is right for you? Art by SkiaSkai Here’s a short list of values and traits you can derive from dholes and dhole behavior in the wild:
Do you value and understand friendship in its purest form?
Do you value cooperation (n.b. without power structures and hierarchies)?
Do you enjoy communal living (with a chosen family of close friends and/or a polycule)?
Are you clued into dog whistles? (Okay, this one’s kind of a dumb joke because dholes are called “whistling dogs”, but a lot of dhole furries I know are very clueful about the alt-right’s bullshit, so it’s fitting.)
Do traditional notions of sex and gender not interest you in the slightest?
If you said yes to any of those questions, or if you simply can’t decide between fox or wolf and don’t feel like phoning it in with a fictitious hybrid, a dhole may be a good fursona choice for you.
We’ve more-or-less all been coping with the pandemic since early March.
During this time, I’ve seen a lot of people stressed and depressed to their breaking points, usually while also blaming themselves for not being able to bottle their feelings up and believing no one else is at their limit.
And that’s simply not true. Everyone is suffering, everyone is coping. Not just from the pandemic and the stress and isolation of avoiding the risk of infection, but from the other social ills of our world.
In a different vein, three different colleagues recently told me that I make blogging “look easy” because of the rate that I manage to output new blog posts here.
And if we take a step back and look at both situations, there’s a subtle theme here that I’d like to explore: The unseen.
... mehr anzeigen
You’re Not Alone; It Gets Better
We’ve more-or-less all been coping with the pandemic since early March.
During this time, I’ve seen a lot of people stressed and depressed to their breaking points, usually while also blaming themselves for not being able to bottle their feelings up and believing no one else is at their limit.
And that’s simply not true. Everyone is suffering, everyone is coping. Not just from the pandemic and the stress and isolation of avoiding the risk of infection, but from the other social ills of our world.
In a different vein, three different colleagues recently told me that I make blogging “look easy” because of the rate that I manage to output new blog posts here.
And if we take a step back and look at both situations, there’s a subtle theme here that I’d like to explore: The unseen.
Everything you know about the world is an abstraction of the truth.
That isn’t some philosophical pontification, it’s a plain and simple fact. You don’t know what’s going on in anyone else’s brain at any given moment (especially if they have no inner monologue at all).
Under better times and better conditions, I’d say that the surest and fastest path to being mental unwell (depressed, anxious, etc.) is comparing your behind-the-scenes footage to other peoples’ highlight reels.
Social media is nothing but highlight reels.
Hell, this very blog is a highlight reel of the ideas I managed to flesh out into a coherent structure.
Nobody would ever have known the stress, frustration, and nihilism that goes into trying to come up with a topic to write about if I didn’t just allude to it in this sentence. My writing process is too informal to articulate and very unhelpful to anyone who has to write words for a living: If I can’t think of what I want to say and why, I don’t write. It’s that simple. I can’t force it. I’ve tried. And sometimes I have very strong opinions about certain topics, or something really funny happened, or I observed something really noteworthy that should probably be captured and immortalized in prose… yet, I just can’t figure out how to put it into words, so it languishes forever.
And yet, so many people are so over-exposed to this polished and curated filter bubble, I fear they’ve lost sight of the human experience, and how badly we all struggle and fuck up all the time.
The isolation sure isn’t helping.
The Political Queer Experience
Being LGBTQIA+ in the United States of America is quite an experience, whew, let me tell ya.
Sometimes I have to ask myself: Does anyone really believe that the Trump administration or the GOP is actually pro-LGBT? Surely nobody could have missed the memo? To wit:
The Republican Party platform for 2020 under Trump’s leadership (PDF) specifically called for a reversal of Obergefell v. Hodges (the case that allowed for gay marriage rights). See Page 9.
It’s even worse when you hear from alleged “Gays for Trump” or even “Furries for Trump”.
It’s bizarre; how can so many people support someone who wants to hurt them?
Enter Dean Browning
Dean Browning is a political candidate from Pennsylvania who lost the Republican primary in 2020. He also runs a PAC.
His cover was blown when he forgot to switch to his alt account (which apparently is owned by his adopted son?) to attempt to astroturf a critic. He then tried to offer “context” into the tweet.
Neither the original fuck-up nor his nonpology went unnoticed:
Never one to miss a beat, Coopertom (the cat fursuiter from the infamous cursed photo) decided to remake this hilarious performance art of a gaffe in VRChat.
This blew up. You’ve probably seen news coverage of this event. It made The Verge, it made BuzzFeed. Hell, it even made PC Gamer.
For many readers, this is the first time they read about the furry fandom in a positive light.
For the first many years of the furry fandom’s existence, our media strategy was nonexistent.
We kinda just winged it (with apologies to avian furries), and the end result was an episode of CSI about furries that was so inaccurate and bad in its portrayal of the furry fandom as sex-obsessed losers that if you type “that episode” into Google, it’s the first search result.
Unfortunately, this has stuck in the public imagination for many, many years since. Almost every interaction I’ve had online has been colored by a history of bad press that the many recent years of fair coverage hasn’t abated.
As a result, almost nobody outside of the furry fandom truly has the slightest clue about who we really are, or how incredible the community can be.
Even most furries don’t know this!
Let’s circle back to Coopertom. What many of the folks who saw the news coverage of his VRChat world didn’t see is that he later posted this…
I don’t think even Coopertom anticipated how much love and kindness he would be met with by the community he’s been a part of for at least a decade. He surely wasn’t counting on it. You can hear that much in his voice.
Everyone who hates furries because an old CSI episode portrayed us in an unflattering light–or because of the actions of a scant few individuals that did terrible things and are consequently not welcome in our community–has chosen to blind themselves to what this fandom is really about, and they will forever be Plato’s cave-dwellers as a result.
The furry fandom has always been about humanity.
Whether to celebrate or to critique? That depends on the individual.
Anyone who tells you different is missing the point. (To be explicit: The point isn’t sex, although we aren’t exactly prudes.)
Can We Take the Blinders Off?
A few years ago there was a TED talk to commemorate 1000 TED Talks, in which the speaker recursively used Amazon Mechanical Turk to summarize each of the talks into six words each, and then to summarize the summaries, etc. until he landed on a mere six.
In the same spirit, I’ve been thinking what the six words that describe the furry fandom would be. (Spoiler: See the title of this blog post.)
Whether you’ve been a furry since the days of SomethingAwful trolls or are just discovering your interest for anthropomorphic characters, you’re not alone.
No matter how depressed, frustrated, stressed, angry, despaired, hollow, hopeless, or scared you might feel about your life, it gets better.
This video was made before the pandemic, but it hits differently after:
If I can be said to be coping well (and making blogging seem easy as a result), it’s simply because I’m privileged to have so many good friends to lift up my spirits. It’s not a reflection of me being somehow special, and it isn’t a poor reflection on you or anyone else if you aren’t.
But on the other paw, I utterly failed to gripe about a recent irksome instance of sensationalist cryptography reporting, as well as the recent anti-encryption legislation in the Five Eyes nations. So maybe I’m not doing as hot as some of you might think I am? Win some, lose some.
A lot of people online claim they “hate furries”, but almost none of them quite understand how prolific our community is, let alone how important we are to the Internet. As Stormi the Folf puts it…
I guarantee you the internet would collapse in a most horrific manner if all the furries in the world got Thano's snapped.
They *run* the internet in more ways than most people realize
Stormi is the Potato of Knowledge and Floof What Stormi’s alluding to is true, and that’s a tale best told by an outsider to our community.
Telecommunications as a whole, which also encompasses The Internet, is in a constant state of failure and just in time fixes and functionally all modern communication would collapse if about 50 people, most of which are furries, decided to turn their pager off for a day. t.co/k1UqOv5kpd
— Ẑ͚͔͍̻̤̟ä̶̼̗̟͔́̿̾̓n̬͙̫̿͑͊̈̚d̡̰̭̞͖̟̖̟ͬ̚ê̺͖̂ͩ̀̉ͣrͪ̓ (@mmsword) November 28, 2019
Their follow-up tweet that elaborates on furry involvement is here. So I’d like take the time to explain why nobody should ever underestimate the ingenuity or positivity of the furry community.
The Furry Fandom Has Saved Lives
youtube.com/embed/3h9sO17CV9A?… This is just one of many anecdotes. You can find many more here. Although the furry fandom is widely misunderstood, it’s difficult to overstate how many lives have been saved and enriched by our community.
I wanted to share this touching moment. @Reo_Grayfox was telling me his story, and said those lines while staring straight into his fursuit's eyes. Hearing personal stories like this makes you appreciate the vastly diverse reasons why the furry fandom is essential to so many. pic.twitter.com/fD09Wmv6mf
In 2016, refugees from the civil war in Syria ended up in a hotel in Canada. This would have been an utterly remarkable fact if it wasn’t the same hotel and weekend as the local furry convention, Vancoufur.
Artists and costume makers: I could literally link to hundreds of artists here. Follow me on Twitter; I retweet a lot of cute stuff.
Pretty much everything you could aspire to be that isn’t also terrible, if you look hard enough, you’ll find furries in the leaderboards having a fun time with it all.
Since you’re probably new, here’s a quick primer on the landscape of our community–good, bad, and indifferent. This is the sort of information I and many of my friends wish we had when we first joined the fandom.
The Furry Fandom
Furry is a decentralized, participatory community that is largely online and deeply rooted in Internet history.
You can estimate about 10% of the human population to be LGBTQIA+, but that number is closer to 80% for furries.
Since you’re probably new, here’s a quick primer on the landscape of our community–good, bad, and indifferent. This is the sort of information I and many of my friends wish we had when we first joined the fandom.
The Furry Fandom
Furry is a decentralized, participatory community that is largely online and deeply rooted in Internet history.
You can estimate about 10% of the human population to be LGBTQIA+, but that number is closer to 80% for furries.
As a consequence, our community is largely sex-positive (but not necessarily sexual), queer-friendly, and openly tolerant to people with diverse backgrounds.
Our community is vibrant, art-centric, and generally able to laugh at ourselves.
However, it’s not all sunshine and rainbows all the time, so let’s address the elephant in the room and talk about the bad parts of the furry fandom.
The Bad Parts of Furry
Remember when I said, “Furry is a decentralized, participatory community” earlier? This is both a strength and a weakness: It’s challenging to effectively expel terrible people. Consequently, while most of the furries you run into will be reasonably cool, there are undoubtedly some bad eggs.
It would take me years to comprehensively list all of the badness within any community–let alone one as large as ours–so I’m going to make a few broad strokes for the sake of brevity.
Furries that describe themselves as “Conservative” are almost exclusively the sort of right-wingers that were okay with (if not participating in) the insurrection of January 6, 2021.
Right-wingers range from the milquetoast pseudo-centrists like PeaceWolf to open insurrectionists like Diezel Raccoon to the guy who made a fursona named Foxler (Fox + Hitler) complete with a red armband.
Even if you like to think of yourself as a tolerant and open-minded person, there is nothing positive to be gained by associating or interacting with right-wing furries. They aren’t your log cabin conservatives.
Think of the sheer cognitive dissonance it requires to be openly right-wing and/or evangelical in a community that’s 80% LGBTQIA+ (which is almost always a target of right-wingers and evangelicals, at least in America). And then realize these assholes possess it in spades.
Furry Valley (formerly Furry Menagerie)
Dogpatch has a very long Twitter thread explaining the myriad reasons why you almost certainly want to avoid the group calling itself Furry Valley.
Furry Valley is a cult of personality that tries to welcome new members with “love-bombing” and then hold them hostage with doxing. A lot of the groups in the Furry Telegram list have FV’s tendrils in them, which serves as an unfortunate recruitment funnel for unsuspecting furries.
If the group description mentions Furry Valley, avoid it. If the rules (pinned message, usually) mention Furry Valley, leave it. If you report a pro-FV message to the mods and they allow it, block them and leave it without further incident.
The Fuckboi/Party Scene
There is a contingent of furries that go to furry conventions to do a lot of drugs, have a lot of sex, and go to a lot of private room parties–and not actually participate in the community at large. This is the same contingent that causes a lot of the “30 is gay death” talking points to resurface in the furry fandom.
Predictably, this churns out a lot of unsavory personalities running virtually unchecked by our larger community. After many years, this has become toxic beyond the point of being salvageable, best demonstrated by the organization and attendance of an illegal and unofficial furry convention during the COVID-19 pandemic:
Easily 95% of the people I’ve met in the furry fandom have been genuinely kind, caring, conscientious, and generous. There’s probably some sampling bias and self-selection at play here, admittedly.
How to Get Started?
Don’t bother with local furries, at least out of the gate. Regional groups tend to be catch-all for people who have little in common beyond geographical location, and a lot of local groups are very bad at moderation.
Wanna see my vids even earlier? Check out deleted scenes? Consider supporting me on my Patreon:Patreon: http://patreon.com/StormiFolfKo-Fi: http://ko-fi.com/...
A lot of people online claim they “hate furries”, but almost none of them quite understand how prolific our community is, let alone how important we are to the Internet. As Stormi the Folf puts it…
I guarantee you the internet would collapse in a most horrific manner if all the furries in the world got Thano's snapped.
They *run* the internet in more ways than most people realize
Stormi is the Potato of Knowledge and Floof What Stormi’s alluding to is true, and that’s a tale best told by an outsider to our community.
Telecommunications as a whole, which also encompasses The Internet, is in a constant state of failure and just in time fixes and functionally all modern communication would collapse if about 50 people, most of which are furries, decided to turn their pager off for a day. t.co/k1UqOv5kpd
— Ẑ͚͔͍̻̤̟ä̶̼̗̟͔́̿̾̓n̬͙̫̿͑͊̈̚d̡̰̭̞͖̟̖̟ͬ̚ê̺͖̂ͩ̀̉ͣrͪ̓ (@mmsword) November 28, 2019
Their follow-up tweet that elaborates on furry involvement is here. So I’d like take the time to explain why nobody should ever underestimate the ingenuity or positivity of the furry community.
The Furry Fandom Has Saved Lives
youtube.com/embed/3h9sO17CV9A?… This is just one of many anecdotes. You can find many more here. Although the furry fandom is widely misunderstood, it’s difficult to overstate how many lives have been saved and enriched by our community.
I wanted to share this touching moment. @Reo_Grayfox was telling me his story, and said those lines while staring straight into his fursuit's eyes. Hearing personal stories like this makes you appreciate the vastly diverse reasons why the furry fandom is essential to so many. pic.twitter.com/fD09Wmv6mf
In 2016, refugees from the civil war in Syria ended up in a hotel in Canada. This would have been an utterly remarkable fact if it wasn’t the same hotel and weekend as the local furry convention, Vancoufur.
Artists and costume makers: I could literally link to hundreds of artists here. Follow me on Twitter; I retweet a lot of cute stuff.
Pretty much everything you could aspire to be that isn’t also terrible, if you look hard enough, you’ll find furries in the leaderboards having a fun time with it all.
Search engines have this feature where if you start to type a question, it will attempt to predict your question based on what other people have asked.
This has some hilarious consequences. The PDF file format is apparently the world’s one of the world’s four most popular religions, or so the meme goes. Sometimes this feature gets gamed by large hordes of shitty people (read: 4chan) typing provocative questions into search engines.
Let’s take a look at some of the questions that real people and/or astroturfing trolls have asked Google about the furry fandom and its members.
Search engines have this feature where if you start to type a question, it will attempt to predict your question based on what other people have asked.
This has some hilarious consequences. The PDF file format is apparently the world’s one of the world’s four most popular religions, or so the meme goes. Sometimes this feature gets gamed by large hordes of shitty people (read: 4chan) typing provocative questions into search engines.
Let’s take a look at some of the questions that real people and/or astroturfing trolls have asked Google about the furry fandom and its members.
Answers to Questions People Asked Google About Furries
Note: This is just a subset of all the questions that showed up in Google’s autocomplete for various questions about furries. A lot of the questions are inappropriate or are framed so poorly that they’re not worth answering in the first place.
Soatok is here to answer your burning curiosity.
Do Furries Have Rights?
Yes. Specifically: The same rights as anyone else in the country they live in.
Do Furries Say UwU?
UwU
Do Furries Deserve Rights?
Yes.
I’m glad that matter’s settled, aren’t you?
Do Furries Talk?
If we didn’t, people wouldn’t be so desperate to shut us up, now would they?
But some fursuiters do choose to remain silent in fursuit.
Do Furries Want to Be Animals?
We already are animals: Humans are animals.
I mean, really, the only other options are vegetable, mineral, fungus, or microbe.
Do Furries Want to Be Non-Human Animals?
Much better question!
Generally, no.
The people who believe they are (spiritually or otherwise) a non-human animal are called otherkin or therian, not furries.
This really shouldn’t surprise anyone. Furries are nerds. Nerds go to cons.
Do Furries Go to the Vet?
No.
Not only do we not go to the vet, but we’ve historically done a poor job of vetting the people who rise in popularity in our community… which usually resulted in completely avoidable PR disasters that trolls happily abuse, to this day, to try to astroturf the general public into thinking we’re horribly depraved people.
See what I did there? :3
Why Do Furries Matter?
That’s a rather nihilistic question to ask, and it was the most popular “why?” question, to boot.
Namely, the furry fandom saves lives, provides a support system for a lot of LGBTQIA+ people, and is home to some of the best humans you’ll ever meet (including many that are absolutely vital to modern telecommunications infrastructure, i.e. the Internet).
But at the end of the day, this is a deeply personal question and will ultimately boil down to individual opinion and thus is unanswerable.
Why Do Furries Use Telegram?
Counter-question: Have you ever heard of the network effect?
Telegram supported custom stickers before any other major communication medium, so they’ve been accumulating furries for many years before the other platforms caught up.
What other platform makes it easy to respond with this image when socially appropriate? Sticker by Khia, Telegram sticker pack here.
The main reasons furries choose Telegram today are:
Their friends are already using it
They can effectively reply to messages with custom stickers of their fursona, rather than just plaintext or emoji
That being said, many furries these days use Discord too. Main reasons: Gaming and streaming.
If you’d like to learn more about furries and Telegram, and furries using Telegram, and how to make Telegram bearable, check out A Furry’s Guide to Telegram.
Why Do Furries Like Foxes?
Oh contrare!
Just kidding! This sticker’s meaning is “I’m not a fox!” not “Down with foxes!”
There really isn’t a good answer to this question.
The best approximation you’ll find is that: Foxes used to be an extremely popular choice in cartoon animal character design (Disney’s Robin Hood, Star Fox 64, Sajin Komamura from Bleach, etc.).
It’s an emoticon! OwO is like a sideways :3 face, but with surprised eyes. It comes from copypasta started by a shitpost mocking the typical behavior and communication style of furry roleplayers.
How Do Furries Talk?
Rather well, thank you.
Oh wait, you wanted to know about the anatomy that enables speech? Ask a biologist with a passing interest in science fiction and/or werewolves.
Severely allergic. But that’s just me. Photo by Kurdan. Feline fursonas (cats of all sizes) are almost as common as canid fursonas (wolves, foxes, etc.).
If you’re expecting to see us fight like cats and dogs, you’re in for some disappointment.
How Do Furries Make Money?
A lot of us work in tech!
Soatok, the author of this blog.
But not all furries work in tech. You can find us in pretty much every vocation and profession imaginable.
Some furries work full-time as artists and content creators for the rest of the community. All of the art you’re seeing on this page of my fursona was the result of other artists’ work.
How Do Furries Go to the Bathroom?
Generally, fursuiters have to undress before they can do their business, then redress after.
Non-fursuiters? Same as anyone else.
Can I Hunt Furries?
No, that’s stupid.
Furries are humans (and humans are animals).
Wanting to hunt furries is completely sociopathic and immoral.
You’re effectively asking if it’s okay to commit murder against a predominantly LGBTQIA+ community.
But Since Furries Want to Be Animals, We Should Be Allowed to Hunt Them!
No, of course not. Not unless we can hunt you too, anyway!
“All is fair in love and vore,” or so they say. Art by ruemaw
No, but seriously, if you feel like you should be allowed to “hunt” other people, there is something deeply wrong with you and you should seek therapy before you hurt an innocent person.
Are Furries Legal?
Yes. Why wouldn’t we be?
There may be a lot of nuances to this question. (Are fursuits legal in $venue? That will depend on mask laws, etc.)
The author is demi/gay, if anyone was wondering ;3 – Art by Swizz
Those are all the appropriate and interesting questions I could find through Google’s search prediction feature. If I missed any that are worth including, let me know on Twitter or Telegram.
Copypasta is internet slang for any block of text that gets copied and pasted over and over again, typically disseminated by individuals through online discussion forums and social networking sites.
A lot of people online claim they “hate furries”, but almost none of them quite understand how prolific our community is, let alone how important we are to the Internet. As Stormi the Folf puts it…
I guarantee you the internet would collapse in a most horrific manner if all the furries in the world got Thano's snapped.
They *run* the internet in more ways than most people realize
Stormi is the Potato of Knowledge and Floof What Stormi’s alluding to is true, and that’s a tale best told by an outsider to our community.
Telecommunications as a whole, which also encompasses The Internet, is in a constant state of failure and just in time fixes and functionally all modern communication would collapse if about 50 people, most of which are furries, decided to turn their pager off for a day. t.co/k1UqOv5kpd
— Ẑ͚͔͍̻̤̟ä̶̼̗̟͔́̿̾̓n̬͙̫̿͑͊̈̚d̡̰̭̞͖̟̖̟ͬ̚ê̺͖̂ͩ̀̉ͣrͪ̓ (@mmsword) November 28, 2019
Their follow-up tweet that elaborates on furry involvement is here. So I’d like take the time to explain why nobody should ever underestimate the ingenuity or positivity of the furry community.
The Furry Fandom Has Saved Lives
youtube.com/embed/3h9sO17CV9A?… This is just one of many anecdotes. You can find many more here. Although the furry fandom is widely misunderstood, it’s difficult to overstate how many lives have been saved and enriched by our community.
I wanted to share this touching moment. @Reo_Grayfox was telling me his story, and said those lines while staring straight into his fursuit's eyes. Hearing personal stories like this makes you appreciate the vastly diverse reasons why the furry fandom is essential to so many. pic.twitter.com/fD09Wmv6mf
In 2016, refugees from the civil war in Syria ended up in a hotel in Canada. This would have been an utterly remarkable fact if it wasn’t the same hotel and weekend as the local furry convention, Vancoufur.
Artists and costume makers: I could literally link to hundreds of artists here. Follow me on Twitter; I retweet a lot of cute stuff.
Pretty much everything you could aspire to be that isn’t also terrible, if you look hard enough, you’ll find furries in the leaderboards having a fun time with it all.
Telegram was the first major chat platform that allowed custom sticker packs to be uploaded and used by its users. This led to the creation of a fuckton of sticker packs for peoples’ fursonas.
How many furry sticker packs are there? Well, my friend Nican started a project to collect and categorize them all. You can find their project online at bunnypa.ws.
Instead, they ran a vapid “contest” and point to that as evidence of their protocol’s security.
If you’re a cryptography nerd, then you probably already understand that IND-CCA2 security is necessary for confidential messaging. You’re probably cautious enough to not depend on Telegram’s MTProto for privacy.
If you’re not a cryptography nerd, then you probably don’t care about any of this jargon or what it means.
Telegram is best treated as a message board or a mailing list.
Use it for public communications, knowing full well that the world can read what you have to say. So long as that’s your threat model, you aren’t likely to ever get burned by the Durov family’s ego.
For anything that you’re not comfortable with being broadcast all over the Internet, you should use something more secure. Signal is the current recommended choice until something better comes along.
Last year, Telegram rolled out the ability to collect conversations, groups, and chats into folders. Most furries don’t know about this feature, because it doesn’t enable itself by default.
First, open the hamburger menu (on desktop) or click on your icon (on mobile), then click Settings.
Next, you’ll see an option for Folders.
You should see a button that says “Create New Folder”.
From here, you can include Chats or general types of Chats (All Groups, All Channels, All Personal Conversations) and then exclude specific entries.
Give it a name and press “Create”. After a bit of organizing, you might end up with a setup like this.
Now, here’s the cool thing (but sadly doesn’t exist on all clients–use Telegram Desktop on Windows and Linux if you want it).
Once you’re done setting up your folders, back out to the main interface on Desktop and right click one of the folders, then press “Mark As Read”.
Finally, an easy button to zero out your notifications. Serenity at last!
Note: Doing this to the special Unread folder is congruent to pressing Shift + ESC on Slack. You’re welcome, Internet!
Make Yourself Undiscoverable
In the default configuration, if anyone has your phone number in their address book (n.b. queerphobic relatives) and they install Telegram, you’ll get a notification about them joining.
As you can imagine, that’s a bit of a terrifying prospect for a lot of people. Fortunately, you can turn this off.
Under Settings > Privacy and Security > Phone Number, you can limit the discovery to your contacts (n.b. in your phone’s address book).
Turn Off Notifications for Pinned Messages
Under Settings > Notifications, you will find the appropriate checkbox under the Events heading.
A lot of furry Telegram groups like to notify all users whenever they pin a message. These notifications will even override your normal preferences if you disabled notifications for that group.
Also, you’re probably going to want to disable notifications for every channel / group / rando with very few exceptions, or else Telegram will quickly get super annoying.
Increase the Interface Scale
The default font size for Telegram is tiny. This is bad for accessibility.
Fortunately, you can make the font bigger. Open the Settings menu and scroll down past the first set of options.
Set the interface scale to at least 150%. It will require Telegram to re-launch itself to take effect.
Don’t Rely on Persistent Message History
This is just a cautionary footnote, especially if you’re dealing with someone with a reputation for gaslighting: The other participant in a conversation can, at any point in time, completely or selectively erase messages from your conversation history.
However, this doesn’t delete any messages you’ve already forwarded–be it to your Saved Messages or to a private Channel.
Aside: This is why, when someone gets outed for being a terrible human being, the evidence is usually preserved as forwarded messages to a channel.
Although Telegram isn’t in the same league as Signal and WhatsApp, its user experience is good–especially if you’re a furry.
I hope with the tips I shared above, as well as resources like bunnypa.ws, the Furry Telegram experience will be greatly improved for everyone that reads my blog.
Addendum: Beware the Furry Telegram Group List
A few people have asked me, “Why don’t you tell folks about furry-telegram-groups.net and/or @furlistbot?”
The main reason is that a lot of the most popular groups on that listing are either openly or secretly run by a toxic personality cult called Furry Valley that I implore everyone to avoid.
Welcome back to Cryptography Dispatches, my lightly edited newsletter on cryptography engineering. PSA: I've been doing some livecoding on my Twitch channel,...
Search engines have this feature where if you start to type a question, it will attempt to predict your question based on what other people have asked.
This has some hilarious consequences. The PDF file format is apparently the world’s one of the world’s four most popular religions, or so the meme goes. Sometimes this feature gets gamed by large hordes of shitty people (read: 4chan) typing provocative questions into search engines.
Let’s take a look at some of the questions that real people and/or astroturfing trolls have asked Google about the furry fandom and its members.
Answers to Questions People Asked Google About Furries
Note: This is just a subset of all the questions that showed up in Google’s autocomplete for various questions about furries. A lot of the questions are inappropriate or are framed so poorly that they’re not worth answering in the first place.
Soatok is here to answer your burning curiosity.
Do Furries Have Rights?
Yes. Specifically: The same rights as anyone else in the country they live in.
Do Furries Say UwU?
UwU
Do Furries Deserve Rights?
Yes.
I’m glad that matter’s settled, aren’t you?
Do Furries Talk?
If we didn’t, people wouldn’t be so desperate to shut us up, now would they?
But some fursuiters do choose to remain silent in fursuit.
Do Furries Want to Be Animals?
We already are animals: Humans are animals.
I mean, really, the only other options are vegetable, mineral, fungus, or microbe.
Do Furries Want to Be Non-Human Animals?
Much better question!
Generally, no.
The people who believe they are (spiritually or otherwise) a non-human animal are called otherkin or therian, not furries.
This really shouldn’t surprise anyone. Furries are nerds. Nerds go to cons.
Do Furries Go to the Vet?
No.
Not only do we not go to the vet, but we’ve historically done a poor job of vetting the people who rise in popularity in our community… which usually resulted in completely avoidable PR disasters that trolls happily abuse, to this day, to try to astroturf the general public into thinking we’re horribly depraved people.
See what I did there? :3
Why Do Furries Matter?
That’s a rather nihilistic question to ask, and it was the most popular “why?” question, to boot.
Namely, the furry fandom saves lives, provides a support system for a lot of LGBTQIA+ people, and is home to some of the best humans you’ll ever meet (including many that are absolutely vital to modern telecommunications infrastructure, i.e. the Internet).
But at the end of the day, this is a deeply personal question and will ultimately boil down to individual opinion and thus is unanswerable.
Why Do Furries Use Telegram?
Counter-question: Have you ever heard of the network effect?
Telegram supported custom stickers before any other major communication medium, so they’ve been accumulating furries for many years before the other platforms caught up.
What other platform makes it easy to respond with this image when socially appropriate? Sticker by Khia, Telegram sticker pack here.
The main reasons furries choose Telegram today are:
Their friends are already using it
They can effectively reply to messages with custom stickers of their fursona, rather than just plaintext or emoji
That being said, many furries these days use Discord too. Main reasons: Gaming and streaming.
If you’d like to learn more about furries and Telegram, and furries using Telegram, and how to make Telegram bearable, check out A Furry’s Guide to Telegram.
Why Do Furries Like Foxes?
Oh contrare!
Just kidding! This sticker’s meaning is “I’m not a fox!” not “Down with foxes!”
There really isn’t a good answer to this question.
The best approximation you’ll find is that: Foxes used to be an extremely popular choice in cartoon animal character design (Disney’s Robin Hood, Star Fox 64, Sajin Komamura from Bleach, etc.).
It’s an emoticon! OwO is like a sideways :3 face, but with surprised eyes. It comes from copypasta started by a shitpost mocking the typical behavior and communication style of furry roleplayers.
How Do Furries Talk?
Rather well, thank you.
Oh wait, you wanted to know about the anatomy that enables speech? Ask a biologist with a passing interest in science fiction and/or werewolves.
Severely allergic. But that’s just me. Photo by Kurdan. Feline fursonas (cats of all sizes) are almost as common as canid fursonas (wolves, foxes, etc.).
If you’re expecting to see us fight like cats and dogs, you’re in for some disappointment.
How Do Furries Make Money?
A lot of us work in tech!
Soatok, the author of this blog.
But not all furries work in tech. You can find us in pretty much every vocation and profession imaginable.
Some furries work full-time as artists and content creators for the rest of the community. All of the art you’re seeing on this page of my fursona was the result of other artists’ work.
How Do Furries Go to the Bathroom?
Generally, fursuiters have to undress before they can do their business, then redress after.
Non-fursuiters? Same as anyone else.
Can I Hunt Furries?
No, that’s stupid.
Furries are humans (and humans are animals).
Wanting to hunt furries is completely sociopathic and immoral.
You’re effectively asking if it’s okay to commit murder against a predominantly LGBTQIA+ community.
But Since Furries Want to Be Animals, We Should Be Allowed to Hunt Them!
No, of course not. Not unless we can hunt you too, anyway!
“All is fair in love and vore,” or so they say. Art by ruemaw
No, but seriously, if you feel like you should be allowed to “hunt” other people, there is something deeply wrong with you and you should seek therapy before you hurt an innocent person.
Are Furries Legal?
Yes. Why wouldn’t we be?
There may be a lot of nuances to this question. (Are fursuits legal in $venue? That will depend on mask laws, etc.)
The author is demi/gay, if anyone was wondering ;3 – Art by Swizz
Those are all the appropriate and interesting questions I could find through Google’s search prediction feature. If I missed any that are worth including, let me know on Twitter or Telegram.
When someone says, “I hate furries,” that’s a dog-whistle for anti-queer bigotry. If it’s not immediately clear why this is the case, I’ll explain why this is true. Observation: Homophobia is…
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.
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 o
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.
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).
(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.
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”.
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.
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.
Android doesn’t limit you to one Google account per device. As with Windows and macOS, you can set up multiple logins and switch between them — assuming your version of Android includes this feature.
Telegram was the first major chat platform that allowed custom sticker packs to be uploaded and used by its users. This led to the creation of a fuckton of sticker packs for peoples’ fursonas.
How many furry sticker packs are there? Well, my friend Nican started a project to collect and categorize them all. You can find their project online at bunnypa.ws.
Instead, they ran a vapid “contest” and point to that as evidence of their protocol’s security.
If you’re a cryptography nerd, then you probably already understand that IND-CCA2 security is necessary for confidential messaging. You’re probably cautious enough to not depend on Telegram’s MTProto for privacy.
If you’re not a cryptography nerd, then you probably don’t care about any of this jargon or what it means.
Telegram is best treated as a message board or a mailing list.
Use it for public communications, knowing full well that the world can read what you have to say. So long as that’s your threat model, you aren’t likely to ever get burned by the Durov family’s ego.
For anything that you’re not comfortable with being broadcast all over the Internet, you should use something more secure. Signal is the current recommended choice until something better comes along.
Last year, Telegram rolled out the ability to collect conversations, groups, and chats into folders. Most furries don’t know about this feature, because it doesn’t enable itself by default.
First, open the hamburger menu (on desktop) or click on your icon (on mobile), then click Settings.
Next, you’ll see an option for Folders.
You should see a button that says “Create New Folder”.
From here, you can include Chats or general types of Chats (All Groups, All Channels, All Personal Conversations) and then exclude specific entries.
Give it a name and press “Create”. After a bit of organizing, you might end up with a setup like this.
Now, here’s the cool thing (but sadly doesn’t exist on all clients–use Telegram Desktop on Windows and Linux if you want it).
Once you’re done setting up your folders, back out to the main interface on Desktop and right click one of the folders, then press “Mark As Read”.
Finally, an easy button to zero out your notifications. Serenity at last!
Note: Doing this to the special Unread folder is congruent to pressing Shift + ESC on Slack. You’re welcome, Internet!
Make Yourself Undiscoverable
In the default configuration, if anyone has your phone number in their address book (n.b. queerphobic relatives) and they install Telegram, you’ll get a notification about them joining.
As you can imagine, that’s a bit of a terrifying prospect for a lot of people. Fortunately, you can turn this off.
Under Settings > Privacy and Security > Phone Number, you can limit the discovery to your contacts (n.b. in your phone’s address book).
Turn Off Notifications for Pinned Messages
Under Settings > Notifications, you will find the appropriate checkbox under the Events heading.
A lot of furry Telegram groups like to notify all users whenever they pin a message. These notifications will even override your normal preferences if you disabled notifications for that group.
Also, you’re probably going to want to disable notifications for every channel / group / rando with very few exceptions, or else Telegram will quickly get super annoying.
Increase the Interface Scale
The default font size for Telegram is tiny. This is bad for accessibility.
Fortunately, you can make the font bigger. Open the Settings menu and scroll down past the first set of options.
Set the interface scale to at least 150%. It will require Telegram to re-launch itself to take effect.
Don’t Rely on Persistent Message History
This is just a cautionary footnote, especially if you’re dealing with someone with a reputation for gaslighting: The other participant in a conversation can, at any point in time, completely or selectively erase messages from your conversation history.
However, this doesn’t delete any messages you’ve already forwarded–be it to your Saved Messages or to a private Channel.
Aside: This is why, when someone gets outed for being a terrible human being, the evidence is usually preserved as forwarded messages to a channel.
Although Telegram isn’t in the same league as Signal and WhatsApp, its user experience is good–especially if you’re a furry.
I hope with the tips I shared above, as well as resources like bunnypa.ws, the Furry Telegram experience will be greatly improved for everyone that reads my blog.
Addendum: Beware the Furry Telegram Group List
A few people have asked me, “Why don’t you tell folks about furry-telegram-groups.net and/or @furlistbot?”
The main reason is that a lot of the most popular groups on that listing are either openly or secretly run by a toxic personality cult called Furry Valley that I implore everyone to avoid.
Welcome back to Cryptography Dispatches, my lightly edited newsletter on cryptography engineering. PSA: I've been doing some livecoding on my Twitch channel,...
Beinahe eine philosophische Persönlichkeit. Es ist wohl eine jener zum Glück seltenen, aber absolut ideenlosen Zeiten, die jetzt schon drei Tage andauert. Wieder […]
Thinking of Aaron Swartz today & I’m stuck on this photo - he & OpenAI CEO Sam Altman (both circled) each scraped 1000s of docs but one did it to make the knowledge free for all while the other did it to make $$$$ through probabilistic plagiarism. The US DOJ only came after one of them & the other is feted by tech bros and executives.
Thank you Aaron for so much, for RSS, for Markdown, for Creative Commons and more. I’m sorry our society failed you.
"Weit über 30 Jahre haben wir gekämpft ... tausende von Freizeitstunden geopfert und investiert. Kunstbauwerke wie Brücken, Stützmauern, Durchlässe und den Tunnel saniert und wieder instandgesetzt.
Gleisbauarbeiten, Beschilderungen, auch Entwässerungen... Freischnittarbeiten... die Liste könnte noch erheblich verlängert werden...
Nun ist es endlich soweit. Der Durchhaltewillen und die Mühen haben sich gelohnt.
Unsere Strecke ist abgenommen und darf nach §7f nun endlich wieder im Güter- und Personenverkehr betrieben werden.
Ein Grund zum Feiern. Am 8. und 9. Februar verkehrt ein historischer Zug in dem auch unsere vereinseigene Donnerbüchse mitläuft zwischen Wuppertal-Oberbarmen und Wuppertal-Beyenburg.
Samstag, 08.02.2025
• 09:45 Abfahrt des Eröffnungszuges in Wuppertal Hbf (Keine Mitfahrt möglich!) • 10:20 Ankunft des Eröffnungszuges in W-Beyenburg • 10:30 Feierliche Eröffnung • 12:00 bis 18:00 Stündliche Pendelfahrten in Oberb
... mehr anzeigen
"Weit über 30 Jahre haben wir gekämpft ... tausende von Freizeitstunden geopfert und investiert. Kunstbauwerke wie Brücken, Stützmauern, Durchlässe und den Tunnel saniert und wieder instandgesetzt.
Gleisbauarbeiten, Beschilderungen, auch Entwässerungen... Freischnittarbeiten... die Liste könnte noch erheblich verlängert werden...
Nun ist es endlich soweit. Der Durchhaltewillen und die Mühen haben sich gelohnt.
Unsere Strecke ist abgenommen und darf nach §7f nun endlich wieder im Güter- und Personenverkehr betrieben werden.
Ein Grund zum Feiern. Am 8. und 9. Februar verkehrt ein historischer Zug in dem auch unsere vereinseigene Donnerbüchse mitläuft zwischen Wuppertal-Oberbarmen und Wuppertal-Beyenburg.
Samstag, 08.02.2025
• 09:45 Abfahrt des Eröffnungszuges in Wuppertal Hbf (Keine Mitfahrt möglich!) • 10:20 Ankunft des Eröffnungszuges in W-Beyenburg • 10:30 Feierliche Eröffnung • 12:00 bis 18:00 Stündliche Pendelfahrten in Oberbarmen, Essen- und Getränkeverkauf in Beyenburg
Sonntag, 09.02.2025
• 10:00 bis 18:00 Stündliche Pendelfahrten in Oberbarmen, Beginn Essen- und Getränkeverkauf
Leider befindet sich unsere Vereiseigene V60 in der Hauptuntersuchung und steht für die Fahrten nicht zur Verfügung.
Dennoch würden wir uns freuen möglichst viele Eisenbahnfreunde und -freundinnen, natürlich auch Nicht-Eisenbahnfreunde am und vor allem in den Zügen begrüssen zu können.
Feiern sie mit uns diesen besonderen Anlass, auf ein Wiedersehen im Tal der Wupper,
Nach 30 Jahren harter Arbeit haben es die Freiwilligen des Wupperschiene e.V. geschafft: am Wochenende 08./09.02 wird die Wuppertalbahn von Wuppertal-Oberbarmen bis Wuppertal-Beyenburg feierlich wieder eröffnet. Von 12 bzw.
https://media.ccc.de/v/38c3-we-ve-not-been-trained-for-this-life-after-the-newag-drm-disclosureYou've probably already heard the story: we got contracted to ...
It would be nice to have our little events outside of the all seeing eyes of the billionaires on a server that we all own that we could call Friendica.vg. We need to have platform that respects human rights and actively combats against misinformation, not whatever Facebook is.
I have a feeling they were sharing the information they collect about us to provide the cops and corporations the ability push back against the vegan movement.
Facebook would gladly side with Trump, Cargil, JBS over you, so dont give them an opening to hurt you.
Irgendwie war heute fast alles nichts Richtiges. Zuerst wollte ich ein Zitat von Peter Hacks über die Entstehung von Gedichten hier erscheinen lassen. Dann versuchte ich mich selbst […]
Viele der Projekte befinden sich in einem sehr frühen Planungsstadium. Allerdings registrieren auch Verteilnetzbetreiber teilweise viele Netzanschlussfragen für große Batteriespeicher.
Erstaunlich. Kann mir gut vorstellen, dass einige der Projekte recht schnell umgesetzt werden, wenn die Genehmigung vorhanden ist und die Finanzierung passt. Denn die Technik ist vorhanden und in anderen Teilen der Welt schon im Einsatz
Art: Scruff
messages, each with a max length of
bytes.
to
bytes.
Art: CMYKat
Lazy edit of the “Friendship Ended” meme
CMYKat made this
Art: ScruffKerfluff
as any one-way transformation of some arbitrary-length string (
) to a fixed-length, deterministic, pseudo-random output.
Note: When in doubt, I err on the side of being easily understood by non-experts over pedantic precision. (Art by Swizz)
, it should be difficult to find
such that
) such that
trial messages to find a collision.
will, for two arbitrary messages and a sufficient number of iterations, converge on a single hash output.
for some integer
.
(that is to say,
).
is
).
, and cycle length should be
, which means for a 256-bit hash you should expect a cycle after about
or about 128 bits, and the average cycle length will be about
. Thanks Riastradh for the corrections.
trial hashes. This is cheap enough to try on a typical laptop.
.
.
until
.
“What do you mean I don’t have a petabyte of RAM at my disposal?”
, for an n-bit hash function), not much. (This is just for fun, after all!)
Definitely fun to think about though! (Art by circuitslime)
(Art by Khia. Poorly edited by the author.)
blocks of the underlying ciphertext.
bytes (or 68,719,476,480 bytes). This is approximately 68 GB or 64 GiB.
messages safely. Hooray!
Hooray!
Confound you, technical limitations!
blocks with AES because the keystream blocks–as the output of a block cipher–cannot repeat.
possible values, you should expect a single collision(with 50% probability) after
(or
)samples. This is called the birthday bound.
(for a random nonce between 0 and
messages.
bytes
, or 274,877,906,880 bytes–nearly 256 GiB for each (nonce, key) pair.
bytes
A significant improvement, but still practically limited.
distinct keys).
blocks. Each block is 64 bytes, so that changes the maximum message length to about
(but you probably don’t have this luxury in the real world)
bytes
My canned response to most queries about AES-CBC.
(Art by Riley.)
blocks.
bytes of plaintext. If you’re using PKCS#7 padding, keep in mind that this will include an entire padding block per message, so your safety margin will deplete a bit faster (depending on how many individual messages you encrypt, and therefore how many padding blocks you need).
or about 4.22 PiB of data.
blocks could be anywhere from
bytes of real plaintext. When in situations like this, we have to assume the worst (n.b. take the most conservative value).
Yet another reason to dislike non-AEAD ciphers.
(Art by Khia.)
(Art by Khia.)
I have strong opinions about cryptographic library design.
The sections labeled “This work” are what’s new/significant about this research.
Table 3 from the LadderLeak paper.
It’s complicated!
) to protect the secret key, EdDSA derives the per-signature nonce deterministically from a hash of the secret key and message.
Art by Kyume.
Repeat after me: “I will not roll my own crypto before I’m ready.” Art by AtlasInu.
(Art by Khia.)
(Art by Khia.)
“Sick fursona, bro.”
What you see if you type “COVID-19 statistics” into a search engine. Data sourced from Wikipedia.
Art by circuitslime.
Art by Swizz.
Art by Khia
It doesn’t take a lot of imagination to see where that goes. (Art by Khia.)
Art by INIGO.
Art by SkiaSkai
No more Angry Whoppers for you, mister!
Art by RueMaw.
Image source and backstory of this meme: Dogpatch Press
90s furries built the Internet pic.twitter.com/Gicxme2HkT
“All is fair in love and vore,” or so they say. Art by ruemaw
wakest ⁂
Als Antwort auf Teknevra • • •.Donuts
Als Antwort auf Teknevra • • •For sure, if only out of spite for Pinterest poisoning image search results with low quality, unusable junk.
I'd like to see actual content, with original credits and a way to credit them if it's a repost. Repin?
abeorch
Als Antwort auf .Donuts • • •I saw #pinry - github.com/pinry/pinry/ - Haven't tried it - can't vouch for it .. but is that what you are looking for?
@Teknevra
wakest ⁂
Als Antwort auf abeorch • • •