Monthly Archives: November 2017

Book Review – Applied Cryptography Part I And II – Bruce Schneier

Uncategorized,

This book has been, without a doubt, crucial in aiding my understanding of cryptosystems and why things are the way they are, and how do these cryptic crypto algorithms even work. If you are interested in learning how to develop software that are ‘correct’ and secure, then this is a great book to understand what are the primitives of information security, what algorithms already exist and which ones to use in what scenario.

So the motivation to pursue a thorough understanding of cryptography and to gain the ability and knowledge required to make a secure cryptosystem came sometime after college ended, when I and Kunal were working on a terminal chat application that would support end-to-end encryption. At that time, I hardly knew what I had gotten myself into (which is similar to a lot of things in my life), as the application development part seemed very simple. We got done with the application part, terminal app and the backend, and then came the encryption part, and that is when the knowledge about existing techniques and understanding of basic crypto primitives fell short. And that is when I started reading about cryptography and stumbled upon this book.

Although they seemed daunting at first, both the books are very accommodating for a wide range of audience, right from someone like me who barely knew what a block cipher is, to the more experienced folks who might understand all of the mathematics given in the book in the first go. While not very complex (school grade algebra with addition, multiplication, modulus and xor operations), it takes a little effort (read: re-reading a topic 3 times, sometimes more) to actually get what’s happening, why an operation is being performed, for example.

While reading the first book, remember that it was written when I was literally a year old, in 1996. Hence, although the engineering principles and general recommendation is still valid, you need to keep in mind that the algorithms recommended in that book are not valid (as attacks are found for many of them and DES has officially retired), and that is corrected in the second edition of the book. In any case, studying the DES algorithm in detail should be a delight for any crypto nerd, regardless of its practical value.

The second version is more up to date, and for some reason I was more comfortable reading it than the first one. It might be because I knew a little more while reading the second edition, which can be a good tip: If you’re serious about understanding cryptography from an engineering standpoint, skim over the first book and make a note of everything that you find useful and interesting, and do a more detailed study of the second edition of the book.

What I found nice about the books is, they really are ‘applied’ books. It isn’t all mathematics and algorithms, but the actual merger of these algorithms into real world systems. In the real world, cryptography and cryptosystems don’t exist in isolation, but play a small role in the larger scheme of things. Breaking a cryptosystem is usually reserved for the more resourceful adversary, and while these (well established and peer reviewed) cryptographic primitives rarely fail, when they do, it is catastrophic. The computational infeasibility makes the theoretical aspect of cryptography very secure. Problems appear when they are implemented, and that is where the bugs start to show up. Then there is the software development methodology which usually prioritises deadlines and features above security. There is a section dedicated to explaining what ‘trust’ is, how it forms such an important aspect of information security and secure software development. Overall, the book is quite interesting to read, and the content is without a doubt top quality, which is what one expects from Schneier.

In closing, I’d recommend this book if you are into security and wouldn’t mind knowing the details of some of the fundamental algorithms that make the digital revolution possible. Thank you for reading.

Book Review – Responsive Web Design By Ethan Marcotte

Uncategorized,

It has been a while since my last book review post here. Not that I stopped reading, but I kinda stopped reading non-tech things lately, and hence, there were no new posts. But today, it hit me that I can (and should, given this is a personal diary) write about pretty much anything that I read and find interesting. So here it is, a book by Ethan Marcotte, which I first read about a year and a half ago and then re-read it before a month or so. Responsive web design wasn’t (and still isn’t) my piece of cake. Heck, web design was something totally alien to me in the first place.

The happy realization that being able to set up websites (read: wordpress/joomla blogs on a nix server) doesn’t make one a web developer, much less a designer, came about two years ago, when Dhananjay, a college senior of mine, was contacted by one of his contacts who was looking for a frontend developer. The task was supposed to take a couple of hours at max. Knowing that I did things around the web, Dhananjay outsourced that opportunity to me.

That was one incident that still gives me chills, and I wrote a bit on that earlier. Not only because I realized how horrible I was with frontend and design, but also because I didn’t have the slightest clue about deadlines, how to and how much to work, and how to deal with things that are out of my control. It was a design heavy page, and I had a depth first approach of dealing with things. The end result was that a few pieces took up 80% of my 5 days of work (easily worked for over 70 hours), and the end result was nothing short of a design disaster. That one incident has taught me a lot, especially about how real work happens.

