Dhole Moments

2024-09-13 10:25:12

In 2022, I wrote about my plan to build end-to-end encryption for the Fediverse. The goals were simple:

1. Provide secure encryption of message content and media attachments between Fediverse users, as a new type of Direct Message which is encrypted between participants.
2. Do not pretend to be a Signal competitor.

The primary concern at the time was “honest but curious” Fediverse instance admins who might snoop on another user’s private conversations.

After I finally was happy with the client-side secret key management piece, I had moved on to figure out how to exchange public keys. And that’s where things got complicated, and work stalled for 2 years.

Art: AJ

I wrote a series of blog posts on this complication, what I’m doing about it, and some other cool stuff in the draft specification.

• Towards Federated Key Transparency introduced the Public Key Directory project
• Federated Key Transparency Project Update talked about some of the trade-offs I made in this design
  
  • Not supporting ECDSA at all, since FIPS 186-5 supports Ed25519
  • Adding an account recovery feature, which power users can opt out of, that allows instance admins to help a user recover from losing all their keys
  • Building a Key Transparency system that can tolerate GDPR Right To Be Forgotten takedown requests without invalidating history

  
  

• Introducing Alacrity to Federated Cryptography discussed how I plan to ensure that independent third-party clients stay up-to-date or lose the ability to decrypt messages

Recently, NIST published the new Federal Information Protection Standards documents for three post-quantum cryptography algorithms:

• FIPS-203 (ML-KEM, formerly known as CRYSTALS-Kyber),
• FIPS-204 (ML-DSA, formerly known as CRYSTALS-Dilithium)
• FIPS-205 (SLH-DSA, formerly known as SPHINCS+)

The race is now on to implement and begin migrating the Internet to use post-quantum KEMs. (Post-quantum signatures are less urgent.) If you’re curious why, this CloudFlare blog post explains the situation quite well.

Since I’m proposing a new protocol and implementation at the dawn of the era of post-quantum cryptography, I’ve decided to migrate the asymmetric primitives used in my proposals towards post-quantum algorithms where it makes sense to do so.

Art: AJ

The rest of this blog post is going to talk about technical specifics and the decisions I intend to make in both projects, as well as some other topics I’ve been thinking about related to this work.

Which Algorithms, Where?

I’ll discuss these choices in detail, but for the impatient:

• Public Key Directory
  
  • Still just Ed25519 for now

  
  

• End-to-End Encryption
  
  • KEMs: X-Wing (Hybrid X25519 and ML-KEM-768)
  • Signatures: Still just Ed25519 for now

  
  

Virtually all other uses of cryptography is symmetric-key or keyless (i.e., hash functions), so this isn’t a significant change to the design I have in mind.

Post-Quantum Algorithm Selection Criteria

While I am personally skeptical if we will see a practical cryptography-relevant quantum computer in the next 30 years, due to various engineering challenges and a glacial pace of progress on solving them, post-quantum cryptography is still a damn good idea even if a quantum computer doesn’t emerge.

Post-Quantum Cryptography comes in two flavors:

1. Key Encapsulation Mechanisms (KEMs), which I wrote about previously.
2. Digital Signature Algorithms (DSAs).

Originally, my proposals were going to use Elliptic Curve Diffie-Hellman (ECDH) in order to establish a symmetric key over an untrusted channel. Unfortunately, ECDH falls apart in the wake of a crypto-relevant quantum computer. ECDH is the component that will be replaced by post-quantum KEMs.

Additionally, my proposals make heavy use of Edwards Curve Digital Signatures (EdDSA) over the edwards25519 elliptic curve group (thus, Ed25519). This could be replaced with a post-quantum DSA (e.g., ML-DSA) and function just the same, albeit with bandwidth and/or performance trade-offs.

But isn’t post-quantum cryptography somewhat new?

Lattice-based cryptography has been around almost as long as elliptic curve cryptography. One of the first designs, NTRU, was developed in 1996.

Meanwhile, ECDSA was published in 1992 by Dr. Scott Vanstone (although it was not made a standard until 1999). Lattice cryptography is pretty well-understood by experts.

However, before the post-quantum cryptography project, there hasn’t been a lot of incentive for attackers to study lattices (unless they wanted to muck with homomorphic encryption).

So, naturally, there is some risk of a cryptanalysis renaissance after the first post-quantum cryptography algorithms are widely deployed to the Internet.

However, this risk is mostly a concern for KEMs, due to the output of a KEM being the key used to encrypt sensitive data. Thus, when selecting KEMs for post-quantum security, I will choose a Hybrid construction.

Hybrid what?

We’re not talking folfs, sonny!

Hybrid isn’t just a thing that furries do with their fursonas. It’s also a term that comes up a lot in cryptography.

Unfortunately, it comes up a little too much.
I made this dumb meme with imgflip
When I say we use Hybrid constructions, what I really mean is we use a post-quantum KEM and a classical KEM (such as HPKE‘s DHKEM), then combine them securely using a KDF.

Post-quantum KEMs

For the post-quantum KEM, we only really have one choice: ML-KEM. But this choice is actually three choices: ML-KEM-512, ML-KEM-768, or ML-KEM-1024.

The security margin on ML-KEM-512 is a little tight, so most cryptographers I’ve talked with recommend ML-KEM-768 instead.

Meanwhile, the NSA wants the US government to use ML-KEM-1024 for everything.

How will you hybridize your post-quantum KEM?

Originally, I was looking to use DHKEM with X25519, as part of the HPKE specification. After switching to post-quantum cryptography, I would need to combine it with ML-KEM-768 in such a way that the whole shebang is secure if either component is secure.

But then, why reinvent the wheel here? X-Wing already does that, and has some nice binding properties that a naive combination might not.

So let’s use X-Wing for our KEM.

Notably, OpenMLS is already doing this in their next release.

Art: CMYKat

Post-quantum signatures

So our KEM choice seems pretty straightforward. What about post-quantum signatures?

Do we even need post-quantum signatures?

Well, the situation here is not nearly as straightforward as KEMs.

For starters, NIST chose to standardize two post-quantum digital signature algorithms (with a third coming later this year). They are as follows:

• ML-DSA (formerly CRYSTALS-Dilithium), that comes in three flavors:
  
  • ML-DSA-44
  • ML-DSA-65
  • ML-DSA-87

  
  

• SLH-DSA (formerly SPHINCS+), that comes in 24 flavors
• FN-DSA (formerly FALCON), that comes in two flavors but may be excruciating to implement in constant-time (this one isn’t standardized yet)

Since we’re working at the application layer, we’re less worried about a few kilobytes of bandwidth than the networking or X.509 folks are. Relatively speaking, we care about security first, performance second, and message size last.

After all, people ship Electron, React Native, and NextJS apps that load megabytes of JavaScript code to print, “hello world,” and no one bats an eye. A few kilobytes in this context is easily digestible for us.

(As I said, this isn’t true for all layers of the stack. WebPKI in particular feels a lot of pain with large public keys and/or signatures.)

Eliminating post-quantum signature candidates

Performance considerations would eliminate SLH-DSA, which is the most conservative choice. Even with the fastest parameter set (SLH-DSA-128f), this family of algorithms is about 550x slower than Ed25519. (If we prioritize bandwidth, it becomes 8000x slower.)

Adopted from CloudFlare’s blog post on post-quantum cryptography.

Between the other two, FN-DSA is a tempting option. Although it’s difficult to implement in constant-time, it offers smaller public key and signature sizes.

However, FN-DSA is not standardized yet, and it’s only known to be safe on specific hardware architectures. (It might be safe on others, but that’s not proven yet.)

In order to allow Fediverse users be secure on a wider range of hardware, this uncertainty would limit our choice of post-quantum signature algorithms to some flavor of ML-DSA–whether stand-alone or in a hybrid construction.

Unlike KEMs, hybrid signature constructions may be problematic in subtle ways that I don’t want to deal with. So if we were to do anything, we would probably choose a pure post-quantum signature algorithm.

Against the Early Adoption of Post-Quantum Signatures

There isn’t an immediate benefit to adopting a post-quantum signature algorithm, as David Adrian explains.

The migration to post-quantum cryptography will be a long and difficult road, which is all the more reason to make sure we learn from past efforts, and take advantage of the fact the risk is not imminent. Specifically, we should avoid:

• Standardizing without real-world experimentation
• Standardizing solutions that match how things work currently, but have significant negative externalities (increased bandwidth usage and latency), instead of designing new things to mitigate the externalities
• Deploying algorithms pre-standardization in ways that can’t be easily rolled back
• Adding algorithms that are pre-standardization or have severe shortcomings to compliance frameworks

We are not in the middle of a post-quantum emergency, and nothing points to a surprise “Q-Day” within the next decade. We have time to do this right, and we have time for an iterative feedback loop between implementors, cryptographers, standards bodies, and policymakers.

The situation may change. It may become clear that quantum computers are coming in the next few years. If that happens, the risk calculus changes and we can try to shove post-quantum cryptography into our existing protocols as quickly as possible. Thankfully, that’s not where we are.

David Adrian, Lack of post-quantum security is not plaintext.

Furthermore, there isn’t currently any commitment from the Sigsum developers to adopt a post-quantum signature scheme in the immediate future. They hard-code Ed25519 for the current iteration of the specification.

The verdict on digital signature algorithms?

Given all of the above, I’m going to opt to simply not adopt post-quantum signatures until a later date.

Version 1 of our design will continue to use Ed25519 despite it not being secure after quantum computers emerge (“Q-Day”).

When the security industry begins to see warning signs of Q-Day being realistically within a decade, we will prioritize migrating to use post-quantum signature algorithms in a new version of our design.

Should something drastic happen that would force us to decide on a post-quantum algorithm today, we would choose ML-DSA-44. However, that’s unlikely for at least several years.

Remember, Store Now, Decrypt Later doesn’t really break signatures the way it would break public-key encryption.

Art: Harubaki

Miscellaneous Technical Matters

Okay, that’s enough about post-quantum for now. I worry that if I keep talking about key encapsulation, some of my regular readers will start a shitty garage band called My KEMical Romance before the end of the year.

CMYKat

Let’s talk about some other technical topics related to end-to-end encryption for the Fediverse!

Federated MLS

MLS was implicitly designed with the idea of having one central service for passing messages around. This makes sense if you’re building a product like Signal, WhatsApp, or Facebook Messenger.

It’s not so great for federated environments where your Delivery Service may be, in fact, more than one service (i.e., the Fediverse). An expired Internet Draft for Federated MLS talks about these challenges.

If we wanted to build atop MLS for group key agreement (like has been suggested before), we’d need to tackle this in a way that doesn’t cede control of MLS epochs to any server that gets compromised.

CMYKat

How to Make MLS Tolerate Federation

First, the Authentication Service component can be replaced by client-side protocols, where public keys are sourced from the Public Key Directory (PKD) services.

That is to say, from the PKD, you can fetch a valid list of Ed25519 public keys for each participant in the group.

When a group is created, the creator’s Ed25519 public key is known. Everyone they invite, their software necessarily has to know their Ed25519 public key in order to invite them.

In order for a group action to be performed, it must be signed by one of the public keys enrolled into the group list. Additionally, some actions may be limited by permissions attached at the time of the invite (or elevated by a more privileged user; which necessitates another group action).

