Cryptotronix: My new open hardware / software company

I’ve started a company: Cryptotronix, LLC. I figured it was the most responsible thing I could do before my daughter is born in about two months… For those that have been following with my BeagleBone posts, I’m focusing on the CryptoCape and making other circuit boards containing crypto chips. The first board, which I’m calling the “Hashlet,” performs SHA-256 and can store keys on the device for use in keyed-hashes. It’s specifically made for the BeagleBone Black (although one could also use a Raspberry Pi).

The Hashlet.  The chip is an ATSHA204 over I2C.  The mini-cape (capelet) sits nicely on the P9 header and has convenient I2C test points.
The Hashlet. The chip is an ATSHA204 over I2C. The mini-cape (capelet) sits nicely on the P9 header and has convenient I2C test points.

Tinkering with these devices has been a lot of fun and I am committed to seeing the CryptoCape come to fruition.  However, it’s very easy to get security and cryptography wrong (and not even know it!). Therefore, the key (ha!) is to be as open as possible, especially in the early design stages. I’m making open-hardware and where applicable, writing GPL’d software to go with the device, which should allow plenty of room for feedback.

I’m trying to keep a zen “Beginner’s Mind” about this and focus on making accessible, embedded crypto boards with the hope that others will use them as building blocks for awesome open-projects.

2 thoughts on “Cryptotronix: My new open hardware / software company

    1. This is a fair question. I realize that the choice of licenses is as polarizing as politics, so what I’ll do here is try to explain my thoughts behind the decision. I’m sure not everybody will agree, but hopefully people will respect it.

      1. Personal bias. I’m a FSF member and I generally support what the FSF does, so I’m inclined to use FSF licenses.
      2. I like the patent protection in the GPLv3 as well as the DRM clause. I’m not a fan of DRM and crypto hardware is sometimes specifically made exclusively for DRM purposes. The GPLv3 doesn’t necessarily ban DRM, but it does make it harder. I really don’t want to be the guy that made it easy for everybody to build DRM systems.
      3. Eventually I’d like this to be a kernel module, so that’s pretty much GPLv2 afaik.

      Despite my leanings toward the GPL, I’ve never been the type of person to convert people’s belief systems (unless we are talking Emacs ;). Considering everybody’s not a fan on the GPL, I think the following will help:

      • Currently, the ATSHA204 driver has a command line interface. If another program uses that interface, I don’t believe that program is restricted to the GPL. This appears consistent with the GPL FAQ

      • For the driver, eventually that should be library. For that, I’m considering using LGPLv3. That seems to be an acceptable compromise for me. It allows those who link to my software a choice of license.

      This article influenced me as well. They describe why they went the GPL route and I particularly liked their idea for a contributor agreement based on Oracle’s contributor agreement. The Clojure project also uses the same idea.

      Lastly, I’m not against dual licensing. However, it also can also have a polarizing effect. This another reason why I like the Oracle Contributor Agreement. It provides joint ownership of copyright and it states that I must always release the contributor’s work under a FSF or OSI approved license.

Comments are closed.