ELI5 – Message Authentication Code

Uncategorized,

You need some urgent cash to buy today’s lunch. You throw a paper chit at your colleague, “Hey, I need you to transfer 100 bucks in my account number 10022, urgent”. Eve, a bad actor in your office, intercepts the chit, changes the 10022 to 10033, which is her account number, and forwards it to your friend. Your friend, intending to help you, transfers the amount and you both get duped!

The Problem

The above is not a overly rare event, far from it. Such attacks happen all the time on the internet, and the reason is the lack of (cryptographic) authenticity built into core internet protocols. We learned in Authenticated Encryption that confidentiality alone doesn’t mean anything if the attacker can perform active attacks on your communication channel (just like Eve could). We need something better. We need MACs.

Message Authentication Code

As the name gives away, a MAC is an authentication code associated with a message which verifies the integrity of the message and, assuming that the key is only known to you and the message’s sender, its authenticity. Just like with encryption, you give a MAC algorithm a message and a key, and it gives you a tag. This tag is unique to your message and the key pair, and an attacker shouldn’t be able to forge a valid tag for any random message of his choice even if he’s given an infinite number of ciphertext-tag pairs to analyze.


From Wikipedia’s MAC page

In concept, a MAC is similar to a hash function, such that given an arbitrary sized input, you get a fixed-sized output (digest) and this can be reproduced (‘verified’) on other machines as long as one can find the same hash function’s implementation. This is how your download manager ensures that the file it has downloaded from the internet is not broken, by calculating the hash digest and comparing it with the one the website claims. A MAC differs from a traditional hash function in that along with a message input, it also takes a key and as such, knowledge of the key as well as the underlying MAC algorithm is needed to verify (or create a new) a tag.

In fact, one of the most popular MAC algorithms is based on hash functions. The algorithm is called HMAC for Hash-based Message Authentication Code. It works by hashing key material with the message while taking preventive measures for popular attacks on hash functions such as length extension attacks. Any reasonable hash function can be used for the purpose of MAC’ing, including SHA-1 and SHA-256, (MD5 isn’t recommended).

Encryption of the underlying data is not a prerequisite for using MAC, and they can be used irrespective of whether the data being MAC’d needs confidentiality or not. Use MACs whenever data integrity is needed. One caveat to look out for; MAC algorithms by themselves do not prevent replay attacks.

Aside on Replay attacks: A replay attack may happen when, say, you owe Eve some money. You send a note with Eve for your bank saying, “Please give Eve Rs.100 from my account, Signed: Bob”. Now there’s nothing preventing Eve from being greedy and using that same note again some days later. This is prevented in the real world by making cheques unique and one-time use only. Similarly, ciphertexts must embed information (such as packet number, timestamp, session counter etc) that will expire once received and not let Eve re-send it at a later time.

Thank you for reading.

ELI5 – Authenticated Encryption

Uncategorized,

The core goals of cryptography and any application of cryptography are confidentiality, integrity, and authenticity. Let’s begin with a short one liner on each:

  • Confidentiality: No one should be able to read the contents of the message except the intended recipient.
  • Integrity: No one should be able to tamper with the message without going unnoticed.
  • Authenticity: The recipient should be able to confirm that the message indeed came from the sender.

There are other goals that we do not need to touch upon in this article, such as non-repudiation and plausible deniability.

The Problem

Now the problem with using just an encryption algorithm like AES with a non-authenticating mode like CBC is that anyone can change the ciphertext during transmission. And while you might think, “but the modified ciphertext, with high probability, will decrypt to something gibberish”, this isn’t the right argument because the recipient will have no way of knowing for sure, which is a problem, a huge one.

Secondly, there’s also no way of knowing if the message was sent by a person you’re expecting it from. It might have come from any middleman intercepting your network and you wouldn’t be able to tell a difference. And for this reason, encryption without authentication and integrity completely destroys the purpose of encryption. An example of this in the real world is when you see an error such as the following:


https://support.mozilla.org/en-US/kb/what-does-your-connection-is-not-secure-mean

While this can mean that the encryption mode used by the website is weak, more often than not, this means that the browser was able to establish a secure connection but the identity of the website is unknown. This defeats the purpose of encryption because even if the connection is secure, the fact that you don’t know if you’re receiving a message from your intended recipient or if the message hasn’t tampered with defeats the purpose of using cryptography.

Enter Authenticated Encryption

Authenticated encryption solves this problem by introducing authentication and integrity as freebies that you get when you use an authenticated encryption mode along with an encryption cipher such as AES. Examples of authenticated encryption modes include GCM and CCM. In fact, if you check the connection info of the site you’re reading this on (click the green icon and then select more info or something similar on chrome and firefox) and check the technical details part, you’ll see something like this, depending on your browser.