By requiring a valid signature from an existing group member, we remove the capability of the Fediverse instance that’s hosting the discussion group to meddle with it in any way (unless, for some reason, the server is somehow also a participant that was invited).

But therein lies the other change we need to make: In many cases, groups will span multiple Fediverse servers, so groups shouldn’t be dependent on a single instance.

Spreading The Load Across Instances

Put simply, we need a consensus algorithm to determine which instance hosts messages. We could look to Raft as a starting point, but whatever we land on should be fair, fault-tolerant, and deterministic to all participants who can agree on the same symmetric keying material at some point in time.

To that end, I propose using an additional HKDF output from the Group Key Agreement protocol to select a “leader” for all instances involved in the group, weighted by the number of participants on each instance.

Then, every N messages (where N >= 1), a new leader is elected by the same deterministic protocol. This will be performed entirely client-side, and clients will choose N. I will refer to this as a sub-epoch, since it doesn’t coincide with a new MLS epoch.

Since the agreed-upon group key always ratchets forward when a group action occurs (i.e., whenever there’s a new epoch), getting another KDF output to elect the next leader is straightforward.

This isn’t a fully fleshed out idea. Building consensus protocols that can handle real-world operational issues is heavily specialized work and there’s a high risk of falling to the illusion of safety until it’s too late. I will probably need help with this component.

That said, we aren’t building an anonymity network, so the cost of getting a detail wrong isn’t measurable in blood.

We aren’t really concerned with Sybil attacks. Winning the election just means you’re responsible for being a dumb pipe for ciphertext. Client software should trust the instance software as little as possible.

We also probably don’t need to worry about availability too much. Since we’re building atop ActivityPub, when a server goes down, the other instances can hold encrypted messages in the outbox for the host instance to pick up when it’s back online.

If that’s not satisfactory, we could also select both a primary and secondary leader for each epoch (and sub-epoch), to have built-in fail-over when more than one instance is involved in a group conversation.

If messages aren’t being delivered for an unacceptable period of time, client software can forcefully initiate a new leader election by expiring the current MLS epoch (i.e. by rotating their own public key and sending the relevant bundle to all other participants).

Art: Kyume

Those are just some thoughts. I plan to talk it over with people who have more expertise in the relevant systems.

And, as with the rest of this project, I will write a formal specification for this feature before I write a single line of production code.

Abuse Reporting

I could’ve swore I talked about this already, but I can’t find it in any of my previous ramblings, so here’s a good place as any.

The intent for end-to-end encryption is privacy, not secrecy.

What does this mean exactly? From the opening of Eric Hughes’ A Cypherpunk’s Manifesto:

Privacy is necessary for an open society in the electronic age. Privacy is not secrecy.

A private matter is something one doesn’t want the whole world to know, but a secret matter is something one doesn’t want anybody to know.

Privacy is the power to selectively reveal oneself to the world.

Eric Hughes (with whitespace and emphasis added)

Unrelated: This is one reason why I use “secret key” when discussing asymmetric cryptography, rather than “private key”. It also lends towards sk and pk as abbreviations, whereas “private” and “public” both start with the letter P, which is annoying.

With this distinction in mind, abuse reporting is not inherently incompatible with end-to-end encryption or any other privacy technology.

In fact, it’s impossible to create useful social technology without the ability for people to mitigate abuse.

So, content warning: This is going to necessarily discuss some gross topics, albeit not in any significant detail. If you’d rather not read about them at all, feel free to skip this section.

Art: CMYKat

When thinking about the sorts of problems that call for an abuse reporting mechanism, you really need to consider the most extreme cases, such as someone joining group chats to spam unsuspecting users with unsolicited child sexual abuse material (CSAM), flashing imagery designed to trigger seizures, or graphic depictions of violence.

That’s gross and unfortunate, but the reality of the Internet.

However, end-to-end encryption also needs to prioritize privacy over appeasing lazy cops who would rather everyone’s devices include a mandatory little cop that watches all your conversations and snitches on you if you do anything that might be illegal, or against the interest of your government and/or corporate masters. You know the type of cop. They find privacy and encryption to be rather inconvenient. After all, why bother doing their jobs (i.e., actual detective work) when you can just criminalize end-to-end encryption and use dragnet surveillance instead?

Whatever we do, we will need to strike a balance that protects users’ privacy, without any backdoors or privileged access for lazy cops, with community safety.

Thus, the following mechanisms must be in place:

1. Groups must have the concept of an “admin” role, who can delete messages on behalf of all users and remove users from the group. (Signal currently doesn’t have this.)
2. Users must be able to delete messages on their own device and block users that send abusive content. (The Fediverse already has this sort of mechanism, so we don’t need to be inventive here.)
3. Users should have the ability to report individual messages to the instance moderators.

I’m going to focus on item 3, because that’s where the technically and legally thorny issues arise.

Keep in mind, this is just a core-dump of thoughts about this topic, and I’m not committing to anything right now.

Technical Issues With Abuse Reporting

First, the end-to-end encryption must be immune to Invisible Salamanders attacks. If it’s not, go back to the drawing board.

Every instance will need to have a moderator account, who can receive abuse reports from users. This can be a shared account for moderators or a list of moderators maintained by the server.

When an abuse report is sent to the moderation team, what needs to happen is that the encryption keys for those specific messages are re-wrapped and sent to the moderators.

So long as you’re using a forward-secure ratcheting protocol, this doesn’t imply access to the encryption keys for other messages, so the information disclosed is limited to the messages that a participant in the group consents to disclosing. This preserves privacy for the rest of the group chat.

When receiving a message, moderators should not only be able to see the reported message’s contents (in the order that they were sent), but also how many messages were omitted in the transcript, to prevent a type of attack I colloquially refer to as “trolling through omission”. This old meme illustrates the concept nicely:
Trolling through omission.
And this all seems pretty straightforward, right? Let users protect themselves and report abuse in such a way that doesn’t invalidate the privacy of unrelated messages or give unfettered access to the group chats. “Did Captain Obvious write this section?”

But things aren’t so clean when you consider the legal ramifications.

Harubaki

Potential Legal Issues With Abuse Reporting

Suppose Alice, Bob, and Troy start an encrypted group conversation. Alice is the group admin and delete messages or boot people from the chat.

One day, Troy decides to send illegal imagery (e.g., CSAM) to the group chat.

Bob immediately, disgusted, reports it to his instance moderator (Dave) as well as Troy’s instance moderator (Evelyn). Alice then deletes the messages for her and Bob and kicks Troy from the chat.

Here’s where the legal questions come in.

If Dave and Evelyn are able to confirm that Troy did send CSAM to Alice and Bob, did Bob’s act of reporting the material to them count as an act of distribution (i.e., to Dave and/or Evelyn, who would not be able to decrypt the media otherwise)?

If they aren’t able to confirm the reports, does Alice’s erasure count as destruction of evidence (i.e., because they cannot be forwarded to law enforcement)?

Are Bob and Alice legally culpable for possession? What about Dave and Evelyn, whose servers are hosting the (albeit encrypted) material?

It’s not abundantly clear how the law will intersect with technology here, nor what specific technical mechanisms would need to be in place to protect Alice, Bob, Dave, and Evelyn from a particularly malicious user like Troy.

Obviously, I am not a lawyer. I have an understanding with my lawyer friends that I will not try to interpret law or write my own contracts if they don’t roll their own crypto.

That said, I do have some vague ideas for mitigating the risk.

Ideas For Risk Mitigation

To contend with this issue, one thing we could do is separate the abuse reporting feature from the “fetch and decrypt the attached media” feature, so that while instance moderators will be capable of fetching the reported abuse material, it doesn’t happen automatically.

When the “reason” attached to an abuse report signals CSAM in any capacity, the client software used by moderators could also wholesale block the download of said media.

Whether that would be sufficient mitigate the legal matters raised previously, I can’t say.

And there’s still a lot of other legal uncertainty to figure out here.

• Do instance moderators actually have a duty to forward CSAM reports to law enforcement?
  
  • If so, how should abuse forwarding to be implemented?
  • How do we train law enforcement personnel to receive and investigate these reports WITHOUT frivolously arresting the wrong people or seizing innocent Fediverse servers?
  • How do we ensure instance admins are broadly trained to handle this?
  • How do we deal with international law?

  
  

• How do we prevent scope creep?
  
  • While there is public interest in minimizing the spread of CSAM, which is basically legally radioactive, I’m not interested in ever building a “snitch on women seeking reproductive health care in a state where abortion is illegal” capability.

  
  

• Does Section 230 matter for any of these questions?

We may not know the answers to these questions until the courts make specific decisions that establish relevant case law, or our governments pass legislation that clarifies everyone’s rights and responsibilities for such cases.

Until then, the best answer may simply to do nothing.

That is to say, let admins delete messages for the whole group, let users delete messages they don’t want on their own hardware, and let admins receive abuse reports from their users… but don’t do anything further.

Okay, we should definitely require an explicit separate action to download and decrypt the media attached to a reported message, rather than have it be automatic, but that’s it.

Harubaki

What’s Next?

For the immediate future, I plan on continuing to develop the Federated Public Key Directory component until I’m happy with its design. Then, I will begin developing the reference implementations for both client and server software.

Once that’s in a good state, I will move onto finishing the E2EE specification. Then, I will begin building the client software and relevant server patches for Mastodon, and spinning up a testing instance for folks to play with.

Timeline-wise, I would expect most of this to happen in 2025.

I wish I could promise something sooner, but I’m not fond of moving fast and breaking things, and I do have a full time job unrelated to this project.

Hopefully, by the next time I pen an update for this project, we’ll be closer to launching. (And maybe I’ll have answers to some of the legal concerns surrounding abuse reporting, if we’re lucky.)

CMYKat

https://soatok.blog/2024/09/13/e2ee-for-the-fediverse-update-were-going-post-quantum/

#E2EE #endToEndEncryption #fediverse #FIPS #Mastodon #postQuantumCryptography

Dhole Moments

2021-04-19 10:21:00

Normally when you see an article that talks about cryptocurrency come across your timeline, you can safely sort it squarely into two camps: For and Against. If you’re like me, you might even make a game out of trying to classify it into one bucket or the other from the first paragraph–sort of like how people treat biological sex–and then reading to see if you were right or not. Most of the time, you don’t even have to read past the headline to know where the author stands.

Unfortunately, the topic of cryptocurrency is complicated in ways only nerds could envision. And I’m not even talking about the cryptography involved when I say that.

(Art by Khia.)

Cryptocurrency is one of those cans I keep kicking down the road, lest all of its worms escape. I’m neither an enthusiast who wants to pump dogecoin to the moon, nor a detractor who thinks that the idea of digital cash is inherently stupid.

https://twitter.com/FiloSottile/status/1380576100888281094

The “crypto means cryptography” trope exists because, after Bitcoin’s first price hike, a shitload of speculative investors flooded cryptography forums and drowned out the usual participants’ discussions. I’ve previously said that some gatekeeping is necessary for the maintenance group identity, and that the excess of this minimum amount is what creates toxicity. Unfortunately, this trope has far exceeded the LD50 for healthy discourse.

Some of my friends make their living working on cryptocurrency projects–as researchers, mathematicians, programmers, security engineers, and so on. A lot of the interesting cryptography breakthroughs we’ll see in the next 10-15 years will be, at least in part, the result of cryptographers working in the cryptocurrency space. It’s difficult to talk about zero-knowledge proofs without acknowledging some of the kick-ass research the Electric Coin Company has done in order to launch their privacy-preserving cryptocurrency, and that’s only one example.

