Joy Marcus is a Venture Partner with Gotham and is CEO of Bloglovin. After chatting with her today I decided to give the platform a try. The company is growing like a weed so hopefully they’ll send some traffic this way.
Given my security background I naturally look at a lot of security startups, and more than a few of these involve crypto. For those who don’t know, crypto can pose a problem in tech due diligence since bad crypto looks like good crypto, until someone breaks it.
So what does one look for to catch bad crypto? Glad you asked. The technical term for the red flags I try to spot is Mumbo-Jumbo. When I hear a hand waving explanation about how this crypto does something that no one has done before and that it is “tough for people to believe at first” my Spidey sense goes off. And if their white-paper is really just a glorified sales pitch then I’m really worried.
In the book EBoys the author talks about Benchmark’s investment in a crypto company where the founder claims to have implemented a one-time pad in his program. If you know anything about crypto then you know this just can’t be true. Full stop. Benchmark ends up investing and the company goes down in flames. As someone who knew about crypto, I was shaking my head the entire time they are discussing making the investment in the book because you know they company can’t be doing what they say they are.
So, what’s the point? I’ve seen a few companies recently that when I ask how they do their crypto, I get vague answers on the technical front and deflections about the how business benefits of their software are amazing. When the CEO says: “Do you know any other program that can do X, Y, and Z?” This is a huge red flag; if the CEO (or CTO) can’t explain how it works it is a problem. Sounds obvious right? But these companies are still getting funded by folks, which leads me to believe that not everyone is doing their due diligence on this correctly.
In contrast, a CEO recently gave me a great answer. He walked me through the public algorithms used and explained how they used public and private key cryptography to protect their data. When we dove in he explained what an attacker would have to do to get access to a users data, and how a compromise of their server would affect users. He talked about the security model and was forthright about its limitations, explaining how an attacker could get data under different sets of circumstances and the work they had done to mitigate them. Giving honest answers about what happens when a machine is compromised instead of insisting it will never happen should give confidence, not frighten people off.
Cryptography is subtle and can be tricky, so I often have an expert take a look as a final diligence step. But many times that level of scrutiny isn’t necessary; if the CTO can’t answer how the program generally protects users then a deep dive just isn’t warranted. There isn’t any need to call in an expert mechanic if the car is clearly missing its engine. If you’re going to pitch a product that relies heavily on crypto you need to be able to explain what it does; if you as CEO can’t explain how it works then how can an investor have any confidence in the product.
<I actually wrote this several weeks ago, but then life got in the way. I think it is still relevant.>
This is the first in a (hopefully) recurring theme of posts discussing patterns I’m seeing in startup companies.
For the past few months I’ve seen a number of companies that can be described as Github for X. Basically an open storage platform where people can fork off projects. While I’ve seen a bunch of others, some good examples are:
Partly this is probably due to Githubs big fundraise. But another aspect is probably that coders are starting to branch out to other domains and they are trying to bring their tools with them.
Back in the dark ages we used RCS & CVS to track source changes. They were hard to use in teams and didn’t scale well to the Internet. Today we have incredibly powerful tools with integrated sharing platforms.
For those who’ve used these tools with a distributed team you know how powerful they can be. It is only natural that people will want to bring them to other domains.