Yes, I’m the most active visitor of my blog

Here, AES_128_GCM is used for symmetric encryption of the content you exchange with the server with AES providing confidentiality and GCM providing authentication and integrity. SHA256 is used to authenticate the initial handshake and as a pseudo-random function (PRF).

In a nutshell, these authenticated encryptions usually take a message, encrypt it, then MAC the ciphertext (and IV) and then append the MAC to the ciphertext. This is called Encrypt-then-MAC. Now if the ciphertext is changed, the MAC won’t match and the receiver can easily discard such messages without having to touch the contents of ciphertext. There are other variations to this method, namely MAC-then-Encrypt and MAC-and-Encrypt, with benefits of going with each although most experts recommend doing Encrypt-then-MAC.



From wikipedia page on authenticated encryption. This is Encrypt-then-MAC

As you can imagine, this can be easily done manually (and until some years ago, it was mostly done by developers). But since it is easier (and much more secure) to standardize such modes and leave the secure implementation part to the experts, these ‘readymade’ modes have picked up wide adoption and as you saw, you’re currently using GCM to ensure confidentiality, integrity, and authenticity of this very line. Thank you for reading!

Advice From An Old Programmer – Zed Shaw

Uncategorized,

The first article on my site is about me starting with Python. That was four years ago and around that time I had read this book called ‘Learn Python The Hard Way’. I really, really liked it. It was amongst one of those earlier pieces of memories that I’d probably never forget for my entire life, similar to the kind of impact reading The Hacker Manifesto and Sir Eric Raymond’s ‘How To Become A Hacker’ had on me.

I decided to give the Python 3 edition of Learn Python The Hard Way a read. The last section of the book is titled ‘Advice from an old programmer’ and in that, Zed Shaw shares with us some of his zoomed-out thoughts on programming and the career one makes out of it. Although it is very subjective and very blunt, just like the rest of the book (and I really like the rawness in his writing), for me personally it refreshed the old memories associated with the book.

I had read this exact chapter in the previous edition, but this time it made so much more sense. And not just this chapter, but in the entire book, the subtle pieces of well targeted humor and strong opinions held by the author were something of a delight to read even if you didn’t believe in the exact same thing.

I’m copy pasting the section of that book that I think I’ll come back to read re-read again and again. I think many of you will appreciate it as well.

Advice From An Old Programmer

You’ve finished this book and have decided to continue with programming. Maybe it will be a career for you, or maybe it will be a hobby. You’ll need some advice to make sure you continue on the right path and get the most enjoyment out of your newly chosen activity.

I’ve been programming for a very long time. So long that it’s incredibly boring to me. At the time that I wrote this book, I knew about 20 programming languages and could learn new ones in about a day to a week depending on how weird they were. Eventually, though, this just became boring and couldn’t hold my interest anymore. This doesn’t mean I think programming is boring, or that you will think it’s boring, only that I find it uninteresting at this point in my journey.

What I discovered after this journey of learning is that it’s not the languages that matter but what you do
with them. Actually, I always knew that, but I’d get distracted by the languages and forget it periodically.
Now I never forget it, and neither should you.

Which programming language you learn and use doesn’t matter. Do not get sucked into the religion
surrounding programming languages as that will only blind you to their true purpose of being your tool
for doing interesting things.

Programming as an intellectual activity is the only art form that allows you to create interactive art. You
can create projects that other people can play with, and you can talk to them indirectly. No other art form
is quite this interactive. Movies flow to the audience in one direction. Paintings do not move. Code goes
both ways.

Programming as a profession is only moderately interesting. It can be a good job, but you could make
about the same money and be happier running a fast food joint. You’re much better off using code as
your secret weapon in another profession.

People who can code in the world of technology companies are a dime a dozen and get no respect.
People who can code in biology, medicine, government, sociology, physics, history, and mathematics
are respected and can do amazing things to advance those disciplines.

Of course, all of this advice is pointless. If you liked learning to write software with this book, you should try
to use it to improve your life any way you can. Go out and explore this weird, wonderful, new intellectual
pursuit that barely anyone in the last 50 years has been able to explore. Might as well enjoy it while you
can.

Finally, I’ll say that learning to create software changes you and makes you different. Not better or
worse, just different. You may find that people treat you harshly because you can create software, maybe
using words like “nerd.” Maybe you’ll find that because you can dissect their logic they hate arguing
with you. You may even find that simply knowing how a computer works makes you annoying and weird
to them.

To this I have just one piece of advice: they can go to hell. The world needs more weird people who know
how things work and who love to figure it all out. When they treat you like this, just remember that this is
your journey, not theirs. Being different is not a crime, and people who tell you it is are just jealous that
you’ve picked up a skill they never in their wildest dreams could acquire.
You can code.