I guess it was then when I had read Ethan’s book for the first time. I believe it wasn’t as much for learning as it was to put on some burnol on my bruised ego. But nevertheless, even then the book had given me much insights about what web designing actually is, and why it isn’t very different from what I had been doing all along, it just requires thinking in a different mindset.

Fast forward to June this year, I interviewed at a couple of places for the role of a web developer. I was expecting a role on the backend, maybe a nodejs or python based job, but instead, I got a job as a ReactJS engineer. Yeah, a frontend engineer. As difficult as it was for me to digest it, I had to accept the fact that I will be dealing with a lot of CSS now. I had to up my design game, or it was game over, and I seriously didn’t want to screw as bad as I did two year ago. My friend Kunal was kind enough to lend me his Head First HTML & CSS book which I am currently reading. But apart from the raw knowledge, it was the mindset that I required immediately, the mindset of a frontend developer, and for that, I picked up Responsive Web Design once again.

Shall we start with the review, Plis?

Sure. The author starts by talking about architecture, responsive architecture in particular, about artists and their canvases. Responsive architecture is all around us, from window panes that allow variable amounts of light depending upon the time of the day, to modern home equipments. The author then talks about the usual restrictions in print media, and how web designers are fighting hard to recreate those restrictions on our browsers. We do not have to do that. The canvas of a web designer is inherently responsive. It isn’t a flaw, it is a freedom.

The author makes sure that reading this book won’t feel like the usual wall-of-text-hitting-your-face-with-technical-jargon experience. The book feels like a spiritual exercise, as if web designing is an art waiting to be discovered by an engineer who always saw it like a soul dead practice of giving random attributes to random elements and praying to the Gods of DOM that it looks just decent enough to pass the QA. I was really immersed into the book as I was reading it, and hoping that it lasts forever, which it obviously didn’t. The book is not long, and is divided into three sections; The responsive grid, Responsive images and Media queries. After reading this book, you’ll look at hardcoded ‘px’ values as if they were taboo in your (code) culture. The author shows how simple calculations can turn all the zombie pixel measurements into the more lively ’em’s and ‘rem’s, which are, of course, responsive.

A good article that the author strongly recommends is a blog post that was written some 17 years ago from now, but still is as relevant today as it was then. The post is called A Dao of Web Design, and it falls into the must-reads category for me. To give you a taste of the article, read the following quote.

The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.“

Beautiful, isn’t it? Suddenly, web design isn’t something that you do when you’ve done everything you could do to avoid it in the first place. True, writing CSS by hand is time consuming, working and supporting multiple browsers and display sizes is stressful to say the least, and most of the time, you’re better off using a ready-made solution like Bootstrap or Semantic, but once in a while, it is good to think about web as your canvas and think of yourself as an artist trying to fill in beautiful colors into the canvas. Now whenever I think about the different ways in which my web application is supposed to look on different screens, I remind myself that it isn’t a ‘restriction’ that the app needs to look that way on that screen. Rather, it is a freedom that the app can look the way it needs to look in order to be the most comfortable version of itself for that particular reader. Ever seen a person struggling with folding a newspaper on a busy bus stop, or a cautious women carrying a large piece of art in her arms, making sure she doesn’t bend it, yes, that is exactly what a restriction, a limitation looks like. Thankfully, our dearest web doesn’t have that one. Thank you for reading.

Tinkering With OBD-II Port

Uncategorized,

I’ve been seeing people hook up their computers to their cars from quite some time. It is a common sight if you watch any motorsport event on television, where technicians are seen working on their laptops that is connected via a cable to the car or bike. I found it quite fascinating. “What interesting tweaks must they be making to that machine with that computer!” I thought. The idea of tweaking a machine to improve it’s characteristics wasn’t new to me. Overclocking is nothing new. But obviously, since I saw all those professionals do it, I assumed there was no way for such an interface to exist on our everyday road vehicles.

