Tor-ramdisk 20151215 released: libressl to the rescue!

If you’ve read some of my previous posts, you know that I’ve been maintaining this hardened-Gentoo derived, uClibc-based, micro Linux distribution called “tor-ramdisk”.   Its a small image, less than 7 MB in size, whose only purpose is to host a Tor relay or exit node in a ramdisk environment which vanishes when the system is shut down, leaving no traces behind.  My student Melissa Carlson and I started the project in 2008 and I’ve been pushing out an update with every major release of Tor.  Over the years, I automated the build system and put the scripts on a git repository at that Roger Dingledine gave me.  If you want to build your own image, all you need do is run the scripts in the chroot of a hardened amd64 or i686 uClibc stage3 image which you can get off the mirrors.

Recently, upstream switched the tor-0.2.7.x branch to depend on openssl’s elliptic curves code.  Unfortunately, this code is patented and can’t be distribute in tor-ramdisk.  If you read the tor ebuilds, you’ll see that the 0.2.7.x version has to DEPEND on dev-libs/openssl[-bindist] while the 0.2.6 only depends on dev-libs/openssl.  Luckily, there’s libressl which aims to be a free drop in replacement for openssl.  Its in the tree now and almost ready to go — I say almost because we’re still in the transition phase.  Libressl in Gentoo has been primarily hasufel‘s project, but I’ve been helping out here and there.  I got a few upstream commits to make sure it works in both uClibc and musl as well as with our hardened compiler.

So, this is the first tor-ramdisk release with libressl.  Of course I tested both the amd64 and i686 images and they work as expected, but libressl is new-ish so I’m still not sure what to expect.  Hopefully we’ll get better security than we did from openssl, but I’ve got my eyes out for any CVE’s.  At least we’re getting patent free code.

Tor-ramdisk has been one of those mature projects where all I have to do is tweak a few version numbers in the scripts, press go, and out pops a new image.  But I do have some plans for improvements: 1) I need to clean up the text user interface a bit.  Its menu driven and I need to consolidate some of the menu items, like the ‘resource’ menu and the ‘entropy’ menus.  2) I want to enable IPv6 support.  For the longest time Tor was IPv4 only but for a couple of years now, it has supported IPv6.  3) Tor can run in one of several modes.  Its ideal as a relay or exit node, but can be configured as client or hidden service for processes running on a different box.  However, tor-ramdisk can’t be used as a bridge.  I want to see if I can add bridge support.  4) Finally, I’m thinking of switching from uClibc to musl and building static PIE executables.  This would make a tighter image than the current one.

If you’re interested in running tor-ramdisk, here are some links:


ChangeLog: same as i686.

15 thoughts on “Tor-ramdisk 20151215 released: libressl to the rescue!”

  1. Isn’t it the method that’s patented rather than the implementation? So won’t you still have the same patent issues with libressl?

    1. Hi Mike, you can’t patent algorithms. Anyhow, see my response to Alexis. The only thing I’m worried about is the implementation of ecc in libressl. Since it is a fork/refactoring of openssl, there *may* be too much overlap. But you can’t even turn off ecc using the configure file the way you can with openssl. I’ll bounce the question off upstream.

  2. Hey,

    I don’t understand how libressl, or any crypto implementation, makes a difference on elliptic curves patents. To me, it sounds like either openssl or libressl (ebuilds) got something wrong: the former in claiming code is patented while it’s not or the latter by shipping patented code, effectively making the code non-free but not telling it.


    1. Alexis, I’m glad you read my post because I know you went over this in bug #531540 [1]. My understanding is that you can patent an implementation but not the algorithm or the primes [2]. I know other distributions have done a variety of things like hack out questionable code (Redhat), or even just ignore the issue (like Ubuntu). I’m following OpenBSD on this which is shipping binary with libressl so I’m in the same boat they are. I’ve compare the ecc code in both openssl and libressl and they are different, but I don’t know if those difference really address the patent claims. I’ll ask upstream when I have a chance.

      Anyhow, I also switched because I’m hoping to get better security from libressl. Openssl has a bad track record last year.


      1. Actually with patents it isn’t about the implementation, but the idea. Implementation is governed more under copyright law.

        If there are patents around ECC, then they apply equally to openssl and libressl. Whether patents should apply to math is a different story, and will vary region to region. But if openssl violates the patent for the algorithm you care about, so does libressl.

        See for instance h.264, floating point textures, GIF, and MP3. All of those had a patent over part of their implementation (some still do), and so all are restricted in who can implement them. h.264 is considered a bad video format because you can’t clean room implement a encoder/decoder for it and fall victim to a patent case. If you could, would Mozilla be avoiding the algorithm like they do? Would Cisco pay out millions of dollars to license a decoder for use in VOIP products in free software?

        1. I get this but ecc is a mathematical idea. I find it so hard to get my head around that. So can I even teach elliptic curve in my classes? Anyhow, is OpenBSD then infringing on the patent?

          1. It depends a lot on what, exactly is covered by the patent. “Algorithms” aren’t patentable in most places, but you’ll find that most code patents are described as a “system and method” (as though they were a novel way of arranging an assembly line) which, for some, strange reason, is patentable.

            You may certainly teach *about* the algorithms. But any actual implementation, even done by hand on the blackboard could easily be a violation. I know of professors who have been forced to pay royalties for demonstrating patented algorithms in class, although my knowledge is hearsay and not direct.

            There are some exemptions allowing a person to make a limited number of a patented item for research purposes. In the chemistry world, the courts have taken the opinion that the exemptions apply per-molecule, effectively rendering the exemptions useless. I would expect in the computer world that it would be found that the exemptions apply per physical copy of the algorithm, meaning you would be limited in the number of times you could write it down, or cause it to appear on a projector. And no, destroying a previous implementation doesn’t credit back toward your lifetime total of free implementations. So, you could end up on-the-hook for a pretty penny in royalties depending on what the patent covers and what you do in your classes.

        2. “Actually with patents it isn’t about the implementation, but the idea. Implementation is governed more under copyright law.”

          A patent applies to an implementation; every single bullet point in the “Claims” section on the patent has to match *exactly* for something to be infringing. Too many people don’t understand this and read the title or the abstract of a patent and think it applies broadly to everything that it vaguely describes. (Note: this is only for regular patents, not dress patents).

          I suggest searching for “Andrew Tridgell on Patent Defence”, and watch his talk or read the transcript, for a better explanation of this.

  3. ” I know of professors who have been forced to pay royalties for demonstrating patented algorithms in class,” Okay seriously here, citation needed.

  4. Well, as already said, patents are about the “idea”. How to draw the line between a somewhat simple mathematical function, undergrad course material, and a patented idea is not easy at all though. It gets even worse when you can see unclear lawsuits about patents on a technique that had been published in international journals by unrelated researchers prior to the patent issue (meaning patent holders have somewhat done plagiarism).

    As for openssl ECC, the only references I’ve been able to find is about patents that have expired. It is, however, hard, if not impossible, to assert those are the only ones. Then you can extract various ways to handle it:
    1. Assume there are no other, unless proven otherwise. Like most distributors do. These are your openbsd/ubuntu examples.
    2. Conduct a thorough review of the techniques, and enable only those you have been able to assert patents have expired (or research papers are old enough so that no one can claim a new patent on it). This is the redhat example.
    3. Be safe & lazy: Disable everything just in case. This is the Gentoo example.

Leave a Reply

Your email address will not be published.