They cannot. That is pretty damn cool.

Beautiful, isn’t it? Thank you for reading!

Blog Anniversary – Four Amazing Years

Uncategorized

So it is the time of the year when my domain registrar pings notifying me of domain expiration and reminds me of all the adventures I’ve had with this domain, this blog. And after contemplating for some time, the inner writer whispers, ‘iss awsar par ek post toh banta hai’.

Before this one, I had a couple of other blogs. The goal with those blogs was making money (and learning and knowledge sharing, but honestly, I wanted to taste money). There’s a difference between writing for yourself and writing for a wider, more general audience while thinking about SEO and praying to the gods at Google to increase your PR. After a while, finding no success and realizing that I wasn’t enjoying it that much (you know you’re obsessed with traffic and pageviews when you open Google Analytics every 30 minutes!), I gave up on that and started this personal blog, convincing myself that traffic oriented blogging isn’t my piece of cake. Four years ago, in that article, I wrote this, not knowing how it will turn out.

So, you may ask, what is this thing? The thing you are reading this on! Isn’t it a blog?

Yes it surely it, but I feel it is more than a blog. It is a diary. I don’t really care if no one reads this blog, and as a result, if you look at the source code, there is no analytics code installed. It simply means I never know how many people visit this blog, if at all they do. All I know is I enjoy writing here far more that what I did writing on a blog where people actually came to read stuff.

I’m happy that it was a successful experiment. Writing without the lure of traffic and affiliate commission is much more liberating, and you can be extremely honest about whatever you like. Most importantly, this place has become sort of a hangout for me, a diary and a place to reflect. I sometimes simply read the old articles to find spelling and grammatical errors, haha. There are so many of them, but I correct none. Correcting them would be slowly erasing the past me, so let that stay as it is. It gives me a nice perspective on how my interests, my hobbies and simpler things like the way I construct sentences, are changing. And change is good.

Thank you for reading.

Time & Hash Based One Time Passwords

Uncategorized

Ever wondered how two factor authentication apps works? I certainly did. One could just guess how SMS based tokens work, that’s simple (although they shouldn’t be used as per guidelines from NIST). But what about TOTP or Time based One Time Password, the ones in which you scan a QR code and the OTP generator app (like freeOTP and andOTP) gives you a new six digit token every 30 seconds or so?

I was, for quite some time, under the (very misinformed) impression that web servers which implement this method of 2FA expose an API and, by means of the QR code, give you the endpoint with some token and then the OTP generator app polls the server and gets a new ephemeral password which the user enters in the application. Straight forward, but plain wrong.

The belief was challenged when I noticed that the OTP generator app works irrespective of network connection, even if both devices are offline (that is, when working on localhost server). HOW? I dug further and I learned some very interesting things, some of which I wanted to write here.

The Name, Dude

Time based One Time Password, the name itself gives enough clue to guess that it uses time, and as such is independent of inter-communication as long as the two systems are in time-sync. But an adversary can be assumed to be in time-sync as well, right? Yes, that’s where we bring in the secret (a randomly generated token) which is embedded in the QR code that you scan with your smartphone app. So we have the time which is in sync and we’ve established a way of transferring the secret from the server to the client. Turns out, that’s all the data we need to keep generating secrets independently on the client and server side, completely offline once the initial secret sharing happens.

Basic OTP Algorithm

  function generate_otp(secret, counter) {
    h = hmac(key=secret, message=counter, algorithm=sha1)
    offset = get_last_four_bits(h)
    pre_opt = get_32_bits_starting_from_offset(h)
    otp = get_desired_number_of_chars(pre_otp, N)
  }

  function get_totp(secret) {
    counter = epoch / 30
    return generate_otp(secret, counter)
  }

  global counter; // get from database
  function get_hotp(secret) {
    return generate_otp(secret, counter)
  }

The basic OTP algorithm (both time and hash based) accept a secret and a counter value. Combining current time and the secret, a new 6 (or N) digit token is generated every 30 (or Ti) seconds. They differ in what the counter value supplied to the algorithm.

  • TOTP: take the number of times the interval Ti can be fitted in the total number of seconds since epoch. Which is just a weird way of saying that the interval is the quotient when you divide the seconds_since_epoch number by the interval duration (Ti).
  • HOTP: take the current counter stored persistently and use that. After use, increment the counter in the database.

After establishing the counter value, the rest of the steps remain the same in both the cases.

  • Compute HMAC value of message Ti and key secret, get the hex digest
  • The last 4 bits (last digit in hex) is stored as offset
  • Starting from offsetth bit, take 32 bits (8 hex digits) and discard the first bit (xor with 7ffffffff. This works because f = 1111 and 7 = 0111, so &’ing with 7 (0111) is equal to switching off the first bit)
  • Convert the 32 bits hex to int, then take the least significant 6 bits (or N depending on requirement), and that is your OTP
  • ?? Profit!