Here’s cryptographer Jean-Phillipe Aumasson, whose employer is launching a regulated cryptocurrency marketplace:

https://twitter.com/veorq/status/1384045994413678598

If you’re not familiar with JP’s work, he wrote several cryptography books (including Serious Cryptography), contributed to several hash functions (SipHash, BLAKE2, and BLAKE3), and initiated the Password Hashing Competition that resulted in Argon2.

However, there’s also a lot of bullshit in the cryptocurrency space.

• Years of securities fraud enabled by “Initial Coin Offerings” (ICOs) on the Ethereum blockchain. Most famously: Bitcoiin (yes, with two I’s) whose spokesman was bad movie star, Steven Seagal.
• The plague of hacked Twitter accounts pretending to be Elon Musk, perpetuating a “give me some $ and I’ll give you more back” scam that’s sadly effective.
• The whole cryptoart / NFT debacle.
• Litanies of startups trying to “use blockchain to solve X problem” without ever asking if the problem warrants a blockchain in the first place.
• Every microgram of drama related to John McAfee.

And those are just the items I can list off, off the top of my head. The awfulness surrounding cryptocurrency is like a fractal: The deeper you look at it, the more shit you see.

Cryptocurrency Subculture: A Tale of Too Shitty

The world’s most successful cryptocurrency to date, Bitcoin, was created in 2008 by an anonymous cryptographer who liked to be known as Satoshi Nakamoto and distributed on metzdowd.com, a mailing list created by a group of cryptoanarchists that called themselves “cypherpunks”.

At the risk of being overly reductive, cryptoanarchists are people who believe strongly in a right to privacy and therefore the right to use cryptography to protect communications from others–be it governments, corporations, or jealous ex-lovers. The cypherpunks were a group of cryptoanarchists that also wrote code. It’s a wordplay on “cyberpunk”.

It’s difficult to speculate about the intentions or politics of Satoshi Nakamoto, considering they said very little of substance about their private beliefs, and no longer answer emails from random strangers. However, given their presence on metzdowd, it’s reasonable to propose they were at least sympathetic to the cypherpunks’ cause.

Most outspoken cryptocurrency enthusiasts today are not like Satoshi Nakamoto. They don’t understand or frankly give a shit about complex, nuanced points about privacy and the government machinations underpinning public safety–let alone how that intersects with the racist history of the institutions charged with keeping the public safe. They’re largely anarcho-capitalists who want to make as much money as they can and, in turn, pay as little as possible in taxes.

How do you make money in cryptocurrency?
By obtaining some amount of a coin, then convincing other people to buy it to drive up the demand, and therefore the price, and then sell at a later date. Then you can sell your coins at a higher price than you paid (either directly, or through energy costs from “mining”) and pocket your profits.

Don’t let the name fool you: anarcho-capitalists (a.k.a. ancaps) aren’t anarchists (and furthermore, cryptocurrency-manic ancaps aren’t cryptoanarchists). Here’s a helpful video to disambiguate the terms involved:

https://www.youtube.com/watch?v=OOTlxsn8tWc

If I said that large swaths of the cryptocurrency community was generally shitty, I would not be the first to make this observation. The earliest Bitcoin events were caricatures of the kind of toxic sexist excess that dominates chauvinistic power fantasies. (“When lambo?”)

It’s not just the bad politics or the stark contrast between cryptocurrency in practice and cryptocurrency as envisioned by the earliest architects on the metzdowd cryptography mailing list.

Last year I wrote about a dumb attack against the second hash function used by the cryptocurrency, IOTA. After I wrote this story, my Twitter mentions and DMs were flooded with astroturfing attempts by IOTA enthusiasts. Nearly a year later, most of those have been deleted–presumably because of an account suspension.

https://twitter.com/HapaRekk/status/1283485380004597760

Before IOTA, Monero enthusiasts used to engage in bad faith with anyone that dared criticize their favorite cryptocurrency project on Reddit or Hacker News.

To be clear: I don’t think that cryptocurrency projects or their developers are ever necessarily responsible for the behavior of their users. Sometimes you find toxic assholes like Sergey Ivancheglo (the IOTA developer that threatened security researchers) at the helm, and then immediately jettison it until they leave (to great fanfare of the non-toxic part of their community).

I don’t want to overstate my case here. A lot of blockchainiacs are just downright awful people. The absolute worst. But I’ve found over the years that, the less a person talks about cryptocurrency as a financial endeavor (e.g. speculative trading), the less likely they are to be shitty. It’s not a law of the universe, but it’s a useful measuring stick.

But with all that in mind, an obvious question emerges.

If there’s so much awful shit surrounding cryptocurrency, why would furries (a subculture that constantly receives endless helpings of flak from society at large) ever venture near cryptocurrency?

The Politics Inherent to Furry Identity

Art by Swizz.

A lot of Americans like to think of themselves as “Free Speech” proponents. Some of them get all sweaty over whether or not they should be allowed to broadcast, and profit from, bigoted or hateful content laden with slurs.

And yet, the most censored people in American society are, without a doubt, sex workers. And you rarely hear any so-called “Free Speech” proponents give an iota of shit about the plight of sex workers. They can’t even freely engage in commerce here.

Sex work is explicitly banned by most financial service providers, such as PayPal. It’s exceedingly difficult for sex workers to make ends meet without constantly having to worry about their accounts being frozen and funds inaccessible.

There are a lot of reasons why the plight of sex workers is so bad in America. At the top of the list is the intersection of conservative politics and evangelical Christianity, which overall condemns healthy and consensual expressions of human sexuality. (Ever noticed how the only people who think they have a “sex addiction” are religious or right-wing? Not a coincidence.)

Do you know who else is a target of evangelicals and conservatives?

Furries, as you might know, are widely considered an LGBTQIA+ subculture (although not all of us are LGBTQIA+; only about 80%). But we’re more than just an LGBTQIA+ subculture. We’re also a vibrant community filled with skilled artists. Some of this art is pornographic in nature. It turns out, when queer people aren’t forced into the closet, they tend to embrace shameless authenticity and celebrate their romantic and sexual attractions with pride.

https://twitter.com/Pinboard/status/992819169593716737

A few years ago, the Death Eaters in Congress passed two bills (FOSTA and SESTA) that were advertised as an attempt to crack down on “sex trafficking”.

In practice, these laws killed Pounced.org–the only furry “dating” site at the time that wasn’t a sketchy cash grab (FurryMate, FurFling, etc.). Pounced.org died because the cost to avoid being criminally prosecuted under these laws was so exorbitant that they couldn’t sustain the website anymore, and it probably wasn’t the only small dating site to be killed by poor legislation. Only the big players could really have front-loaded these costs.

Which leads to the meat of this issue…

Why Furries Might Be Interested in Cryptocurrency

Cryptocurrency can be very attractive to members of the furry fandom because of the bullshit baked into the societies and cultures we exist in.

Cryptocurrency promises to be permissionless and decentralized; to bank the unbanked. If you make your living filling up someone else’s spank bank, the idea of creepy rich white men not being able to exercise targeted censorship against you or your family is, frankly, irresistible.

“Can’t use PayPal for your trade? Just setup a cryptocurrency wallet and give a different address to each of your clients, and instructions on how to access some vaguely reputable cryptocurrency exchange.”

Granted, most furries aren’t sex workers or porn artists, but some of our friends are, and we want to see them protected. But there’s another threat that cryptocurrency promises to alleviate: Chargeback fraud.

The prevalence of chargeback fraud is why I always tip artists. It helps to offset some of the harm caused by shitty behavior.
(Art by Khia)

This is the usual story (although exceptions do exist) I heard from my artist friends:

Someone under 18 decides they want to commission an artist they cannot personally afford, so they steal their parent’s credit card and use it to pay for a commission. Later–often after the work has been completed and delivered to the client–their parent notices the unauthorized charge on their credit card, and issues a chargeback.

Not only does this steal from the artist, but it incurs a $35 fee and increases the risk of their account being permanently suspended by their payment provider–thereby preventing them from accessing the funds paid to them by legitimate customers.

“Thanks for the free art! Now you’re at least $35 poorer and maybe lost your only lifeline out of perpetual poverty.”

— Assholes

And thus, the Siren Song repeats once again!

Cryptocurrency doesn’t prevent chargeback fraud, but it does shift the risk from independent artists that have no capital or political power and onto billion dollar financial institutions like Coinbase.

Once the cryptocurrency has been transferred from the Coinbase wallet to the furry artist, it cannot be unspent. Bad faith behavior might still happen, but the artist doesn’t risk their livelihood because of it.

And that’s why, when furry auction site The Dealer’s Den announced a plan to rebuild with “Blockchain Technology”, I didn’t even bat an eye. It seems like an obvious solution to a pervasive unsolved problem to me.

Sure, it’d be great if we could solve this problem with sensible civil policy. But when is that going to finally happen? After all, we’re talking about the same governments that bungled COVID-19 last year, and the AIDS crisis last century, and so on…

https://www.youtube.com/watch?v=aJtvKSUPICA

However, and this bears emphasizing, the CryptoArt / NFT trend is not a valid reason to get involved in cryptocurency! As I said on Twitter:

https://twitter.com/SoatokDhole/status/1370045499122843654

https://twitter.com/SoatokDhole/status/1370046285798064128

https://twitter.com/SoatokDhole/status/1370047071949033472

https://twitter.com/SoatokDhole/status/1370047509314297862

So, super long preamble aside, what I thought I’d do today is talk a bit about cryptocurrency and how to engage with the topic responsibly, especially if you’re trying to mitigate the damage of the systems we inherited.

Cryptocurrency For Furries

I’m going to be very light on technical jargon, in the interests of accessibility, but at the risk of being imprecise.

No two cryptocurrencies are created equal. If you’re hoping to use one to mitigate systemic harms to our community, I implore you to learn the technical details in depth.

Decentralized Consensus

Cryptocurrencies can be classified by something called their consensus mechanism, which is how they can maintain a consistent ledger without being centralized. It doesn’t really matter, for the purpose of this article, how any of them work. I’m happy to dive into that in a future blog post, should anyone want it.

What you need to know is that Proof-of-Work (PoW) consensus algorithms are designed to maximize energy waste across the entire cryptocurrency network. That’s how it maintains its security against different kinds of esoteric-sounding attacks.

When you “mine” a Proof-of-Work cryptocurrency, what you’re doing is solving a computationally hard puzzle (e.g. find a number that, when combined with the previous block’s hash and your address and hashed, produces a specific number of leading 0 bits determined by an algorithm to ensure this happens at a set average frequency of time), which results in the entire network agreeing that your address gets the “block reward” (a fixed amount of whatever currency) plus transaction fees.

Cryptocurrency discussions frequently invite conversations about the environmental impact of mining. Proof-of-Work is the cause for this excess energy use which certainly contributes to global climate change.

So, if you’re going to get involved with cryptocurrency without contributing to global climate disaster, you’re going to want to avoid Proof-of-Work cryptocurrencies. There are several other options to choose from.

Proof-of-Stake is popular among my cryptocurrency nerd friends, although it receives a fair bit of criticism from experts (especially the “nothing at stake” problem). Ask your cryptographer. It’s probably not me.

On-Chain Privacy

The vaunted “blockchain” is a public, transparent record of all transactions.

