Tony Arcieri

Hi there. These days I dabble in cryptography, but in the past made the Celluloid actor framework for Ruby and the Reia programming language

Read this first

It’s time for a memory safety intervention


Memory safety won’t fix shell escaping bugs. Memory safety won’t fix logic bugs. Memory safety will not prevent an attacker who has obtained your HMAC key from forging a malicious credential that, when deserialized, can call arbitrary Ruby methods (yes, this was a real vulnerability in older versions of Rails). Memory safety will not prevent a federated identity system which uses XML-based credentials from accidentally running attacker controlled commands due to external entity processing (yes, this was a real vulnerability in certain implementations of SAML). A language which provides a memory safe model but binds to unsafe code is still vulnerable when calling into unsafe code.

Nobody disputes these things. Now that we have that out of the way…

Programming in C means you are using an unsafe memory model 100% of the time. It is the programming equivalent of trying to walk a

Continue reading →

Key rotation, user experience, and crypto reporting

Screen Shot 2017-01-13 at 10.57.32 PM.png

WhatsApp was the subject of a recent Guardian article making claims of a “backdoor” stemming from a “bug” in the way WhatsApp handles key rotations for users. The problem? WhatsApp will automatically transmit messages after the recipient’s key has changed without first asking the sender to confirm the new key is genuine.

Far from being a “bug” or “backdoor” (a claim so wrong I am sure hoping the original author of the story Samuel Gibbs will issue a retraction), handling key rotation seamlessly is a difficult problem with a long-storied history, along with many attempts to surface such information to the user in order to ask them to make a security decision, such as in the SSH screenshot above.

Clearly an in-person exchange of key fingerprints is the most secure option for establishing a secure channel, but is inconvenient, often impractical, and doesn’t provide a good means for

Continue reading →

4 fatal flaws in deterministic password managers

Wouldn’t it be nice if your password manager didn’t need a database? Instead of synchronizing a password vault between your devices, you could use the magic of cryptography to magically transform a master password into a unique password for each site.

There have been a numerous and ever growing implementations of this idea. Much of the marketing material for these tools talks about how using a deterministic scheme allows “sync-free” operation, is “more secure” than a password vault, and often that it’s a newer idea than encrypted password vaults.

In this post, I will argue that you can’t practically provide “sync-free” operation without making your password manager unusable, how using a deterministic scheme harms security, and how it’s actually an old idea which never caught on for good reasons.

Deterministic password derivation schemes date back to at least 2003: Stanford PwdHash and

Continue reading →

A quick tour of Rust’s Type System Part 1: Sum Types (a.k.a. Tagged Unions)

Rust is one of those hip new programming languages you might get tired of hearing about on the Hacker News, but talking with people who have heard of Rust but haven’t actually looked into it in depth, I feel like what Rust actually offers you as a programmer is often poorly communicated. The more I use Rust, the more I’ve come to discover that the single most important thing it offers, the part of the language that almost all of its other benefits fall out of, is its type system.

I’m embarking on a short series of blog posts which will explore Rust’s type system, and hopefully describe things in a beginner-friendly way such that you don’t need to know a whole lot about advanced type systems to understand what I’m talking about.

Before I go any further talking about type systems, let me make one thing clear: this is not a post for type system experts. If you’re a functional programmer

Continue reading →

Introducing TJSON, a stricter, typed form of JSON

TJSON logo

NOTE: TJSON syntax has been revised since this post was originally published. Please visit for the latest syntax.

I’d like to announce a project I’ve been working on with Ben Laurie called TJSON (Tagged JSON).

TJSON is syntax-compatible with JSON, but adds mandatory type annotations. Its primary intended use is in cryptographic authentication contexts, particularly ones where JSON is used as a human-friendly alternative representation of data in a system which otherwise works natively in a binary format.

Before I go further describing TJSON, I’d like to give some background.


JSON is a bit of a mess. You may have seen Parsing JSON is a Minefield recently, which did a fantastic job of illustrating that while JSON’s “simplicity is a virtue” approach lead to widespread adoption, underspecification has lead to a proliferation of interoperability

Continue reading →