Security Consideration

The entire security of the OTP lies in the secrecy of the initial secret. If that’s compromised, an attacker can easily generate as many OTPs as she wishes. Also, given the keyspace of the OTP, and also that many servers are designed to accept counter+1 and counter-1 OTPs, securing the system against bruteforce is a most.

One important aspect of these 2FA mechanisms is that losing your 2FA device means losing your account. This is especially the case with services like ProtonMail where the password is used to decrypt client data.

Naive Python Implementation

Given how simple this algorithm was, I tried to implement it. The core algorithm was literally less than five lines of python code. Here’s a naive implementation of the same, and while it seems to work, I’d not use it anywhere.

Thank you for reading! PS Python noob, please don’t judge! 😛

GDPR Humor

Uncategorized

Curating a list humorous content related to GDPR.

xkcd #1998

GDPR Hall Of Shame: https://gdprhallofshame.com/

In midst of outburst of privacy policy updates from random companies reminding you of how much they care about your privacy, mozilla dropped this gem.

Ghostery sent 500 users email updating them about changes in privacy policy and forgot to use the BCC feature.

Found this on reddit r/Europe

This on r/ProgrammerHumor

Thank you for reading!

Reusing An Old Laptop’s LCD Panel

Uncategorized,

A month ago, my manager from LaughGuru gave me his old non-functional laptop. It was a six year old Dell Inspiron 15R 5520 notebook computer with 2GB ram, third-gen Intel i5 and a 500GB hard disk and weighted almost as much as Misty and my new Thinkpad combined. I couldn’t get the motherboard to boot up so I decided to take it apart (and given the condition of the laptop it made little sense to repair it).

I’ve found some really useful things inside the laptop. The two gig ram chip and the 500 gigs hard disk now sits on another water damaged laptop that my friend gave me a week ago and powers it flawlessly. The CD drive will come in handy someday as an external disk drive. I planned to use the display as an external monitor for my laptop, and that turned out to be a DIY project in itself.

Enter LVDS Connectors

So I isolated the LCD and looked very carefully for any hints on what sort of connector was that dangling from behind the panel. It had the word LVDS on it. Some Internet research later, things became clear. As alien as it sounds, LVDS or Low-voltage differential signaling is a standard that is used for high-speed transfers using very low power. For me, it simply meant that there’s no straightforward way of plugging the HDMI or VGA cable from my laptop into the bare LCD panel and start using it.

Unfortunately, there’s also no easy way of using the laptop’s motherboard logic to make the LCD panel work. Searching for a solution made it clear that LCD controller kit is what needs to be used. It is important that the exact spec of the LCD panel is known, as the kits are only compatible with a small range of panels. It might be difficult if the LCD was never working in your possession, as in my case, but this nice website called Panelook makes it easy to get the detailed spec of the panel from just the serial number. Things to look at are the resolution and the backlight type. The resolution needs to be an exact match and the backlight type is needed to judge if you’ll need an inverter with your controller kit. Mine was a WLED panel so no external power source or inverter needed. The next step is searching the serial number on ebay and other local hobby sites. I found a nice kit on Banggood and decided to order it.

Putting It All Together

Interfacing was simple, and there are nice videos on the topic on youtube. There’s the LVDS connector that goes into your LCD panel. Then there’s the controls board that needs to be plugged into the main board. The controls board also has an IR receiver for remote control and can be used to control brightness, contrast, sharpness etc of the panel.

The board itself supported inputs through AV connector, HDMI, and VGA. It operates on 12 volts and 4 amps and luckily I had a 5 amps supply with me, so no extra expenditure there. I had to borrow VGA cable from a friend though as my laptop only has VGA and no HDMI.

I used an old Tupperware tiffin box as the LCD’s stand to keep the delicate LVDS cables safe and away from physical contact with anything. To avoid physical damage to the panel, I’ve used the stock display cover of the laptop (the top half) as it was. The added benefit of using the stock plastic cover was that I could drill holes and fix the controller board on the back of the panel like an all in one PC (I could’ve literally made it an all-in-one PC by docking my raspberry pi back there as well, haha). Overall, I was very happy with the result, and as I write this, I have my editor on my primary screen and the browser on the extended display. Dual monitors at home achievement unlocked!




Hope you found this article useful. Thank you for reading!

Banggood’s India Direct Mail Shipping

Uncategorized,