When you use a cryptocurrency like Bitcoin, it’s sort of like tweeting your financial activities for the world to see.

“But nobody knows who owns this address,” Bitcoin maximalists might argue. To which I point out: Nobody is supposed to know your sockpuppet Twitter accounts either, but when you use them to harass someone right after they block your main account, we know it’s you.

The people whom this applies to know who they are, and should stop.
(Art by Khia)

Some cryptocurrencies, like Zcash, try to provide something like TLS for your transactions. When you use shielded Zcash addresses, the transaction amounts and recipients are encrypted, and this ciphertext is accompanied by a zero-knowledge proof to ensure the total amount in the shielded and unshielded pools remains consistent.

I highly implore you to choose a cryptocurrency that has on-chain privacy, especially if your target audience includes queer people and/or sex workers.

Mainstream Appeal

Finding a privacy-preserving cryptocurrency that doesn’t equate to Global Warming Bucks is a tall order, but if you want people to actually use a cryptocurrency, it needs to be accessible.

By accessible, I mean available on all the mainstream cryptocurrency exchange platforms (Coinbase, Binance, Bitfinex, etc.).

This might sound like pointless gatekeeping, but remember: They have the money and lawyers to negotiate with the economic powerhouses of the world, while sex workers and furry artists do not.

Cryptographic Security

Any regular reader of Dhole Moments probably saw this section coming a mile away, but an important consideration for a cryptocurrency to build upon is whether or not it’s actually secure.

This is where things get tricky. Weird or poor choices in cryptographic algorithm don’t seem to matter much.

Bitcoin uses ECDSA over Koblitz curves. IOTA shipped two broken hash functions, threatened researchers, and then tried to claim the first broken hash function was backdoored for “copy protection”. The CryptoNote currencies (n.b. Monero) tried to build on EdDSA but introduced a double spend attack.

I’m certainly not qualified to audit an entire cryptocurrency and say “yes/no” on its security. But any cryptocurrency you consider should at least pass a smoke test from your cryptographer.

Which Cryptocurrency Should I Choose?

If you’re looking for a cryptocurrency that’s secure, accessible, privacy-preserving, and doesn’t waste a fuck ton of energy all the time, the short answer is that there is none. You’re going to have to make a trade-off.

Shocking, I know.
(Art by Khia)

I’m sure there are cryptocurrency projects that use privacy-preserving technologies without a Proof-of-Work algorithm, and their design and implementation might even be secure! But, to date, I’m not aware of any such projects that also have mainstream accessibility on large exchange platforms.

You’ll notice that I didn’t mention price volatility in my list above. There’s two reasons for that:

1. I’m not a financial expert. For all I know, price volatility might be something you want out of your cryptocurrency, especially if you’re LARPing a day trader.
2. It’s hard enough to make this choice without adding more complications to the formula.

If Zcash ever adopted a consensus algorithm that wasn’t Proof-of-Work, it’d be a shoe-in for me to recommend. It checks all the other boxes neatly and is one of the most interesting cryptography projects on the Internet, after all.

In the meantime, maybe some other project will fill this niche and become widely accessible for everyone. There’s a lot of exciting and/or scary things happening with cryptocurrency research.

If you’re stuck with a hard decision, honestly, just do the best you can and be very transparent about the trade-offs you’re making and why you’re making them. Then ask a friend or expert to check your reasoning before you commit to it. “Do nothing” also needs to be publicly considered, no matter how absurd it might seem.

Disclaimers and Other Remarks

I do not work with cryptocurrency in my dayjob. I’d like to say that, consequently, I don’t have a conflict of interest, but all humans have subconscious biases, and a lot of my favorite people in cryptography do work in or with cryptocurrency. I want my friends to be able to continue to do awesome work without feeling ashamed.

https://twitter.com/cryptolexicon/status/1331712883403722752

Thus, I don’t care if you invest in Bitcoin or Dogecoin or whatever. Shoot for the moon while you awoo at the moon. Just be careful; for every winner, there’s at least one loser.

Fact: Dholes are also known as “Whistling Dogs”
(Art by Khia)

I’m a fan of transparency logs–which are often compared to blockchains, but without the currency aspect. If you’re not familiar, read up on Trillian and Chronicle. Notably, Trillian is the backbone of Certificate Transparency, which helps keep the CA infrastructure honest and consequently makes HTTPS safer for everyone.

https://soatok.blog/2021/04/19/a-furrys-guide-to-cryptocurrency/

#Cryptocurrency #furries #furry #furryArtists #FurryFandom #Politics #Society

Dhole Moments

2020-06-08 08:11:00

I probably don’t need to remind anyone reading this while it’s fresh about the current state of affairs in the world, but for the future readers looking back on this time, let me set the stage a bit.

The Situation Today

(By “Today”, I mean early May 2020, when I started writing this series.)

In the past two months, over 26 million Americans have filed for unemployment, and an additional 14 million have been unable to file.

Federal Reserve chairman, Jerome Powell, says we’re in the worst economy ever.

In a desperate bid of economic necromancy, many government officials want to put millions more Americans at risk of COVID-19 before we can develop a vaccine and effective treatment. And we still don’t even know the long-term effects of the virus.

I’m not interested in discussing the politics of this pandemic or who to blame; I’ll leave that to everyone else with an opinion. Instead, I want to acknowledge two facts that most people probably already know:

1. This was mostly avoidable with competent leadership and responsible preparation
2. Most of us have rough times ahead of us

I can’t do anything about the first point (although most people are focused on it), but I want to try to alleviate the second point.

What This Series is About

Whether you lost your job and need an income to survive, or you’re one of the essential workers wanting to avoid being sacrificed by politicians for the sake of economic necromancy, I wrote this guide to help you transition into a technology career with little-to-no tech experience.

This is not a magic bullet! It will require time, focus, and effort.

But if you follow the advice on the subsequent posts in this series, you will at least have another option available to you. The value of choice, especially when you otherwise have none, is difficult to overstate.

I am not selling anything, nor are there ads on these pages.

This entire series is released under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Why Work in Tech?

Technology careers aren’t everyone’s cup of tea, and they might be far from your first choice, but there are a couple of advantages that you should be aware of especially during this pandemic and lockdown:

1. Most technology careers can be performed remotely.
2. Most technology careers pay well.

The first point is especially important for folks living in rural areas hit hard by a lack of local employment opportunities.

A lot of the information and suggestions contained in this series may be applicable to other domains. However, my entire career has been in tech, so I cannot in good conscience speak to the requirements to gain employment in those industries.

Why Should We Trust You?

You shouldn’t. I encourage you to take everything I say with a grain of salt and fact-check any claims I make. Seriously.

My Background

I’m currently employed as a security engineer for a cryptography team of a larger company, although I don’t even have a Bachelor’s degree. I’ve worked with teams of all sizes on countless technology stacks.

I have been programming, in one form or another, since I was in middle school (about 18 years ago), although I didn’t start my professional career until 2011. I’ve been on both sides of bug bounty programs, including as my fursona. A nontrivial percentage of the websites on the Internet run security code I wrote under my professional name.

Art by Khia

My Motivation

Over the past few years, I’ve helped a handful of friends (some of them furries) transition into technology careers. I am writing this series, and distributing it for free because I want to scale up the effort I used to put into mentoring.

I’m writing this series under my furry persona, and drenching the articles with queer and furry art, to make it less palatable to bigots.

Art by Kerijiano

Series Contents

1. Building Your Support Network and/or Team
2. Mapping the Technology Landscape
3. Learning the Fundamental Skills
4. Choosing Your Path
5. Starting and Growing an Open Source Project
6. Building Your C.V.
7. Getting Your First Tech Job
8. Starting a Technology Company
9. Career Growth and Paying It Forward

The first three entries are the most important.

The header art for this entire series was created by ScruffKerfluff.

https://soatok.blog/2020/06/08/furward-momentum-introduction/

#Technology

Dhole Moments

2020-05-09 22:31:37

Update (2021-01-09): There’s a newer blog post that covers different CloudFlare deanonymization techniques (with a real world case study).

---

Furry Twitter is currently abuzz about a new site selling knock-off fursuits and illegally using photos from the owners of the actual fursuits without permission.

The website in question.

Understandably, the photographers and fursuiters whose work was ripped off by this website are upset and would like to exercise their legal recourse (i.e. DMCA takedown emails) of the scam site, but there’s a wrinkle:

Their contact info isn’t in DNS and their website is hosted behind CloudFlare.

CloudFlare.
Private DNS registration.

You might think this is a show-stopper, but I’m going to show you how to get their server’s real IP address in one easy step.

Ordering the Server’s IP Address by Mail

Most knock-off site operators will choose open source eCommerce platforms like Magento, WooCommerce, and OpenCart, which usually have a mechanism for customers to register for an account and login.

Usually this mechanism sends you an email when you authenticate.

(If it doesn’t, logout and use the “reset password” feature, which will almost certainly send you an email.)

Once you have an email from the scam site, you’re going to need to view the email headers.

With Gmail, can click the three dots on the right of an email then click “Show original”.

Account registration email.
Full email headers after clicking “Show original”.

And there you have it. The IP address of the server behind CloudFlare delivered piping hot to your inbox in 30 minutes or less, or your money back.

That’s a fairer deal than any of these knock-off fursuit sites will give you.

Black magic and piss-poor opsec.

What Can We Do With The Server IP?

You can identify who hosts their website. (In this case, it’s a company called Net Minders.)

With this knowledge in mind, you can send an email to their web hosting provider, citing the Digital Millennium Copyright Act.

One or two emails might get ignored, but discarding hundreds of distinct complaint emails from different people is bad for business. This (along with similar abuse complaints to the domain registrar, which isn’t obscured by DNS Privacy) should be enough to shut down these illicit websites.
The more you know!

Epilogue

https://twitter.com/Mochiroo/status/1259289385876373504

The technique is simple, effective, and portable. Use it whenever someone tries to prop up another website to peddle knock-off goods and tries to hide behind CloudFlare.

https://soatok.blog/2020/05/09/how-to-de-anonymize-scam-knock-off-sites-hiding-behind-cloudflare/

#cloudflare #deanonymize #DNS #fursuitScamSites #informationSecurity #OnlinePrivacy #opsec

Dhole Moments

2021-07-02 06:32:20

Last week, Floridians were startled by an emergency alert sent to all of our cell phones. Typically when this sort of alert happens, it’s an Amber Alert, which means a child was abducted. In Florida, we sometimes also receive Silver Alerts, which indicates that an Alzheimer’s or dementia patient has gone missing. (Florida has a lot of old and retired people.)

To my surprise, it was neither of those things. Instead, it was a Blue Alert–a type of alert I had never seen before. Apparently nobody else had seen it either, because a local news site published a story explaining what Blue Alerts even are for their confused readers.

What’s a Blue Alert?

A Blue Alert is an involuntary message, communicated over the emergency alert infrastructure, to perform the equivalent of a Twitter call-out thread on a suspected cop-killer or cop-abductor.

Blue Alerts are opt-out, not opt-in, and you cannot turn them off without also disabling other types of emergency alerts. Even on newer phones which offer greater granularity with the types of emergency alerts to receive, there is no specific flag to disable Blue Alerts and leave all the other types turned on.

Blue Alerts Are Security Theater

Blue Alerts do not provide any meaningful benefit towards public safety, and actually make us less safe.

