The compromises of product development
Sometimes, you need to “settle”
I am back for another update! Quite a few things have happened after I published the last update. I have mocked up some basic wireframes. Check them out here! Once that was done, I got started with making the Android app.
First, let me give a brief overview of how I envisioned the app to run. You “login” with your name and password. Since this is an algorithmic password manager, this sensitive stuff is not stored anywhere. These details are used to generate your own cryptographic seed — using the Argon2 algorithm. A year ago, I would have chosen scrypt, but Argon2 was the winner of the Password Hashing Competition in 2015 — which is why I chose it over scrypt. Once you have the seed, you supply the website address (eg: medium.com) and you generate a password — using an algorithm like SHA-256. The idea is that given a seed and site address, the generated password would be the same every time. There are some other implementation artifacts which I have planned for and will explain in a later post.
My plan for coding the app (live updates here) was to first flesh out the login screen and then add the logic for generating the cryptographic seed on logging in and store it in a temporary session variable in Android. I wrote some boilerplate code to generate an Argon2 hash and expectedly ran the code on my Nexus 6P waiting to see the generated hash appear in a toast.
But, nah. The app crashed.
Java.lang.UnsatisfiedLinkErrorOh, fancy!
In my (admittedly limited) Java/Android experience, I had never seen this error. Calling the Argon2 library threw this up and I was befuddled (And oh, if you know how to solve this, please sound off here). Ultimately, I realized that the JVM Argon2 binding I was calling had no ARM implementation. And even the original C implementation has only been tested on x86 architectures. I could possibly attempt to do an ARM implementation but especially in security and cryptography, it is better to let the experts do their thing. As a noob, it is best if I don’t try — there is a lot of stuff I need to learn before I even attempt to implement a sensitive library with wide-ranging implications.
So now I have to make a choice. I can either hold off until Argon2 is more mature — which can take a few years, given how everything has to be vetted and stress-tested in cryptography — or use an older, more mature library. I am going to take the latter route in this app and appropriately include some future-proof method to transition the app to a newer algorithm at a later stage. Some kind of versioning or backwards compatibility is essential so that users can still generate passwords! The short answer is that yes, NirvanaPass will be pivoting from Argon2 to scrypt to generate the cryptographic seed. There are concerns over scrypt, but as of now, that is the best available.
Time to draw up a future-proofing plan and get back to coding!
See you soon,
Pratyush.