Here’s some great news for all you hobby electronics enthusiasts who drool at the sight of cheap stuff on Banggood and AliExpress, but upon rethinking about the time it takes them to ship something, give up on the prospect of buying it. I’m not a hobby electronics person, but after shopping some three-four times in the past year through sites like AliExpress and Banggood, I was convinced that the wait is definitely not worth the discount that you get, because the shipping time is usually around 40-50 days. Yes, nearly two months it took for my speaker amplifier to reach me. And then some others that never reached.

But it seems like those are the days of the past because two weeks ago when I reluctantly surfed Banggood for a LCD controller board that I couldn’t find on Ebay or other Indian sites, I saw a new method of shipping called ‘India Direct Mail’ (not really new, it has been around since the last quarter of 2017), and it promised to ship in 8-16 days at almost no additional cost.

I really found it hard to believe but decided to take risk and order as I didn’t have much to lose (except for some 1200 rupees). It turned out to be true. Today, I received my LCD controller board, just 12 days after ordering. I feel this is reasonable, especially given that you won’t get it for at least double that here in India, if at all you do get it. This is great stuff and I’ll definitely be using this more in the future.

Encrypted Backups Using Duplicity & Google Cloud Storage

Uncategorized,

I came across this utility called Duplicity couple of days ago and found it to be very useful. I’ll use this little post to write about what it is and how can it be used to create encrypted backups of not so frequently accessed data on servers that you do not trust. If you only care about the tool, jump to the Usage section.

Use Case

I was working on a little project that involved setting RAID 1 using some spare 500 gig drives and Raspberry Pi as the raid controller. My problem was that I only had two drives, say A and B, and I needed to backup the data on one of the drives (say A) before setting up the raid in case something breaks. I tried to use a friend’s external hard disk but didn’t succeed getting it to work. Finally, I did find another hard disk (say C) in the ‘trash’ laptop a friend of mine gave me. So now I could get the data off the primary disk (A) onto this new disk (C), and I did manage to succeed in that. But this exposed a deeper question of how am I supposed to take care of around 400 GB of backup data, and is having a single copy of it even safe. Of course not.

If you remember my NextCloud solution on DigitalOcean, that worked great as a lightweight cloud, for easy backups of current set of camera pictures and maybe contacts and such. But when it comes to archiving data, DigitalOcean would get a bit too expensive (~USD 10 for 100GB and so on with their block storage). However, their object store was relatively cheap and costed around USD 5 for 250GB of data per month. I needed something like this.

The second problem was speed of upload. I own a modest 2.5Mbps connection, so uploading data off my Internet was out of question. Since I had Google Peering, I could make use of that. I looked up Google Cloud’s solutions and found Google Cloud Storage, which was AWS S3 like object store. They also offered USD 300 free credits to begin with for a year, so I decided to test it out. It worked great, and I got transfer speeds in excess of 24Mbps, which is what Google Peering does.

The last hurdle was finding an automated script to manage sync. I was already a huge fan of rsync and was searching for a way of doing incremental backups (although not strictly required for archiving data) while doing some sort of encryption as well. That is where Duplicity came in.

Enter Duplicity

Duplicity is a tool that uses rsync algorithm for incremental bandwidth efficient backups that are compressed into tarballs and encrypted with GPG. The tool supports a wide range of servers and protocols, and will work with anything from AWS S3, Google Drive/Cloud to WebDAV or plain SSH. In the typical *nix fashion, it does a little thing well and the use cases are only limited to your creativity.

Usage

The setup requires you to install Google Cloud SDK and Python 2’s Boto that will serve as an interface to Google Cloud Storage. Then go ahead, sign up with Google Cloud if you haven’t already and set up a new cloud storage project (say my_backup). Make sure you enable Interoperable Access in /project/settings/interoperability and create a new access-key/secret-key pair. You’ll need to copy these into the ~/.boto config file under gs_access_key_id and gs_secret_access_key respectively.

The last step is to test drive the entire setup. Create a directory with a couple of sample files (probably a slightly large video file as well), and run duplicity with the following command.

$ duplicity ~/backup_directory gs://my_backup

Enter the password when prompted. If all goes well, you’ll see some transfer stats after the command finishes execution (time taken depending on your transfer speed etc), and in your GC console under your storage project’s browser, you’ll see something like in the following image (of course, not a hundred difftars like mine. I’m in the process of backing up my archive).

If you do, then congrats! Those are the encrypted tar volumes of your data. Now just to be sure, make a little change in one of the files and run that command again. You’ll see that this time it takes almost no time, and if you refresh the GC storage’s browser, you’ll see couple of new files over there. Those are I believe the diff files.



To recover the archived files, just do a reverse of the command above and you’ll all your files magically in the ~/backup_directory (after you enter the correct password, that is).

$ duplicity gs://my_backup ~/backup_directory

The next step after the initial backup would to be to run this command every hour or so, so that regular backups of our directory keeps happening. I haven’t tested it yet but something like