If someone just killed a cop, do you really expect random untrained citizens to get involved? We already know how that worked out for the armed and trained professionals.

https://twitter.com/cel_decicco/status/1408127188671647748

If law enforcement wants an uncritical platform to broadcast their lies and omissions with no questions (or only softball questions that presuppose the frame that they’re telling the truth), they already have every major media outlet in their locale. They don’t need the Blue Alerts to get the word out, or to advertise a cash reward for information leading to an arrest. They already have channels for that.

Why are Blue Alerts a thing? The best reason I’ve been able to discern is: Because the surviving families of deceased law enforcement officers want to feel like their loss is taken seriously. The need to “do something”–even when that something is meaningless, or even harmful, but still looks like a solution–is the essence of Security Theater.

But Blue Alerts aren’t as harmless as a mere expression of sheer self-entitlement over the rest of us unimportant proles.

Blue Alerts actually serve to make our society less safe by increasing Alarm Fatigue, which negatively impacts public safety by making people less focused when an alert comes in.

Alternatively, some people will actively disable Blue Alerts to prevent alarm fatigue. But, as stated above, there’s no way to disable them in isolation without also disabling other emergency alerts, which puts them at risk of being uninformed of an actual severe or extreme emergency.

Making the public less safe goes against the very predicate for why police forces exist in most states.

Just say NO to Security Theater!
(Art by Khia.)

Blue Alerts Are Copaganda (in Practice)

This one needs a bit of explaining. I’m going to focus on Florida, because it’s familiar to me.

Blue Alerts were created in Florida in 2011 via an executive order by then-governor Rick Scott. According to Spectrum News 9, only three alerts have been issued since the system was created.

(Anecdote: I’ve had my own mobile phone since 2008 and never once received one until last week.)

The Florida Department of Law Enforcement identifies four criteria for a Blue Alert to be issued:

1. A law enforcement officer must have been: seriously injured; killed by a subject(s); or become missing while in the line of duty under circumstances causing concern for the law enforcement officer’s safety.
2. The investigating agency must determine that the offender(s) poses a serious risk to the public or to other law enforcement officers, and the alert may help avert further harm or assist in the apprehension of the suspect.
3. A detailed description of the offender’s vehicle or other means of escape (vehicle tag or partial tag) must be available for broadcast to the public.
4. The local law enforcement agency of jurisdiction must recommend issuing the Blue Alert.

That fourth requirement gives law enforcement a lot of discretion in deciding whether or not to issue a Blue Alert.

That power to arbitrarily decide whether or not to send one might explain why, despite having 2 cops killed in 2020 and 4 cops killed in 2018 due to shooting incidents (both in Florida alone, and I do not have access to data earlier than 2018), a Blue Alert wasn’t emitted for any of those incidents.

Gee, I wonder if something else could have happened last week to prompt law enforcement to exercise a rarely-used tool in their toolbelt?

What Happened Before June 2021’s Blue Alert

I’m not particularly clued into the specific events of the shooting that issued the Blue Alert, but there was a particularly embarrassing incident for law enforcement in Florida the day before that was starting to gain a lot of attention.

Florida Highway Patrol tased a teenage boy in his girlfriend’s yard. And it was starting to get national media coverage.

Content Warning: Do not watch this video if violence–especially police violence–might cause you severe discomfort or trigger an involuntary psychological response to past trauma:

https://www.youtube.com/watch?v=n4wSkqQlA9o

I do not have, nor will I claim to have, any specific evidence that proves that the cops used the shooting in Volusia County, Florida as an excuse to trigger the surprising Blue Alert to confuse and distract the populace.

However, all cops are bastards, so I certainly suspect them of doing such a thing to cover for their buddies.

And since their mere suspicion is generally sufficient justification for cops to violate the Fourth Amendment with wild abandon, it’s only fair that my suspicion be sufficient to launch an investigation into their motives.

Just kidding!

We know the system is stilted in cops’ favor, which is why there’s a Blue Alert when a cop gets killed, but not a Stasi Alert when cops decide to murder an American citizen.

(Art by Khia.)

In Conclusion

Blue Alerts are not actionable for their recipients, and make the public less safe. Additionally, they provide the police yet another propaganda tool that I suspect they already used once to distract the public from an embarrassing news story.

Here’s what needs to happen:

1. Mobile Operating System developers need to create a dedicated toggle to disable Blue Alerts without disabling other emergency alerts.
2. These toggles need to be easier to find and configure.

These aren’t political solutions, merely technological ones, but as a security engineer, that’s all I can offer.

https://soatok.blog/2021/07/02/blue-alerts-security-theater-and-copaganda/

#ACAB #BlueAlerts #Florida #police #policeState #Politics #publicSafety #SecurityTheater #Society #Technology

Dhole Moments

2020-10-07 02:46:12

This is the first entry in a (potentially infinite) series of dead end roads in the field of cryptanalysis.

Cryptography engineering is one of many specialties within the wider field of security engineering. Security engineering is a discipline that chiefly concerns itself with studying how systems fail in order to build better systems–ones that are resilient to malicious acts or even natural disasters. It sounds much simpler than it is.

If you want to develop and securely implement a cryptography feature in the application you’re developing, it isn’t enough to learn how to implement textbook descriptions of cryptography primitives during your C.S. undergrad studies (or equivalent). An active interest in studying how cryptosystems fail is the prerequisite for being a cryptography engineer.

Thus, cryptography engineering and cryptanalysis research go hand-in-hand.

Pictured: How I feel when someone tells me about a novel cryptanalysis technique relevant to the algorithm or protocol I’m implementing. (Art by Khia.)

If you are interested in exploring the field of cryptanalysis–be it to contribute on the attack side of cryptography or to learn better defense mechanisms–you will undoubtedly encounter roads that seem enticing and not well-tread, and it might not be immediately obvious why the road is a dead end. Furthermore, beyond a few comparison tables on Wikipedia or obscure Stack Exchange questions, the cryptology literature is often sparse on details about why these avenues lead nowhere.

So let’s explore where some of these dead-end roads lead, and why they stop where they do.

(Art by Kyume.)

Length Extension Attacks

It’s difficult to provide a better summary of length extension attacks than what Skull Security wrote in 2012. However, that only addresses “What are they?”, “How do you use them?”, and “Which algorithms and constructions are vulnerable?”, but leaves out a more interesting question: “Why were they even possible to begin with?”

An Extensive Tale

Tale, not tail! (Art by Swizz.)

To really understand length extension attacks, you have to understand how cryptographic hash functions used to be designed. This might sound intimidating, but we don’t need to delve too deep into the internals.

A cryptographic hash function is a keyless pseudorandom transformation from a variable length input to a fixed-length output. Hash functions are typically used as building blocks for larger constructions (both reasonable ones like HMAC-SHA-256, and unreasonable ones like my hash-crypt project).

However, hash functions like SHA-256 are designed to operate on sequential blocks of input. This is because sometimes you need to stream data into a hash function rather than load it all into memory at once. (This is why you can sha256sum a file larger than your available RAM without crashing your computer or causing performance headaches.)

A streaming hash function API might look like this:
class MyCoolHash(BaseHashClass): @staticmethod def init(): """ Initialize the hash state. """ def update(data): """ Update the hash state with additional data. """ def digest(): """ Finalize the hash function. """ def compress(): """ (Private method.) """
To use it, you’d call hash = MyCoolHash.init() and then chain together hash.update() calls with data as you load it from disk or the network, until you’ve run out of data. Then you’d call digest() and obtain the hash of the entire message.

There are two things to take away right now:

1. You can call update() multiple times, and that’s valid.
2. Your data might not be an even multiple of the internal block size of the hash function. (More often than not, it won’t be!)

So what happens when you call digest() and the amount of data you’ve passed to update() is not an even multiple of the hash size?

For most hash functions, the answer is simple: Append some ISO/IEC 7816-4 padding until you get a full block, run that through a final iteration of the internal compression function–the same one that gets called on update()–and then output the current internal state.

Let’s take a slightly deeper look at what a typical runtime would look like for the MyCoolHash class I sketched above:

1. hash = MyCoolHash.init()
   
   • Initialize some variables to some constants (initialization vectors).

   
   

2. hash.update(blockOfData)
   
   • Start with any buffered data (currently none), count up to 32 bytes. If you’ve reached this amount, invoke compress() on that data and clear the buffer. Otherwise, just append blockOfData to the currently buffered data.
   • For every 32 byte of data not yet touched by compress(), invoke compress() on this block (updating the internal state).
   • If you have any leftover bytes, append to the internal buffer for the next invocation to process.

   
   

3. hash.update(moreData)
   
   • Same as before, except there might be some buffered data from step 2.

   
   

4. output = hash.digest()
   
   • If you have any data left in the buffer, append a 0x80 byte followed by a bunch of 0x00 bytes of padding until you reach the block size. If you don’t, you have an entire block of padding (0x80 followed by 0x00s).
   • Call compress() one last time.
   • Serialize the internal hash state as a byte array or hexadecimal-encoded string (depending on usage). Return that to the caller.

   
   

This is fairly general description that will hold for most older hash functions. Some details might be slightly wrong (subtly different padding scheme, whether or not to include a block of empty padding on digest() invocations, etc.).

The details aren’t super important. Just the rhythm of the design.

• init()
• update()
  
  • load buffer, compress()
  • compress()
  • compress()
  • …
  • buffer remainder

  
  

• update()
  
  • load buffer, compress()
  • compress()
  • compress()
  • …
  • buffer remainder

  
  

• …
• digest()
  
  • load buffer, pad, compress()
  • serialize internal state
  • return

  
  

And thus, without having to know any of the details about what compress() even looks like, the reason why length extension attacks were ever possible should leap out at you!

Art by Khia.

If it doesn’t, look closely at the difference between update() and digest().

There are only two differences:

1. update() doesn’t pad before calling compress()
2. digest() returns the internal state that compress() always mutates

The reason length-extension attacks are possible is that, for some hash functions, the output of digest() is its full internal state.

This means that you can run take an existing hash function and pretend it’s the internal state after an update() call instead of a digest() call by appending the padding and then, after calling compress(), appending additional data of your choice.

The (F)Utility of Length Extension

Length-Extension Attacks are mostly used for attacking naive message authentication systems where someone attempts to authenticate a message (M) with a secret key (k), but they construct it like so:
auth_code = vulnerable_hash(k.append(M))
If this sounds like a very narrow use-case, that’s because it is. However, it still broke Flickr’s API once, and it’s a popular challenge for CTF competitions around the world.

Consequently, length-extension attacks are sometimes thought to be vulnerabilities of the construction rather than a vulnerability of the hash function. For a Message Authentication Code construction, these are classified under canonicalization attacks.

After all, even though SHA-256 is vulnerable to length-extension, but you can’t actually exploit it unless someone is using it in a vulnerable fashion.

That being said, it’s often common to say that hash functions like SHA-256 and SHA-512 are prone to length-extension.

Ways to Avoid Length-Extension Attacks

Use HMAC. HMAC was designed to prevent these kinds of attacks.

Alternatively, if you don’t have any cryptographic secrets, you can always do what bitcoin did: Hash your hash again.
return sha256(sha256(message))
Note: Don’t actually do that, it’s dangerous for other reasons. You also don’t want to take this to an extreme. If you iterate your hash too many times, you’ll reinvent PBKDF1 and its insecurity. Two is plenty.