And I was wrong. I discovered that, by law, it was necessary for all cars to have a diagnostics port, called the On-Board Diagnostics port. The latest revision for that port is v2 or OBD-II, and all cars manufactured after 1996 should have one. Also, sometimes, the automotive Youtubers I followed showed various stats on the screens such a the engine rpm, throttle position, boost pressure etc. So that implied there exists a way to extract those stats out of the vehicle’s ECU. Interesting. A quick Google search for “odb scanners” revealed that they’re not very expensive either (with cheap clones available for as low as INR 300, USD 5 or even lower). After researching a bit, I learned that there was loads of data that came out of that little adapter, and that great Android applications (like Torque and DashCommand) exist which spit out the data into beautiful dials and graphs (like the ones on the Nissan GTR ♥) I was awestruck. What more can a nerd ask for!

All this happened a couple of months ago. I knew I needed to get one of those. I waited a couple of months and finally ordered it earlier this month. The first challenge was to find the OBD port. Unlike some other cars, Zacky’s OBD port was hidden behind the fuse box cover, the adapter had to go inside there. I managed to access the port without opening the fuse box and problem solved! Plugged in the adapter, paired with with my phone and it started sending data. That was one of the best feelings ever!

Some of the data it sent that I found particularly interesting to read was

  1. Boost pressure from the turbocharger
  2. Engine RPM
  3. Coolant temperature
  4. Engine load
  5. Error codes and provision to reset them
  6. Horse power, torque, acceleration and other such “calculated” data by combining sensor data with phone’s sensors like GPS and accelerometer and known parameters (like vehicle weight, engine displacement etc)
  7. and loads of other cool stuff

Note that the available sensor list varies from manufacturer to manufacturer, so keep that in mind. But even with the most basic, the experience is fun. It’s like opening task manager on your computer for the first time. Wow, so I can actually run this h4ck3r stuff, right?

Interesting Learnings

– Negative boost pressure When you start the car and drive it normally, you’ll notice that the boost pressure gauge will read negative (technically, not pressure but vacuum). Only when driving hard (shifting late, for example), will you notice the boost pressure rising. I thought it was some erroneous data from the sensor so I read up a bit. Turns out, at high rpm, the turbo forces the air fuel mixture into the cylinders. But what happens when the turbo is running too slow for compressing air? It simply works as a naturally aspirated engine and sucks in air during the intake stroke. THAT sucking part explains the vacuum. Cool!

– Driving modes So Zacky featured this thing called driving modes. Putting her on “Sports” made the throttle more responsive but reduced fuel economy while putting her in “Eco” did the exact opposite. Now I could’ve told you that this isn’t just marketing and if you test it out, you can even feel a noticeable difference, but that was all I knew. Now, after driving for a while with the boost pressure gauge in front, I made this little observation. When in normal drive mode, the turbo does not spool over 4-6psi boost. But as soon as I go ‘sport’, the turbo goes well over 10psi, even 12 if the sensor is to be believed, which is pretty fantastic.

– A better understanding of the relationship between torque and horsepower, and what each number actually implies. Yes, power is work done per unit time, but what exactly does that feel like. Why do diesels have same horsepower figures even after having loads of torque. It gets really clear once you see the torque, the rpm and the (thus calculated) horsepower figures side-by-side.

– Torque curve So there’s this thing called a torque curve of an engine, which is just a curve with torque on one axis and RPM on the other. For an IC engine, the torque is not linear (as with electric motors), but a curve with a peak at some specific RPM (or RPM range, which is why a torque (or horsepower) figure is always accompanied by a RPM range), and tapering off at both the ends. To get the maximum acceleration, you have to keep this curve in mind when changing gears.

Now show me some kode!

Yeah, right. So while I was on all of that, I thought, why not study the protocol itself and try writing a little script to pull the raw data from the sensors out, just for fun. Right, but how? This thing is running on Bluetooth, and how do you sniff that. Is there something like Wireshark for bluetooth? Googling “Wireshark for bluetooth” reveals that Wireshark is the “Wireshark for bluetooth”. Damn!

But before wireshark could sniff, I needed to get thing thing connected to my laptop. That’s pretty straightforward. After having it running at /dev/rfcomm0, fire up Wireshark and keep it listening on Bluetooth interface.

Okay, pause. Here’s the funny part. The above text was written some 4 months ago. Then I had to do a lot of physical work to take my laptop into Zacky and do all the research/coding from there. I remember going out at least 3 times, but for some weird reason, never bothered to finish writing this article. I’m putting this out right now so that I will remember to write the part-II for it during the next weekend. Stay tuned.