0 * * * *  duplicity /home/abhishek/backup_dir gs://backup_dir >> /dev/null

should do the trick.

If you found this article interesting, make sure you read up more about Duplicity on their webpage and in the man pages. There are tonnes of config options. Thank you for reading!

The LaughGuru Experience

Uncategorized

So today is my last day here at LaughGuru, my first company. I might still be working with them after this point, but most of the active development would stop and the role of the tech-team will be reduced to just maintenance of existing systems and the like. My plans for the time after my dose of Laughter Guru is still away from total clarity, so won’t really write them here. What I do have some clarity on is how I spent the three quarters of my last year as, and that is what I’ll write on in this little post.

The journey to LaughGuru

Around this time last year, my final sems were in progress. I had no job in hand (that was a thing in the final year, everyone asked everyone else if they had a job. I used to called myself berozgaar, and that is what I’ll call myself from tomorrow). I had some direction, but nothing in particular. My friend Abhishek was my gateway to the world of startups, because I knew of none and planning the future wasn’t my strongest game. So borrowing his experience and startup wisdom, I made a little list of companies that I could apply to and look forward to spending some good time learning and building software and making new friends. Those were literally my only criteria when selecting the organizations that I was going to write to. One of them was LaughGuru, the company Abhishek was then working for.

I wrote an email to the co-founder of the company sometime in mid-May. The communication was initiated through Abhishek, and I was effectively an ’employee referred’ candidate. The conversation went well, and I learned that this person is also the product and engineering manager at the company. He seemed nice. I learned that I’ll be working with ReactJS and the formal interview will start sometime after my exams were done. In the meanwhile, I also spoke with other companies that I knew of then, and most of the experience was pleasant. The people I spoke to were interesting, were open to the idea of accepting a college fresher into their teams and in general open to helping. While the entire experience was intimidating, and the idea of talking about yourself and your ‘achievements’ in front of (some very successful) people was not something I was very comfortable with (but yeah, on this blog it is okay :P), in hindsight it was a great experience into the startup world. Most importantly, I learned that getting a job at some startup is very easy. Getting a good job, at some good startup? That’s the trick.

After my exams and after some really interesting adventures on Indian roads, I got back to the business of adulthood. The company gave me an assignment, which was an interactive card game. The challenging bit was that it had to be implemented in ReactJS that I had little idea about until then. I made a decent looking version of it in around 4 days and the call for interview round 1 came sometime after that. I’m not sure about the type of that interview, but there was a mix of questions, technical and the others. It lasted some two-two and a half hours, and went well. I felt comfortable with the team, and while they seemed like nice people in general, it definitely didn’t seem like a place full of elite programmers working extra hard to bring something of a dream to reality (that is how I naively imagined startups to be like).

A week later, my second on-site interview round was conducted. This time the frontend lead was present, with whom I would be working if I get selected. The second round was much more casual than the first, and not many technical questions were asked. We spoke about my personal projects a bit and then for sometime about the technical assignment. It didn’t last very long, and the casualness of round two meant either very good or very bad news. Couple of days later, I received a call from the company and they had decided to offer me a job. I was happy. We negotiated on the offer a bit, and then I bought a day’s time to think. Not just think but I also had other interviews in progress that I had to close if I was going to take the offer up. Did that and I accepted LaughGuru’s offer. The offer date was not announced then, but I was okay with it. It was supposed to be, as some people described it, my last big vacation (which turned out to not be very true, or at least not as scary as it sounds). After the interview, I waited for another two months for the job to start. I used that time to explore my deeper interests, work on some good projects, read books about my newly found interest in cryptographic engineering and spend some good time at home in general.

Joining LaughGuru – Initial Impressions

My first day at LaughGuru was filled with mixed feelings. It wasn’t all scary as was my first day at Samagra. Back then, I didn’t know what was expected of me, and if I’ll be able to live up to the expectations of my mentors and friends. This time, there was no such feeling. I knew I was hired to write Javascript, build frontends, collaborate with an even more experienced developer and hence, I had a clear idea of what I had gotten myself into. I was not a hundred percent happy, and that was because of the sinking feeling of adulthood starting, that I was into frontend engineering which wasn’t a long term interest of mine (nor did I plan on making it that) and just plain dejection that the long vacation was over and I’ll no longer be able to spend time on the things that I wanted to. All of that aside, the day went okay, and they gave me company email accounts and added me to the comms channels. It felt good.