Or you can do something really trivial (which ultimately became another standard option in the SHA-2 family of hash functions):

Always start with a 512-bit hash and then truncate your output so the attacker never recovers the entire internal state of your hash in order to extend it.

That’s why you’ll sometimes see SHA-512/224 and SHA-512/256 in a list of recommendations. This isn’t saying “use one or the other”, that’s the (rather confusing) notation for a standardized SHA-512 truncation.

Note: This is actually what SHA-384 has done all along, and that’s one of the reasons why you see SHA-384 used more than SHA-512.

If you want to be extra fancy, you can also just use a different hash function that isn’t vulnerable to length extension, such as SHA-3 or BLAKE2.

Questions and Answers

Art by Khia.

Why isn’t BLAKE2 vulnerable to length extension attacks?

Quite simply: It sets a flag in the internal hash state before compressing the final buffer.

If you try to deserialize this state then invoke update(), you’ll get a different result than BLAKE2’s compress() produced during digest().

For a secure hash function, a single bit of difference in the internal state should result in a wildly different output. (This is called the avalanche effect.)

Why isn’t SHA-3 vulnerable to length extension attacks?

SHA-3 is a sponge construction whose internal state is much larger than the hash function output. This prevents an attacker from recovering the hash function’s internal state from a message digest (similar to the truncated hash function discussed above).

Why don’t length-extension attacks break digital signature algorithms?

Digital signature algorithms–such as RSASSA, ECDSA, and EdDSA–take a cryptographic hash of a message and then perform some asymmetric cryptographic transformation of the hash with the secret key to produce a signature that can be verified with a public key. (The exact details are particular to the signature algorithm in question.)

Length-extension attacks only allow you to take a valid H(k || m) and produce a valid H(k || m || padding || extra) hash that will validate, even if you don’t know k. They don’t magically create collisions out of thin air.

Even if you use a weak hash function like SHA-1, knowing M and H(M) is not sufficient to calculate a valid signature. (You need to be able to know these values in order to verify the signature anyway.)

The security of digital signature algorithms depends entirely on the secrecy of the signing key and the security of the asymmetric cryptographic transformation used to generate a signature. (And its resilience to side-channel attacks.)

However, a more interesting class of attack is possible for systems that expect digital signatures to have similar properties as cryptographic hash functions. This would qualify as a protocol vulnerability, not a length-extension vulnerability.

TL;DR

Art by Khia.

Length-extension attacks exploit a neat property of a few cryptographic hash functions–most of which you shouldn’t be using in 2020 anyway (SHA-2 is still fine)–but can only be exploited by a narrow set of circumstances.

If you find yourself trying to use length-extension to break anything else, you’ve probably run into a cryptographic dead end and need to backtrack onto more interesting avenues of exploitation–of which there are assuredly many (unless your cryptography is boring).

---

Next: Timing Side-Channels

https://soatok.blog/2020/10/06/dead-ends-in-cryptanalysis-1-length-extension-attacks/

#cryptanalysis #crypto #cryptographicHashFunction #cryptography #lengthExtensionAttacks

Dhole Moments

2020-05-13 10:00:22

If you’re reading this wondering if you should stop using AES-GCM in some standard protocol (TLS 1.3), the short answer is “No, you’re fine”.

I specialize in secure implementations of cryptography, and my years of experience in this field have led me to dislike AES-GCM.

This post is about why I dislike AES-GCM’s design, not “why AES-GCM is insecure and should be avoided”. AES-GCM is still miles above what most developers reach for when they want to encrypt (e.g. ECB mode or CBC mode). If you want a detailed comparison, read this.

To be clear: This is solely my opinion and not representative of any company or academic institution.

What is AES-GCM?

AES-GCM is an authenticated encryption mode that uses the AES block cipher in counter mode with a polynomial MAC based on Galois field multiplication.

In order to explain why AES-GCM sucks, I have to first explain what I dislike about the AES block cipher. Then, I can describe why I’m filled with sadness every time I see the AES-GCM construction used.

What is AES?

The Advanced Encryption Standard (AES) is a specific subset of a block cipher called Rijndael.

Rijndael’s design is based on a substitution-permutation network, which broke tradition from many block ciphers of its era (including its predecessor, DES) in not using a Feistel network.

AES only includes three flavors of Rijndael: AES-128, AES-192, and AES-256. The difference between these flavors is the size of the key and the number of rounds used, but–and this is often overlooked–not the block size.

As a block cipher, AES always operates on 128-bit (16 byte) blocks of plaintext, regardless of the key size.

This is generally considered acceptable because AES is a secure pseudorandom permutation (PRP), which means that every possible plaintext block maps directly to one ciphertext block, and thus birthday collisions are not possible. (A pseudorandom function (PRF), conversely, does have birthday bound problems.)

Why AES Sucks

Art by Khia.

Side-Channels

The biggest reason why AES sucks is that its design uses a lookup table (called an S-Box) indexed by secret data, which is inherently vulnerable to cache-timing attacks (PDF).

There are workarounds for this AES vulnerability, but they either require hardware acceleration (AES-NI) or a technique called bitslicing.

The short of it is: With AES, you’re either using hardware acceleration, or you have to choose between performance and security. You cannot get fast, constant-time AES without hardware support.

Block Size

AES-128 is considered by experts to have a security level of 128 bits.

Similarly, AES-192 gets certified at 192-bit security, and AES-256 gets 256-bit security.

However, the AES block size is only 128 bits!

That might not sound like a big deal, but it severely limits the constructions you can create out of AES.

Consider the case of AES-CBC, where the output of each block of encryption is combined with the next block of plaintext (using XOR). This is typically used with a random 128-bit block (called the initialization vector, or IV) for the first block.

This means you expect a collision after encrypting (at 50% probability) blocks.

When you start getting collisions, you can break CBC mode, as this video demonstrates:

https://www.youtube.com/watch?v=v0IsYNDMV7A

This is significantly smaller than the you expect from AES.

Post-Quantum Security?

With respect to the number of attempts needed to find the correct key, cryptographers estimate that AES-128 will have a post-quantum security level of 64 bits, AES-192 will have a post-quantum security level of 96 bits, and AES-256 will have a post-quantum security level of 128 bits.

This is because Grover’s quantum search algorithm can search unsorted items in time, which can be used to reduce the total number of possible secrets from to . This effectively cuts the security level, expressed in bits, in half.

Note that this heuristic estimate is based on the number of guesses (a time factor), and doesn’t take circuit size into consideration. Grover’s algorithm also doesn’t parallelize well. The real-world security of AES may still be above 100 bits if you consider these nuances.

But remember, even AES-256 operates on 128-bit blocks.

Consequently, for AES-256, there should be approximately (plaintext, key) pairs that produce any given ciphertext block.

Furthermore, there will be many keys that, for a constant plaintext block, will produce the same ciphertext block despite being a different key entirely. (n.b. This doesn’t mean for all plaintext/ciphertext block pairings, just some arbitrary pairing.)

Concrete example: Encrypting a plaintext block consisting of sixteen NUL bytes will yield a specific 128-bit ciphertext exactly once for each given AES-128 key. However, there are times as many AES-256 keys as there are possible plaintext/ciphertexts. Keep this in mind for AES-GCM.

This means it’s conceivable to accidentally construct a protocol that, despite using AES-256 safely, has a post-quantum security level on par with AES-128, which is only 64 bits.

This would not be nearly as much of a problem if AES’s block size was 256 bits.

Real-World Example: Signal

The Signal messaging app is the state-of-the-art for private communications. If you were previously using PGP and email, you should use Signal instead.

Signal aims to provide private communications (text messaging, voice calls) between two mobile devices, piggybacking on your pre-existing contacts list.

Part of their operational requirements is that they must be user-friendly and secure on a wide range of Android devices, stretching all the way back to Android 4.4.

The Signal Protocol uses AES-CBC + HMAC-SHA256 for message encryption. Each message is encrypted with a different AES key (due to the Double Ratchet), which limits the practical blast radius of a cache-timing attack and makes practical exploitation difficult (since you can’t effectively replay decryption in order to leak bits about the key).

Thus, Signal’s message encryption is still secure even in the presence of vulnerable AES implementations.

Hooray for well-engineered protocols managing to actually protect users.
Art by Swizz.

However, the storage service in the Signal App uses AES-GCM, and this key has to be reused in order for the encrypted storage to operate.

This means, for older phones without dedicated hardware support for AES (i.e. low-priced phones from 2013, which Signal aims to support), the risk of cache-timing attacks is still present.

This is unacceptable!

What this means is, a malicious app that can flush the CPU cache and measure timing with sufficient precision can siphon the AES-GCM key used by Signal to encrypt your storage without ever violating the security boundaries enforced by the Android operating system.

As a result of the security boundaries never being crossed, these kind of side-channel attacks would likely evade forensic analysis, and would therefore be of interest to the malware developers working for nation states.

Of course, if you’re on newer hardware (i.e. Qualcomm Snapdragon 835), you have hardware-accelerated AES available, so it’s probably a moot point.

Why AES-GCM Sucks Even More

AES-GCM is an authenticated encryption mode that also supports additional authenticated data. Cryptographers call these modes AEAD.

AEAD modes are more flexible than simple block ciphers. Generally, your encryption API accepts the following:

1. The plaintext message.
2. The encryption key.
3. A nonce (: A number that must only be used once).
4. Optional additional data which will be authenticated but not encrypted.

The output of an AEAD function is both the ciphertext and an authentication tag, which is necessary (along with the key and nonce, and optional additional data) to decrypt the plaintext.

Cryptographers almost universally recommend using AEAD modes for symmetric-key data encryption.

That being said, AES-GCM is possibly my least favorite AEAD, and I’ve got good reasons to dislike it beyond simply, “It uses AES”.

The deeper you look into AES-GCM’s design, the harder you will feel this sticker.

GHASH Brittleness

The way AES-GCM is initialized is stupid: You encrypt an all-zero block with your AES key (in ECB mode) and store it in a variable called . This value is used for authenticating all messages authenticated under that AES key, rather than for a given (key, nonce) pair.
Diagram describing Galois/Counter Mode, taken from Wikipedia.
This is often sold as an advantage: Reusing allows for better performance. However, it makes GCM brittle: Reusing a nonce allows an attacker to recover H and then forge messages forever. This is called the “forbidden attack”, and led to real world practical breaks.

Let’s contrast AES-GCM with the other AEAD mode supported by TLS: ChaCha20-Poly1305, or ChaPoly for short.

ChaPoly uses one-time message authentication keys (derived from each key/nonce pair). If you manage to leak a Poly1305 key, the impact is limited to the messages encrypted under that (ChaCha20 key, nonce) pair.

While that’s still bad, it isn’t “decrypt all messages under that key forever” bad like with AES-GCM.

Note: “Message Authentication” here is symmetric, which only provides a property called message integrity, not sender authenticity. For the latter, you need asymmetric cryptography (wherein the ability to verify a message doesn’t imply the capability to generate a new signature), which is totally disparate from symmetric algorithms like AES or GHASH. You probably don’t need to care about this nuance right now, but it’s good to know in case you’re quizzed on it later.

H Reuse and Multi-User Security

If you recall, AES operates on 128-bit blocks even when 256-bit keys are used.

If we assume AES is well-behaved, we can deduce that there are approximately different 256-bit keys that will map a single plaintext block to a single ciphertext block.

