Some observations on the FormLab’s Form 2 printer:

First, the resolution of the objects that are printed is simply amazing. I remember putting together the original Makerbot; this thing prints objects that are absolutely amazing compared to the extruded noodle of the original Makerbot print objects.

For example, I’m able to print 2 millimeter holes through a design and have them come out exactly 2 millimeters in size. I’m printing 32p gears; these are gears with 10 teeth per circumference inch and have them come out perfectly. (I tried the same thing with the original Makerbot; there is no way 32p gears could possibly have worked. Of course the current generation of Makerbots are light years ahead of the box of do-it-yourself wooden parts and gears of the original Makerbot printer.

Here are some parts I printed; they look imperfect because I roughly sanded them using 320 grit sand paper to see how well things would hold up to sanding. (You can get a much better result if you follow FormLab’s instructions.)

I’m currently writing a Macintosh app which can be used to design gear chain mechanisms using spur gears; the mechanism is the top and bottom of a simple gear chain which performs a clock motion work, stacking two gears with a 12 to 1 ratio, so when one gear (attached to a minute hand) turns one full revolution, the other stacked gear (attached to an hour hand) would turn 1/2th of a revolution.

This is a test mechanism; ultimately I’m looking to design a clock, and I may write more about it in later posts.

The pins are 2mm by 25mm long pins; I was able to specify the holes to an amazing degree of accuracy. I was able to specify the holes in the corners of the frame to a 1/10th of a mm larger than the hole of a standard M3 screw. (Right now I’m waiting for some washers I ordered to insert between the gears.)

It’s stunning how great the quality of the parts printed are.

Of course this resolution and quality has a cost: time. The two frames that I printed to hold the gears (a test of the software that generates Delaunay triangles to triangulate the axle locations for my gears; the resulting frame was bigger than I wanted, so I need to tweak it) took 7 hours to print.

Yes, you read that right. Seven hours.

The four gears inside took around 4 hours to print.

But then, it makes sense. The Form 2 printer takes care to agitate and heat the resin to a consistent state; this allowed me to print some amazing items pretty much right out of the box. After each layer is printed (and each layer is 50 microns thick; about the thickness of a very thin piece of paper), the resin is agitated and the area cleared for the next layer. Needless to say for an object 3 inches tall, building up the part 50 microns at a time takes a while.

The resulting parts come out tacky. Even after bathing the parts in isopropyl alcohol for 20 minutes, the resin is not set or cured; you must allow the parts to finish curing–either in a UV light (mine is on order), or let the part rest for about a day.

Another thing to note is that while the results of using automatic scaffolding helps make the parts print correctly, sometimes with heavy objects the scaffolding can fail, causing print errors. (I tried printing a model of a manatee for my wife, only to have the flippers and head separate from the rest of the body, as the body was too heavy to hold rigid during printing. I fixed the model by gluing the pieces back together.)

Further, the automatic scaffolding algorithm can be a pain; you need to review the parts and edit the scaffolding locations. For example, the above photographed gears have a problem meshing; bits of the scaffolding got stuck between the teeth. So if you have surfaces that must be perfectly shaped and clean, you may need to edit how the scaffolding gets applied.

At some point when I get the gear design software working, I’ll publish a note here.

What is Noam Chomsky best known for?

• His left-wing political positions, especially his positions on the Israeli-Palestinian conflict and his position on modern capitalism.
• His work on Transformational generative grammars, and his work on formal grammars and the Chomsky-Schützenberger hierarchy.

So I picked up a small Arduboy on Kickstarter, and I tossed together a game.

It’s cool to be playing with a device with only 2.5K of RAM (of which 1K is dedicated to an offscreen drawing bitmap), and only 32K of program space (of which about 8K or so is dedicated to the Arudboy firmware). The way you write software for such a small device is completely different than how you’d write software for a larger device with more memory.

The game is a variation on the box moving puzzle games out there; at present I have 30 levels of varying difficulty. You can download the sources for the game from GitHub.

Makes me want to get involved in the IoT, of course with better security practices than we saw here, or here.

So the next project I’m taking on requires that I carry general liability insurance. And one of the requirements of the general liability insurances was to take down and stop selling E6B software for pilots.

Great.

Well, it’s not like I sold a lot of copies of the software to the public. And heck, the Android version wasn’t even active; the software had been taken down from the Play store because I forgot to renew some contracts with Google Play.

But it is a shame that something like that cannot be offered to the public.

I’ve got a couple of weeks; I’ll probably publish all of the code open source on my personal GitHub account instead, because why not?

Credential Stealing as an Attack Vector

Basically if someone can steal your password, they often can get into your system and do a lot of damage.

A quick review: authentication “factors” involve who you are, what you know, and what you have. A one-factor authentication technique involves just one of these three things: a key to your front door involves what you have, a password involves what you know. We can bolster the strength of any of these “factors” by requiring longer passwords or better designed keys and key locks, but you only have one thing to bypass to get into the system.

For “two factor” authentication to work, it involves two of these three factors: routinely it involves “what you have” and “what you know.” So your ATM card is a two-factor system: you must first present your ATM card, then enter your password PIN.

What makes two factor authentication more powerful is that now you have two systems (working on concert) to bypass. This also allows you to weaken one factor if the other factor must also be present–such as an ATM PIN which is an easily guessable 4 to 6 digit number.

The nice thing about cell phones is that it easily allows us to distribute software that allows your cell phone to participate in the login process: making “what you have” your cell phone as part of the login process.

And there are a number of applications out there which can be used as part of a two-factor authentication process, such as Google Authenticator, which implements TOTP and HOTP one-time passwords. It should also be relatively easy to implement your own one-time password application, though ideally unless you know what you’re doing, just download and drop in the libraries from someone else’s implementation.

Security is, in part, about making it more expensive for a hacker to crack your system and obtain secure information.

Yesterday I noted that just because you wrap your protocol in SSL/TLS doesn’t make it secure.

Today I’ve been playing with Diffie-Hellman key exchange, using the 1024 Bit MODP key from RFC 4306 as the constants G and P in the algorithm described in the Wikipedia article. I’ve implemented this in Java using BigInteger, in code that compiles using GWT to compile to Javascript, in order to secure a conversation between a web front end and a server back end. The resulting key generated by the Diffie-Hellman exchange is used to seed a Blowfish encryption scheme which also compiles to GWT; packets are thus encoded using Blowfish and the shared secret from a DH exchange, then sent wrapped in JSON using Base64 encoding.

And just now I got the whole thing to work: I know have secure packets between a web client and a web server back-end.

That is the sort of stuff that makes me happy.

Spent a bunch of time optimizing the SCBigInteger class on iOS to speed up RSA encryption/decryption and key generation in SecureChat. I’ve gotten a 30% increase in speed, which I suppose isn’t too bad, though it appears the Java implementation is still faster. And that makes me wonder what Java is doing.

Check out the latest at GitHub.

Once you have the infrastructure for secure chatting between clients, expanding it to handle more than just text is a matter of encoding.

And so I’ve extended the client to allow sending and receiving photographs. Securely.

A new version has been pushed to the master branch of GitHub.

The interesting part about all this is learning the limitations of encryption using an RSA public/private key architecture.

The upside: unless the encryption key is generated on your device and shared using a secure mechanism (such as public/private key architecture), your protocol is not secure. Sure, your specifications may claim that the server-generated encryption key used by the clients is not stored on the server after it is generated–but we only have your promise.

RSA public/private key encryption, however, is computationally expensive. Even on Android, where the BigInteger implementation has been seriously optimized over my first pass attempt at building my own BigInteger code, encrypting and decrypting an image can be quite costly. It’s why, I suspect, most commercial applications use a symmetric encryption mechanism–because most symmetric encryption systems are significantly faster (as they involve bit-wise operations rather than calculating modulus products on large integers.

Which is why I’ll be focusing my attention on the iOS implementation of BigInteger.

But even on Android, decrypting a message using a 1024 bit RSA key can be acceptably fast enough, especially if encryption security is more important to you than efficiency.

In practice I can see using something like Diffie-Hellman to mediate exchanges between two devices. Nothing behind the mathematics of that protocol require the protocol to be completed in one session; there is no reason why the server couldn’t store the first part of the exchange (the value A = g^a mod p) on the server, so that later another client B couldn’t then complete the exchange. It implies each device stores the shared secret of all the devices it is communicating with–but with today’s modern devices, storing a thousand shared secrets doesn’t represent a lot of memory.

It may also be possible to use a variation of Diffie-Hellman in conjunction with a symmetric encryption algorithm (perhaps by using the shared secret as a key to such an encryption scheme).

What’s interesting about GitHub is that it’s public. Including the develop branch, where I’m in the process of building the Android version of a SecureChat client.

It’s kinda weird to see your incremental changes and bug fixes so publicly revealed.

The Apple v FBI clash left a bitter taste in my mouth. Not just because the FBI wants to punch holes in Apple’s security for their own benefit; at some level this is just a natural reaction of an investigative agency whose goal is to build cases against terrorists and to stop terrorism before it happens.

What left the bitter taste in my mouth were the pundits who claimed Apple was committing treason. What left the bitter taste were the politicians and political candidates who kept saying “let’s open the hole, and deal with the consequences later”–meaning they were simply not willing to look at the issue.

But what really left the bitter taste in my mouth was the presumption that somehow encryption is the property of large corporations and large governments–and even those on the far right sounded a lot like socialists when they demanded the two cooperate to make our world a safer place.

That really bothered me–because cryptography is not the exclusive domain of large corporations and large governments.

Which is why I put together SecureChat, an open source Java server/iOS client which provides end-to-end RSA encryption of messages.

This perhaps isn’t the best way to provide end-to-end encryption; certainly there are undoubtedly holes that in the next few months those who look at this code may find.

But my point was to demonstrate a couple of things:

Encryption is not the exclusive domain of a handful of large corporations and government agencies. Working from first principles I built an RSA encryption engine from scratch–even going so far as to bypass Apple’s built-in security classes (except for their SecureRandom function–but that could also be replaced), on the presumption that a future administration forces Apple to open back doors in their built-in encryption classes.

Please note I do not believe this will come to pass, and I believe Apple has security as a primary goal. This is more of a what if? exercise.

This is a demonstration of what one motivated developer can do in the span of a couple of months part-time work. If I can do it, undoubtedly there are others who have also done this.

The design provides complete end-to-end encryption of messages from device to device; only encrypted messages exist on the back-end server. Further, old messages are deleted as they are delivered; this prevents a record of messages from accumulating on the server. The design also keeps messages encrypted on the device; while messages are stored in SQLite (and could be easily scraped), messages can only be decrypted using the RSA key kept in an encrypted keystore that requires a correct passcode to be entered in the app. And the checksum used to determine if the keystore was correctly decrypted uses a CRC-8 checksum–a deliberate design which (for a 4 digit passcode) means someone randomly picking passcodes is 37 times more likely to destructively decode the keystore (and lose the private RSA key).

SecureChat is now hosted on GitHub, and is open sourced using the GNU GPL.