Since I had worked a bit before this, I couldn’t help but notice the contrasts in the way both the companies and their people operated. I missed the ‘hello’s and ‘good morning’s when people came into the office everyday wearing a wide smile, lunch sharing, office hangouts and town halls, a family like environment and a CEO who actually speaks to you and hears you. On the plus side, I was working in an actual ‘tech team’ with people who knew more about most things than me, although people weren’t into tech, I could have decent technical conversations, learn about patterns and best practices and more. The ‘working in a tech startup’ dream had become a reality and I was naturally happy about it.

Given that the company wasn’t very fast paced and our manager was very considerate about deadlines, the work load was very low. Due to that, I could do quite a few things on the side, read after coming back home and the weekends were entirely free (I only had to work during the weekends during my last couple of weeks). I managed to squeeze enough time to learn Haskell, build a nice speaker, write on this blog regularly, learn applied cryptography and implement algorithms, read books and travel to some extent (Jagriti Yatra was during this time). Another perks of working for LaughGuru (or any tech startup in general) is, you get paid decently well. And when you get paid well, you can buy time with it (I got myself a nice house close to the office to ease commute), or service some of your expensive hobbies and interests (a paid VPN and email provider, a fancy laptop, lots of paperback books etc).

Last 4 Months

So after the initial month’s dust settled and things started to become natural to me, I started to enjoy my job a lot more. The work that I did (mostly writing ReactJS and lots of CSS which I had recently picked up) had become second nature to me, and as a result I could put in more thought about what I was doing, why I was doing what I was doing, asking questions and learning things from a product and even business perspective rather than just the frontend or tech perspective which I did in the initial months. Along with the work part, I was also hanging out with my office friends, seeing and learning things outside of tech, hanging out at nice places and exchanging stories. Due to a weird turn of events, the frontend lead (whom I used to report) and Abhishek (my friend who had referred me to LaughGuru) had to leave the company. It was not a very happy time for me, for I was very close with both of these people and had become very comfortable with having them around. Guess it is part of being in a professional setting, people come and go.

Things were different after that, not necessarily better or worse. I was reporting directly to the manager (also the product guy). He gave me all the product ‘gyaan’ that he had accumulated over the years, we discussed tech during work and checked out other company’s products and borrowed inspiration from them. Since I was the only person on the frontend of our product, I had to put in some thinking before jumping into code, and that was a very important lesson that I knew I needed to learn. Towards the end of my time at LaughGuru, I was doing more thinking about how to implement a feature, the data flow, handling edge cases and basic optimization than I was actually coding. I had also simultaneously read the novel ‘The Mythical Man Month’ and was realizing its importance.

Our manager was a very smart guy and quite friendly. Another one of my colleagues, the person who took care of the content, had also become a good friend. I would really miss the nice lunch and coffee conversations with these two. Both of them were math, history and science nerds, and it was always fun to listen to them talk. I went to a star gazing session with one of them, and a mid night cycling event earlier in the year and it was very cool hanging out with them. Will definitely miss that as well.

Closing the LaughGuru Chapter

While the departure of my friends was heartbreaking, I had decided to continue my work on the awesome product that we were building, especially now that I was in total control of the codebase of the frontend. It was delightful to see the frontend take shape and become usable as each day passed. We were building a lot of new features, and I felt extremely proud to be able to deliver them end to end. It was similar to my time in Samagra where I would get to build the entire projects end to end, only here I was much more mature. Because of all of this, or maybe not because of it but because of my own sluggishness, my personal studies were taking a hit. I wasn’t making much progress in that direction.

It was sometime during March that I found the time I gave to my personal studies inadequate. I also had a very clear understanding that nows the time to experiment and risk it for a dream, and it will only get harder the longer I wait. Talking to some people and thinking thoroughly about this, I told my manager that I needed time to study and hence I’d be discontinuing (at least full time) with my role as an engineer at this organization. The discussions that followed lead to this day today and all of it sailed very smoothly. Last few weeks were very busy; vacating my rented flat, working to get the product in decent shape, the nostalgia of my amazing time spent here and the anticipation for a brighter future filled with happiness. I’ll be unemployed again soon, will look for a way to sustain myself but most importantly, do something that I’ll never get tired of doing. That’s the simple end goal here.

Good Experiences & Learnings

I think working with some very smart people has been the best part of the experience. It gives you a benchmark to look up to with regards to everything, from books to humor. You learn a lot in the everyday conversations, the occasional outings and the way they work. That was one thing I couldn’t do sitting at home (I would’ve anyway written code or learned a new technology, so that’s not something particular to LaughGuru). I read some really nice books and articles thanks to my colleagues. My understanding of tech products has matured a lot during the last couple of months, and I think this will come in handy for my personal projects.