This is trivial to calculate. Simply divide the number of possible keys () by the number of possible block states () to yield the number of keys that produce a given ciphertext for a single block of plaintext: .

Each key that will map an arbitrarily specific plaintext block to a specific ciphertext block is also separated in the keyspace by approximately .

This means there are approximately independent keys that will map a given all-zero plaintext block to an arbitrarily chosen value of (if we assume AES doesn’t have weird biases).

Credit: Harubaki

“Why Does This Matter?”

It means that, with keys larger than 128 bits, you can model the selection of as a 128-bit pseudorandom function, rather than a 128-bit permutation. As a result, you an expect a collision with 50% probability after only different keys are selected.

Note: Your 128-bit randomly generated AES keys already have this probability baked into their selection, but this specific analysis doesn’t really apply for 128-bit keys since AES is a PRP, not a PRF, so there is no “collision” risk. However, you end up at the same upper limit either way.

But 50% isn’t good enough for cryptographic security.

In most real-world systems, we target a collision risk. So that means our safety limit is actually different AES keys before you have to worry about reuse.

This isn’t the same thing as symmetric wear-out (where you need to re-key after a given number of encryptions to prevent nonce reuse). Rather, it means after your entire population has exhausted the safety limit of different AES keys, you have to either accept the risk or stop using AES-GCM.

If you have a billion users (), the safety limit is breached after AES keys per user (approximately 262,000).

“What Good is H Reuse for Attackers if HF differs?”

There are two numbers used in AES-GCM that are derived from the AES key. is used for block multiplication, and (the value of with a counter of 0 from the following diagram) is XORed with the final result to produce the authentication tag.

The arrow highlighted with green is HF.

It’s tempting to think that a reuse of isn’t a concern because will necessarily be randomized, which prevents an attacker from observing when collides. It’s certainly true that the single-block collision risk discussed previously for will almost certainly not also result in a collision for . And since isn’t reused unless a nonce is reused (which also leaks directly), this might seem like a non-issue.

Art by Khia.

However, it’s straightforward to go from a condition of reuse to an adaptive chosen-ciphertext attack.

1. Intercept multiple valid ciphertexts.
   
   • e.g. Multiple JWTs encrypted with {"alg":"A256GCM"}

   
   

2. Use your knowledge of , the ciphertext, and the AAD to calculate the GCM tag up to the final XOR. This, along with the existing authentication tag, will tell you the value of for a given nonce.
3. Calculate a new authentication tag for a chosen ciphertext using and your candidate value, then replay it into the target system.

While the blinding offered by XORing the final output with is sufficient to stop from being leaked directly, the protection is one-way.

Ergo, a collision in is not sufficiently thwarted by .

“How Could the Designers Have Prevented This?”

The core issue here is the AES block size, again.

If we were analyzing a 256-bit block variant of AES, and a congruent GCM construction built atop it, none of what I wrote in this section would apply.

However, the 128-bit block size was a design constraint enforced by NIST in the AES competition. This block size was during an era of 64-bit block ciphers (e.g. Triple-DES and Blowfish), so it was a significant improvement at the time.

NIST’s AES competition also inherited from the US government’s tradition of thinking in terms of “security levels”, which is why there are three different permitted key sizes (128, 192, or 256 bits).

“Why Isn’t This a Vulnerability?”

There’s always a significant gap in security, wherein something isn’t safe to recommend, but also isn’t susceptible to a known practical attack. This gap is important to keep systems secure, even when they aren’t on the bleeding edge of security.

Using 1024-bit RSA is a good example of this: No one has yet, to my knowledge, successfully factored a 1024-bit RSA public key. However, most systems have recommended a minimum 2048-bit for years (and many recommend 3072-bit or 4096-bit today).

With AES-GCM, the expected distance between collisions in is , and finding an untargeted collision requires being able to observe more than different sessions, and somehow distinguish when collides.

As a user, you know that after different keys, you’ve crossed the safety boundary for avoiding collisions. But as an attacker, you need bites at the apple, not . Additionally, you need some sort of oracle or distinguisher for when this happens.

We don’t have that kind of distinguisher available to us today. And even if we had one available, the amount of data you need to search in order for any two users in the population to reuse/collide is challenging to work with. You would need the computational and data storages of a major cloud service provider to even think about pulling the attack off.

Naturally, this isn’t a practical vulnerability. This is just another gripe I have with AES-GCM, as someone who has to work with cryptographic algorithms a lot.

Short Nonces

Although the AES block size is 16 bytes, AES-GCM nonces are only 12 bytes. The latter 4 bytes are dedicated to an internal counter, which is used with AES in Counter Mode to actually encrypt/decrypt messages.

(Yes, you can use arbitrary length nonces with AES-GCM, but if you use nonces longer than 12 bytes, they get hashed into 12 bytes anyway, so it’s not a detail most people should concern themselves with.)

If you ask a cryptographer, “How much can I encrypt safely with AES-GCM?” you’ll get two different answers.

1. Message Length Limit: AES-GCM can be used to encrypt messages up to bytes long, under a given (key, nonce) pair.
2. Number of Messages Limit: If you generate your nonces randomly, you have a 50% chance of a nonce collision after messages.
   However, 50% isn’t conservative enough for most systems, so the safety margin is usually much lower. Cryptographers generally set the key wear-out of AES-GCM at random nonces, which represents a collision probability of one in 4 billion.

These limits are acceptable for session keys for encryption-in-transit, but they impose serious operational limits on application-layer encryption with long-term keys.

Random Key Robustness

Before the advent of AEAD modes, cryptographers used to combine block cipher modes of operation (e.g. AES-CBC, AES-CTR) with a separate message authentication code algorithm (e.g. HMAC, CBC-MAC).

You had to be careful in how you composed your protocol, lest you invite Cryptographic Doom into your life. A lot of developers screwed this up. Standardized AEAD modes promised to make life easier.

Many developers gained their intuition for authenticated encryption modes from protocols like Signal’s (which combines AES-CBC with HMAC-SHA256), and would expect AES-GCM to be a drop-in replacement.

Unfortunately, GMAC doesn’t offer the same security benefits as HMAC: Finding a different (ciphertext, HMAC key) pair that produces the same authentication tag is a hard problem, due to HMAC’s reliance on cryptographic hash functions. This makes HMAC-based constructions “message committing”, which instills Random Key Robustness.

Critically, AES-GCM doesn’t have this property. You can calculate a random (ciphertext, key) pair that collides with a given authentication tag very easily.

This fact prohibits AES-GCM from being considered for use with OPAQUE (which requires RKR), one of the upcoming password-authenticated key exchange algorithms. (Read more about them here.)

Better-Designed Algorithms

You might be thinking, “Okay random furry, if you hate AES-GCM so much, what would you propose we use instead?”

I’m glad you asked!

XChaCha20-Poly1305

For encrypting messages under a long-term key, you can’t really beat XChaCha20-Poly1305.

• ChaCha is a stream cipher based on a 512-bit ARX hash function in counter mode. ChaCha doesn’t use S-Boxes. It’s fast and constant-time without hardware acceleration.
• ChaCha20 is ChaCha with 20 rounds.
• XChaCha nonces are 24 bytes, which allows you to generate them randomly and not worry about a birthday collision until about messages (for the same collision probability as AES-GCM).
• Poly1305 uses different 256-bit key for each (nonce, key) pair and is easier to implement in constant-time than AES-GCM.
• XChaCha20-Poly1305 uses the first 16 bytes of the nonce and the 256-bit key to generate a distinct subkey, and then employs the standard ChaCha20-Poly1305 construction used in TLS today.

For application-layer cryptography, XChaCha20-Poly1305 contains most of the properties you’d want from an authenticated mode.

However, like AES-GCM (and all other Polynomial MACs I’ve heard of), it is not message committing.

The Gimli Permutation

For lightweight cryptography (n.b. important for IoT), the Gimli permutation (e.g. employed in libhydrogen) is an attractive option.

Gimli is a Round 2 candidate in NIST’s Lightweight Cryptography project. The Gimli permutation offers a lot of applications: a hash function, message authentication, encryption, etc.

Critically, it’s possible to construct a message-committing protocol out of Gimli that will hit a lot of the performance goals important to embedded systems.

Closing Remarks

Despite my personal disdain for AES-GCM, if you’re using it as intended by cryptographers, it’s good enough.

Don’t throw AES-GCM out just because of my opinions. It’s very likely the best option you have.

Although I personally dislike AES and GCM, I’m still deeply appreciative of the brilliance and ingenuity that went into both designs.

My desire is for the industry to improve upon AES and GCM in future cipher designs so we can protect more people, from a wider range of threats, in more diverse protocols, at a cheaper CPU/memory/time cost.

We wouldn’t have a secure modern Internet without the work of Vincent Rijmen, Joan Daemen, John Viega, David A. McGrew, and the countless other cryptographers and security researchers who made AES-GCM possible.

Change Log

• 2021-10-26: Added section on H Reuse and Multi-User Security.

https://soatok.blog/2020/05/13/why-aes-gcm-sucks/

#AES #AESGCM #cryptography #GaloisCounterMode #opinion #SecurityGuidance #symmetricCryptography

Dhole Moments

2020-07-09 09:28:32

Sometimes my blog posts end up on social link-sharing websites with a technology focus, such as Lobste.rs or Hacker News.

On a good day, this presents an opportunity to share one’s writing with a larger audience and, more importantly, solicit a wider variety of feedback from one’s peers.

However, sometimes you end up with feedback like this, or this:

Apparently my fursona is ugly, and therefore I’m supposed to respect some random person’s preferences and suppress my identity online.

I’m no stranger to gatekeeping in online communities, internet trolls, or bullying in general. This isn’t my first rodeo, and it won’t be my last.

These kinds of comments exist to send a message not just to me, but to anyone else who’s furry or overtly LGBTQIA+: You’re weird and therefore not welcome here.

Of course, the moderators rarely share their views.

https://twitter.com/pushcx/status/1281207233020379137

Because of their toxic nature, there is only one appropriate response to these kinds of comments: Loud and persistent spite.

So here’s some more art I’ve commissioned or been gifted of my fursona over the years that I haven’t yet worked into a blog post:

Art by kazetheblaze
Art by leeohfox
Art by Diffuse Moose

If you hate furries so much, you will be appalled to learn that factoids about my fursona species have landed in LibreSSL’s source code (decoded).

Never underestimate furries, because we make the Internets go.

I will never let these kind of comments discourage me from being open about my hobbies, interests, or personality. And neither should anyone else.

If you don’t like my blog posts because I’m a furry but still find the technical content interesting, know now and forever more that, when you try to push me or anyone else out for being different, I will only increase the fucking thing.

---

Header art created by @loviesophiee and inspired by floccinaucinihilipilification.

https://soatok.blog/2020/07/09/a-word-on-anti-furry-sentiments-in-the-tech-community/

#antiFurryBullying #cyberculture #furry #HackerNews #LobsteRs #Reddit

Dhole Moments

2020-06-08 07:04:26

Furward Momentum (Introduction)

1. Building Your Support Network and/or Team
2. Mapping the Technology Landscape
3. Learning the Fundamental Skills
4. Choosing Your Path
5. Starting and Growing an Open Source Project
6. Building Your C.V.
7. Getting Your First Tech Job
8. Starting a Technology Company
9. Career Growth and Paying It Forward

