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

Page 2

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 →

Would Rust have prevented Heartbleed? Another look

In case you haven’t heard, another serious OpenSSL vulnerability will be announced this Thursday. It reminded me of about a year ago, when Heartbleed was announced:


In December 2014 I gave a talk at Mozilla about cryptography in Rust (slides here). I have been meaning to do a followup blog post both about my talk, reactions I received from it, and my subsequent thoughts…

And then this blog post happens. I have been reading Ted Unangst’s blog for quite awhile, mostly with great respect. This particular blog post was, unfortunately, not up to his usual standards. He blogs on a wide range of topics, but security is a complicated field and this blog post is, in my opinion, highly misleading. Ted claims he implemented “Heartbleed” in Rust. Is that actually the case?

In my talk at Mozilla, I covered several of the SSL/TLS bugs seen in 2014, and spent a lot of time covering “goto fail”

Continue reading →

Volapük: A Cautionary Tale for Any Language Community

You may have heard of artificially constructed spoken languages such as Esperanto, Interlingua, or Lojban, but do you realize that before any of these languages there was another constructed language which once claimed nearly a million followers, making it the most popular constructed language of all time?

That language was Volapük, and despite achieving such a high number of speakers is nowadays all but forgotten, even among linguists. I think Volapük’s story is one worth telling, because the reasons for its downfall are worth knowing for any member of a language community.

Volapük was created by Johann Martin Schleyer between 1879 and 1880. Schleyer was a Roman Catholic Priest who, one night, claimed to hear God himself speak to him commanding him to create a universal language to unite the European peoples. Volapük was a hybrid of English, German, and French, although you probably

Continue reading →

CREAM: the scary SSL attack you’ve probably never heard of


2014 was a year packed full of the discovery of new SSL attacks. First we found Java was vulnerable to a new type of “Bleichenbacher” attack. Apple’s SecureTransport, used by both iOS and OS X, went down next with the “goto fail” vulnerability. GNUTLS was vulnerable to a man-in-the-middle attack. OpenSSL perhaps came out as the most notorious with the Heartbleed attack. The NSS library, used by Chrome and Firefox among others, was vulnerable to yet another Bleichenbacher attack known as BERserk. The Microsoft SChannel library used by Windows was vulnerable to a particularly scary remote code execution vulnerability. At least two protocol-level vulnerabilities in SSL were widely circulated: the triple-handshake attack and POODLE. And we still have over a month left in the year!

While 2014 is a notable outlier in terms of the sheer number of attacks discovered and the publicity they’ve

Continue reading →

What’s wrong with in-browser cryptography?

Above image taken from Douglas Crockford’s Principles of Security talk

If you’re reading this, then I hope that sometime somebody or some web site told you that doing cryptography in a web browser is a bad idea. You may have read “JavaScript Cryptography Considered Harmful”. You may have found it a bit dated and dismissed it.

You may have read about WebCrypto and what it hopes to bring to the browser ecosystem. This particular development may make you feel that it’s okay to start moving various forms of cryptography into the browser.

Why not put cryptography in the browser? Isn’t it inevitable? This is a perpetual refrain from various encryption products which target the browser (names and addresses intentionally omitted). While the smarter ones try to mitigate certain classes of attacks by shipping as browser extensions rather than just a web site that a user types into their

Continue reading →

Imperfect Forward Secrecy: The Coming Cryptocalypse

If the Snowden debacle has accomplished anything, it’s raising public awareness in cryptography. This has spawned some sort of meme that if we use “perfect forward secrecy”, our communications are protected from the NSA! Various blog posts and articles in major newspapers have conferred all sorts of magical secret powers onto perfect forward secrecy, specifically surrounding its NSA-fighting powers, going as far to say that perfect forward secrecy is NSA-proof.

First off, let me say that forward secrecy is great, and you should try to deploy it if you can. However, even if you run a stack that supports it (many hardware SSL terminators do not, for example), it’s still pretty hard to implement properly (you need to rotate session ticket keys frequently to gain anything from it, for example).

But let’s not beat around the bush: perfect forward secrecy isn’t some magical silver bullet

Continue reading →

The cloud isn’t dead. It just needs to evolve

At my previous job my daily commute took me past 611 Folsom Street in San Francisco. This building is infamous for being the home of Room 641A, where a whistleblower, Mark Klein, revealed that the NSA had created a secret room and placed beam splitters on fiber optic cables carrying Internet backbone traffic.

I heard Jacob Appelbaum mention this building’s street addess in his 29c3 keynote, along with the NSA’s Utah Datacenter, where wiretapped traffic from this room was allegedly funneled and stored, a challenge that sounds daunting but according to NSA whistleblower William Binney, the datacenter has a “yottabyte” scale capacity intended to archive all the traffic they can collect for up to 100 years. From then on I got a little bit preoccupied with this building every time I walked past it on my daily commute.

It’s a building I took pictures of and tweeted about:, like this picture

Continue reading →

Let’s figure out a way to start signing RubyGems

Digital signatures are a passion of mine (as is infosec in general). Signatures are an integral part of my cryptosystem Keyspace for which I wrote the red25519 gem. The red25519 gem’s sole purpose was to expose the state-of-the-art Ed25519 digital signature algorithm in Ruby. I have since moved on to implementing Ed25519 in the much more comprehensive RbNaCl gem. Point being, I have longed for a modern, secure digital signature system in Ruby and have been working hard to make that a reality.

Digital signatures are something I think about almost every single day, and that’s probably fairly unusual for a Rubyist. That said, if you do work with Ruby, you have hopefully been informed that was compromised and that the integrity of all gems it hosted is now in question. Because of this, is down. As someone who thinks about digital signatures every day, I have

Continue reading →

“DCI” in Ruby is completely broken

Rubyists are people who generally value elegance over performance. “CPU time is cheaper than developer time!” is a mantra Rubyists have repeated for years. Performance has almost always taken a second seat to producing beautiful code, to the point that Rubyists chose what used to be (but is no longer) the slowest programming language on earth in order to get things done.

You can file me under the “somewhat agree” category, or otherwise I’d be using languages with a better performance track record like Java, Scala, or even Clojure. That said, I like Ruby, and for my purposes it has been fast enough. I also like to make light of those who would sacrifice elegance for speed, at least in Ruby, calling out those who would do silly stuff “FOR SPEED!” while compromising code clarity (otherwise known as roflscaling).

The past year though, there’s been an idea creeping through the Ruby

Continue reading →

2012: The Year Rubyists Learned to Stop Worrying and Love Threads (or: What Multithreaded Ruby Needs to Be Successful)

Let me provide a very different picture of how Rubyists used to view threads versus what the title of this post implies about now. I’m not talking about in 2005 in the early days of Rails. I’m talking about at Dr. Nic’s talk at RubyConf 2011, a little more than a year ago. Dr. Nic had a fairly simple message: when performance matters, build multithreaded programs on JRuby (also: stop using EventMachine). Now granted he was working the company that was subsidizing JRuby development at the time, but I didn’t, and I for one strongly agreed with him. Not many other people in the room did. The talk seemed to be met with a lot of incredulity.

“I thought this was going to be a talk on EventMachine!” said That Guy. Perhaps what That Guy missed was that Dr. Nic had hosted EventMachineConf as a subconference of RailsConf a few months before. And now Dr. Nic was saying don’t use EventMachine, use

Continue reading →