One thing that I’m proud of learning in tech is CSS. This is genuinely something that I wouldn’t have learned if not for LaughGuru. As a result, I’m writing it here. CSS is already coming in handy at many places. From fixing random things on my blog, to the other websites that I manage, to even modifying some random theme’s stylesheets found on the Internet to suit my requirements. The CSS I wrote at LaughGuru was strictly mobile responsive, was interactive and used many of the newer CSS3 semantics. Now, because of that, writing a much simpler static blog’s CSS feels quite easy (not talking about this one. Obviously). Learning CSS, maybe not the most pleasant thing, was, in hindsight, a great investment of my time.

Before joining LaughGuru, I scored myself a solid 8 out of 10 for Javascript. But then, I learned so much more here, from service workers, caching, index DB, shadow dom, es6 and 7, abstraction for Javascript components (the OO way), the list goes on and on. Now I’ll hardly score myself a 6, because I’m pretty sure the more I dig, the more there will be to learn and it is in my best interest to stay modest, haha!

I’ve made some friends here. Not just here, but at every place I’ve interacted for the job, I made a conscious effort to be nice and likable (how well that went, I can’t tell), tech can come in second. I was horrible with my social skills in junior college. Things changed a bit in engineering, but I still was around a select few, not interacting much (if at all) with the rest of the class. This time, I made it a point to speak out honestly what I thought, and not just to the few friends. It has been successful so far, and no one has called me a weirdo yet. The Jagriti Yatra really helped me in this regard, and boasted my confidence on many fronts, most important of which was that even if you take the tech out of the conversation, I can still keep the chat going and not disseminate into silence.

Useful Lessons Learned

I’ve learned some lessons during my time here at LaughGuru, some of them the hard way. I’ll start with the one I personally felt very good after learning. It was about the way of the society. For the better part of teenage and until the end of engineering, I always did whatever I did with computers for myself, for the fun and satisfaction. Then suddenly, I got into this fast paced world of startups where your career came before anything and growing professionally was of prime importance; where you become your job description, and I became a React engineer. I had almost fallen for this, taken this to be what adulthood was meant to be. But I am so glad I was wrong. And I decided to again go back to the basics, to doing things that I enjoyed doing. I don’t know how this will turn out, but at least I’ll be happy.

I learned that one has to be smart, not academic but the street smart. While people in general are nice, occasionally you’ll find someone who’s just there to use you. And that is fine while you get a fair return (rewarded in some way), but not without that. There will be people who take the word ‘resource’ a bit too literally and act that way. The important bit for me was realizing that I’m dealing with such a person and taking control of the situation. It is funny how I’ve read about the paranoid mindset all the time in the infosec world, and it seems obvious there, but I had to ‘learn’ it separately when it came to people and the world outside computers.

I learned how powerful negativity is, and how important it is to distance oneself from such forces. Negativity around you is never healthy, and in a profession where your job is to think, plan and create, negativity is a disaster for productivity.

Things To Look Forward To

While LaughGuru was a great place to be at, there are some things I really look forward to for my next gig. First, given my interests, I’ll try to find a job at a place that understands and encourages free software, and that the work I’ll be doing will be open for the world to see. ‘Open Source’ started as just a word for me, then it quickly became an idea that I’d want to be part of sometime in the distant future, and now after working for a for-profit startup and writing proprietary code (which I honestly believe is a perfectly valid thing to do), I realized how integral had the idea of writing free software become to me. For this reason, I’ll try to find a place where I’ll fit ideologically just as well as technically and socially.

I look forward to working for an organization where the chief(s) officers are in touch with the employees and have conversations with them regularly. I feel this is important to the entire growth feedback loop, growth for the organization as well as the employee. This, unfortunately, never happened at LaughGuru. I saw the CEO for the first time three months into my time at his company and as far as I can remember, we never had a meaningful conversation during my time there. Maybe I could’ve tried more, or maybe I need to work on my communication skills more. I’m sure there must’ve been good reasons for that (the obvious one being I simply wasn’t important enough). Whatever might’ve been the reason, that’s past, and for the future I’ll see to it that I have a conversation with the chiefs of the organization before joining and get to know them (I realize that it isn’t feasible for even the slightly larger organizations, let alone the medium to big ones, but I think it is a good personal objective to have).

Money is the root of many evils that happen in an organization. Delayed salaries, pending bonuses, unmet commitments regarding finances and many such things lead to decay of trust between an employee and employer, however good the other relations are, and that is really unfortunate. One thing I’ve realized here is that speaking out the truth upfront rather than giving away excuse after excuse can save quite a few things to both the parties. Going out of business will inevitably happen to many, if not most companies. It is how the situation is handled by the employee and the employer that makes the difference. And I look forward to seeing better ways of that being done.

In Closing

There’s so much more to write, but one can never fully express eight good months of adventures, learning and building through a little blog post, can one? I hope you found this article interesting. If you have any comments, feel free to write them to me at my email address. Thank you for reading.