---

If you’re reading this, I presume you want to pursue a career in technology, but you have little-to-no work experience to cite on your resume.

https://twitter.com/JibKodi/status/907290992289751046

This is ambitious; your success is not guaranteed. But with a little bit of care and a lot of dedication, you can pull it off!

But–and I cannot emphasize this enough–you won’t do it alone.

https://twitter.com/JibKodi/status/908742571014463491

Falsehoods People Believe About Success

It’s difficult to talk about careers without stumbling into a lot of falsehoods and cognitive distortions that many of us have picked up from society over the years. Let’s take a moment to acknowledge some of these myths and delusions so we can deprogram ourselves of them.

The myth of “the self-made man” needs to be retired. It’s the trifecta of widespread, harmful, and incorrect. A lot of books have been sold to people in desperate pursuit of this myth. This genre is called “self help”, which displays an amusing lack of self-awareness: If you could help yourself, what do you need the book for?

People who claim to be “self-made” are somewhere on a spectrum that ranges from breathtaking ignorance all the way to self-entitled narcissism that borders on solipsism.

I’m not here to stroke anyone’s ego or sell you anything.

Humans (and, I suppose, animals of the anthropomorphic variety) are a social species. Our career success cannot exist in a vacuum of our own ego. Anyone who wants to be self-made has doomed themselves from the offset.

No matter what you specialize in, nor how talented you are, you will always sink or swim largely based on how well you work with others. Being able to work effectively on your own is a smaller (but still important) component.

However, working well with others doesn’t mean being an ass-kisser or a push-over. You can and SHOULD say “No” to unreasonable demands. Value your time and assert your personal boundaries. If you don’t, nobody else will.

Some people seem to think (especially regarding women and queer folks) that others can get promoted through an organization by being attractive and/or sexually promiscuous. I like to ask them if they’ve ever tested their theory in their own life, and if not, why they believe it to be true.

Envy is just the shadow of narcissism, and it’s a bad look for everyone. Rather than disparaging others for career success you feel is unwarranted, wouldn’t your time be better spent on improving yourself (and helping the other people you feel are more deserving do the same, thereby cancelling out the relative trajectory of those you think are “unworthy”)?

The Simple Truth

If you want to change careers, you’re going to need the support of your friends and family (chosen or otherwise).

If you don’t have any friends, or your friends are unable or unwilling to support you in your ambitions, stop what you’re doing and find people who will.

“But I don’t know anyone!”

I run a group on Telegram called Furry Technologists for furries interested in science and technology. Start there; I promise we don’t bite.

Furry Technologists Group Logo

“What if I’m not a furry?”

No problem. There are plenty of venues for folks of every background to meet each other on the Internet.

For example, there’s a Slack channel called LGBTQ in Technology that I recommend to LGBTQIA+ people outside the furry fandom interested in tech work.

If you can’t locate a venue that you feel comfortable making friends in, ask around.

“What’s stopping us from pursuing our dreams? Nothing!” Art by ScruffKerfluff.

Form a Coalition or Task Force

For the remainder of this series, I’m going to assume that you’ve managed to gather a small group of 3-6 people (including yourself) to pursue this journey together.

You can think of this as a coalition or task force, since your scope is a little bit wider and more ambitious than “study buddies”: You will be helping each other and holding each other accountable throughout this whole process. (Some people prefer to call such a team a “think tank”. That’s fine too.)

So choose your team carefully.

On Romance and Technology Careers

Open and/or polyamorous relationships are valid, but if you’re in one and considering pursuing a career change with only your sexual/romantic partners to support you, you may want to reconsider.

Pursuing a career change is somewhat destabilizing (unless you’re already on shaky ground because the economy is totally fucked). If your only support network consists of people you’re intimate with, one of two things can go wrong:

1. Relationship troubles can throw a wrench in your plans to pursue your career change, especially if the tension prevents you from studying together.
2. Challenges and setbacks toward your new career can amplify minor conflicts with some or all of your partners.

The easiest way to mitigate these risks is to avoid the situation to begin with, and study with people outside of your polycule.

However, if all of you are negatively affected by the economy, you may not have another option than to work together.

Effective Communication Skills

The first thing you’ll want to work on when you’re starting this journey is effective communication. This may come naturally to a lot of people, so feel free to skip it if everyone’s up to snuff. There’s plenty to do and no time to waste, after all.

Be direct. If you naturally adopt an indirect communication style, this is even more important to deliberately focus on.

Avoid blame. Even if something is their fault, the responsibility is shared among everyone. The only thing we have to blame is blame itself.

Practice echoing questions before you answer them. This shows that you understand the question, and in emotionally intense discussions, it tells the other person that you’re listening.

If you’re a book person, Thinking, Fast and Slow and Nonviolent Communication are both worth reading.

If you’re more of a video person, you can get a lot of mileage out of these TED Talks by Julian Treasure:

https://www.ted.com/talks/julian_treasure_how_to_speak_so_that_people_want_to_listen?language=en

https://www.ted.com/talks/julian_treasure_5_ways_to_listen_better/transcript?language=en

You’ll never be quite finished polishing up your soft skills, but that’s okay! You only need to be better than 50% of the people you’ll encounter to make a positive impression; and a lot of people downright suck at it. Their weakness is your opportunity.

Keeping Yourself Honest

Good intentions never work, you need good mechanisms to make anything happen.

Jeff Bezos, the richest man in modern history (source)

As you work through the remainder of this series, whether you’re actively working together or focusing on different things independently and then meeting up routinely to compare notes, you’ll want to go a step beyond verbally agreeing to meet at a designated time.

Write it down. Send calendar invites if you have to.

Don’t make it convenient for things to slip your mind, or else they will.

A huge part of changing careers is developing new habits, and the two that will serve you well universally in technology is taking notes and putting stuff on calendars.

And when (not if, when) something does slip for someone, have a conversation with them. Maybe you need to slow down so they can catch up. Maybe something happened in their personal life that disrupted their flow and they need to collect themselves. Be empathetic.

What You Will Be Doing Together

So you’ve built a coalition/team. What do you do with it?

In the beginning, you will be looking at the different roles in the technology industry and trying to ascertain which jobs you’ll most likely succeed at. We’ll cover this in the next section, Mapping the Technology Landscape.

Once you have even a vague idea of where you’re headed, your coalition will be studying together to Learn the Fundamental Skills. Even if you’re all specializing in vastly different areas with no overlapping curricula, you’ll be pleasantly surprised how effective, “Can I explain this concept to someone outside of this specialized domain?” is towards measuring your own comprehension of the subject.

After you’ve got the hang of the fundamentals of your chosen discipline and had a chance to work together, the next step is Choosing Your Path: You must collectively decide whether you want to work for an existing company or start your own together. There are advantages and disadvantages to both choices, but in the beginning you may want to at least prepare to get hired rather than start out from scratch.

Regardless of your destination, the next step will be to gain some experience. For this step, I recommend Starting and Growing an Open Source Project. If you’re choosing the path of an employee, this will give you a chance to gain experience. If you’re choosing the path of an entrepreneur, this will give you a chance to develop a prototype solution for the kinds of problems you want to solve professionally. In either case, an open source project is the best opportunity to check your own understanding with other teams/coalitions going through a similar journey and learn from each other.

With a bit of experience under your belt from the previous step, the next step is Building Your C.V. Notice I didn’t call it a résumé. A résumé is just a document; a C.V. is also about your reputation and accomplishments within an industry.

Naturally, the step that follows is either Getting Your First Tech Job or Starting a Technology Company, depending on which path you chose after learning the fundamental skills.

The very first job of your technology career may not be what you hope for. Mine definitely wasn’t, but your mileage may vary. Thus, the final entry in this series is dedicated to Career Growth and Paying It Forward. If you’re not yet happy with where you landed, this section should help you grow your skills further and attain the role you were seeking from the offset of your journey. When you finally get to where you want to be, you’ll very likely be adept at helping your friends and community members escape from unfavorable life circumstances.

---

Next: Mapping the Technology Landscape

https://soatok.blog/furward-momentum-building-your-support-network-and-or-team/

Dhole Moments

2020-07-09 09:28:32

Sometimes my blog posts end up on social link-sharing websites with a technology focus, such as Lobste.rs or Hacker News.

On a good day, this presents an opportunity to share one’s writing with a larger audience and, more importantly, solicit a wider variety of feedback from one’s peers.

However, sometimes you end up with feedback like this, or this:

Apparently my fursona is ugly, and therefore I’m supposed to respect some random person’s preferences and suppress my identity online.

I’m no stranger to gatekeeping in online communities, internet trolls, or bullying in general. This isn’t my first rodeo, and it won’t be my last.

These kinds of comments exist to send a message not just to me, but to anyone else who’s furry or overtly LGBTQIA+: You’re weird and therefore not welcome here.

Of course, the moderators rarely share their views.

https://twitter.com/pushcx/status/1281207233020379137

Because of their toxic nature, there is only one appropriate response to these kinds of comments: Loud and persistent spite.

So here’s some more art I’ve commissioned or been gifted of my fursona over the years that I haven’t yet worked into a blog post:

Art by kazetheblaze
Art by leeohfox
Art by Diffuse Moose

If you hate furries so much, you will be appalled to learn that factoids about my fursona species have landed in LibreSSL’s source code (decoded).

Never underestimate furries, because we make the Internets go.

I will never let these kind of comments discourage me from being open about my hobbies, interests, or personality. And neither should anyone else.

If you don’t like my blog posts because I’m a furry but still find the technical content interesting, know now and forever more that, when you try to push me or anyone else out for being different, I will only increase the fucking thing.

---

Header art created by @loviesophiee and inspired by floccinaucinihilipilification.

https://soatok.blog/2020/07/09/a-word-on-anti-furry-sentiments-in-the-tech-community/

#antiFurryBullying #cyberculture #furry #HackerNews #LobsteRs #Reddit

Dhole Moments

2020-05-27 00:13:21

A paper was published on the IACR’s ePrint archive yesterday, titled LadderLeak: Breaking ECDSA With Less Than One Bit of Nonce Leakage.

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:

1. 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).
2. That you’re using a cryptography library with cache-timing leaks.
3. 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.

There’s even a CryptoPals challenge about these attacks.

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:

1. Never reused
2. Unpredictable
3. Secret
4. 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.)

https://soatok.blog/2020/05/26/learning-from-ladderleak-is-ecdsa-broken/

#crypto #cryptography #digitalSignatureAlgorithm #ECDSA #ellipticCurveCryptography #LadderLeak

Dhole Moments

2024-05-14 16:26:41

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

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

Art: CMYKat

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

Recent Developments

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

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

https://twitter.com/matthew_d_green/status/1789688236933062767

https://twitter.com/matthew_d_green/status/1789689315624169716

https://twitter.com/matthew_d_green/status/1789690652399170013

https://twitter.com/matthew_d_green/status/1789691417721282958

Et cetera.

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

Why Signal is Better for Furries

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

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

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

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

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

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

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

Why Signal?

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

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

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

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

How I Setup a Second Signal Account

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

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

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

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

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

Why does Signal require a phone number?

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

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

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

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

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

Tell Your Friends

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

Lazy edit of the “Friendship Ended” meme

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

Addendum (2024-05-15)

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

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

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

https://soatok.blog/2024/05/14/its-time-for-furries-to-stop-using-telegram/

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