Posts
Open sourcing `@yaki-inc/crypto`
End to end encryption is at the core of how I’m building privacy and security into Datayaki. And with the availability of solid battle tested encryption libraries like
libsodium
andtweetnacl
, implementing end-to-end encryption properly into your NodeJS and Typescript packages has become very accessible……Except it hasn’t!
There is Symmetric encryption where a single secret key is used for both encrypting and decrypting data, Public/Private key based Asymmetric encryption where you encrypt with one of two keys and decrypt with its complementary key. And there is Diffie Hellman Key Exchange where two parties can independently compute and arrive at the same shared symmetric key knowing just the public key of the other party.
There’s so much security built into these encryption algorithms. Yet, the primary packages that are widely used come with one major security risk…
Developer Error!
tweetnacl
is a fast and correct implementation of cryptographic primitives, yet all the keys in the library are typed asstring
s.While this makes it very easily portable and light weight, it also makes it very easy to introduce an unintentional bug like exposing a PrivateKey in a keypair when you meant to share the PublicKey. Since they are both essentially string of bytes, it is easy to mistakenly send one for the other, and have it be exposed in some server’s access log on the internet for all eternity. Having all the keys be strings also makes it hard to debug and easy to introduce bugs in your code that lead to sneaky bugs. For instance, passing in a symmetric key in place of a signing key, or vice versa.
Announcing the availability of
@yaki-inc/crypto
Yaki’s crypto library is a strongly-typed and easy-to-understand wrapper around the battle tested tweetnacl. It’s open sourced under MIT license.
You can read more about it on NPM at @yaki-inc/crypto. But, the gist of it is, it’s strongly typed. A PublicKey and PrivateKey are two different types. And an EncryptionPublicKey is different from a SigningPublicKey.
It also comes with a super easy to use AEAD helper class that lets you do symmetric, asymmetric, and seal/unseal operations and still enforce type restrictions on the resulting
EncryptedDatagram
s. The library also introduces YEP protocol, or the Yaki Encrypted Permissions protocol. This is a way to implement access controls by requiring cryptographic proofs for permission grants, instead of relying on simple boolean flags that any database admin can go tinker with.Datayaki uses it!
Open sourcing was both done to give back something to the community of developers and builders out there, as well as to openly showcase the secure foundations upon which Datayaki’s security is built.
Zero trust is the best way to guarantee trust in Datayaki.
Move fast! Break things! Get stuck!
When I started on my journey of building Datayaki, I chose to heavily bias towards fast and scrappy feature development over engineering rigor. This was a conscious decision to counteract what I encountered while building Remix, aka Mix.byCollab.com half a decade ago.
When I started working on Remix, I had just left Google, and took a lot of the great learnings from Google and applied it towards the project. I built a bazel monorepo. I looked into CI/CD and Code Review solutions like Gerrit, since none existed on Github at the time. I also went down the rabbit hole of setting up a Kubernetes cluster, and designed a service proxy framework (using Envoy) so that my backend services, and my javascript frontend can communicate using protobufs, grpc, http2, and envoy sidecar proxies. I even got bazel to build and test my polyglot project all at once with a simple
bazel build ...
command. Do you know how effin’ hard that is?I did all that and more, except for iterating on the product! I spent 6 months down the drain back then chasing those engineering rigor problems. Of course, I did build a basic collaborative video editor on the web, but then when I brought it to the first customer, it bombed. And around the same time I ran out of money due to an unexpected tax liability… and the project didn’t see the light of day. I’ll save that sad story for another day.
I didn’t want to end up making the same mistakes from the past this time around with Datayaki. I wanted to iterate on product features quickly and put it in the hands of potential customers to get their feedback. So, I basically went against all my 20 years of software engineering training, and went all in on the Amazon way of scrappily putting together the bare minimum effort to get things out, and only investing more time when things stick and scale and rigor graduate from being nice-to-haves, and turn into necessities.
Big Things, Small Beginnings.
Starting a new venture.
Send an emai with your industry/role to access@yaki.app to get access.
Blogging upgrades
One of the important drivers for migrating my blog over to Github Pages / Jekyll has been the need to create more technical articles with ease. This meant, I wanted to be able to integrate with nifty content creation JS libraries such as ASCIInema, Mermaid and JsFiddle.
To start things off, here’s the first integration: Mermaid.
flowchart TD; A[Step 1: Collect Users] -->|lots of users| B(Step 2???); B --> C{???}; C -->|One| D[Profit!]; C -->|Two| E[Profit!]; C -->|Three| F[fa:fa-car Fast car!];I have also updated the blog with pagination and added jsonresume integration. Check out the README.md file at the repo
Now, I simply have to update resume.json file and push the changes, and my PDF and HTML files will get auto generated via a Github workflow.
Welcome to Jekyll!
I’m moving my blog from Tumblr to Jekyll/Github Pages. Why?
- Tumblr stopped Javascript support a while back, and had slowly been removing more and more site customizations I had in place. Seriously, checkout the D3 Demo here and compare it to my tumblr hosted post.
- Jekyll is in line with the static blog generator pattern I wanted to use for migrating my blog over. Serving static files is a lot more deterministic and cost effective than generating a site on the fly for a blog.
- Jekyll lets me customize the look and feel through easy templating, and lets me integrate with plugins I care about such as mermaidjs.
- Github Pages makes deploying changes as easy as updating my local jekyll server and pushing changes to the repo. And to top it off, it is free compared to my S3 hosting solution, which is already pretty cheap at about $1.50/month.
- I get to focus on blogging vs. deploying and setting permissions on S3.
- I get the one interactive feature I care about (i.e, Commenting) through utteranc.es, a nifty plugin that uses Github issues as a backend for commenting on posts.
- I’m using
git
everyday anyway. What better way to quickly jot a post.
This is gonna be my new blogging home moving forward.
subscribe via RSS