A gentle introduction to nio4r: low-level portable asynchronous I/O for Ruby

Rails 5.0 was recently released, and with it came ActionCable, a new part of the framework to put WebSockets “on Rails”. ActionCable has had something of a sordid history, from taking Rails Core developer Aaron Patterson by surprise when he first heard of it at a RailsConf keynote to at one point using both EventMachine and Celluloid, each of which independently is an onerous dependency (I say this as the author of Celluloid).

That said, the dust has settled and both EventMachine and Celluloid have been removed. Instead, ActionCable is based on concurrent-ruby, a Ruby library inspired by Java’s java.util.concurrent which was already a Rails dependency, and nio4r, i.e. New I/O (or Non-blocking I/O) for Ruby, a library you may not have heard of before inspired by java.nio. While EventMachine and Celluloid are both grand inventions, I think there’s something to be said for copying our

Continue reading →

A tale of two cryptocurrencies: Ethereum and Bitcoin’s ongoing challenges


It’s been one of the most interesting months in the history of cryptocurrency. The price of Bitcoin has soared up to nearly $800 (then dropped to $675 as $19 million in BTC hit the market) as the reward for mining a block is soon set to be halved. Ethereum created what is arguably the world’s most complex multi-million dollar financial instrument, the DAO, only to see it hacked through a combination of flaws in its “smart contract” and the language it was implemented in. Meanwhile, the average size of a block in the Bitcoin blockchain nears 90% of the 1MB hard limit.

I’ve been meaning to write a year-in-review followup to my previous post The Death Of Bitcoin, but with the recent events covering Ethereum I just couldn’t help but cover that too, and also speculate what effects this will have on Bitcoin.

 Ethereum’s Hindenburg moment: The DAO disaster and smart contract security

Continue reading →

On the dangers of a blockchain monoculture


At first there was Bitcoin: the world’s most successful cryptocurrency to-date. But lately there has been more and more talk about “the Bitcoin blockchain”, “the blockchain”, “blockchain”, or “blockchain technology”. Bloomberg reports that Nasdaq is seeking to show progress using the much-hyped blockchain. LWN notes The Linux Foundation recently announced a project to “advance blockchain technology”. The Washington Post lists Bitcoin and the blockchain as one of six inventions of magnitude we haven’t seen since the printing press. VISA, Citi, and Nasdaq have invested $30 million into a blockchain company. VCs have collectively invested $1 billion in the Bitcoin ecosystem. Bank of America is allegedly trying to load up on “blockchain” patents. The Bank of England says there’s lots of “buzz around blockchain” and is curious what you’d use “blockchain” for. It seems “blockchain” is

Continue reading →

The Death of Bitcoin


The road of innovation is paved with the corpses of outmoded technologies. Throughout history there are countless examples of a technology presumed to be the “next big thing” starting to gain traction, only to find itself outmoded in the light of a technology that can solve a problem better.

Will this happen to Bitcoin? I don’t know. Unfortunately I don’t have a crystal ball which can tell me that. However, I think it’s an interesting thing to speculate about. Bitcoin is described by enthusiasts as potentially being bigger than the Internet itself (a claim I can’t seem to understand, considering that Bitcoin is an Internet-powered technology), but what if the opposite happened, and Bitcoin wound up being as popular as Betamax cassettes or Napster in the grand scheme of things?

I don’t want to be entirely grim, despite this post’s title. This isn’t intended to be some “Bitcoin is

Continue reading →

An open letter to Matz on Ruby type systems


Hi Matz,

I really enjoyed your keynote at RubyConf 2014. The most interesting part of it to me was where you talked about how Ruby 3.0 might include some sort of type system. There are lots of directions you can go with type systems in Ruby. Your presentation talked about how you like to explore different directions that you could go with a given feature.

I think there were two big points you made about a type system in Ruby that are important:

  • DRY: adding types should not make the Rubyist add type declarations to their program over and over again
  • Duck Typing: this is important to the way Rubyists program and any type system added to Ruby should still enable duck typing

After many years of writing Ruby, I have taken on a rather defensive programming style for a lot of the code I write after debugging too many type-related issues. I often find myself writing code like this:

Continue reading →