Needs More Crypto

Various problems that could be solved by the application of cryptography

Phone Spam and Scams

The problem of phone spam is not knowing that the caller is who they say they are. We already have solved this problem on the web. It’s the same problem as knowing that you’re getting your bank website and not some hacker. Usually when web security is explained to lay people, the focus is on the fact that traffic is encrypted to prevent eavesdropping. Of course this is important since web traffic hops across many untrusted routers and servers between its origin and destination. But what is also crucial is knowing that the destination is who you want it to be. Encryption alone only guarantees that you are being hacked by no more than one hacker.

Phone calls need to be initiated over a protocol that validates cryptographic certificates to confirm that the other party is who they say they are.

This would solve both the problem of spammers bugging regular people and also scammers imitating customers to businesses. I had an experience the other day where I called my credit card customer service and as soon as I connected to a person the call dropped. This happened twice. I suspect they thought I was a scammer because I was at the time logged into my account on my work computer. My work computer is on a VPN which I’ve heard sometimes routes our traffic through India, probably related to the fact we have a team in Bangalore.

If my phone had a trusted certificate, my bank could have more confidence that it was me calling.

Transferring Medical Data

I had a bothersome time recently getting new glasses. I didn’t want to buy into the Luxotica cartel, so I used a popular startup. To get my prescription they offered to call my eye doctor themselves. The eye doctor tried to fax it over but that failed for whatever reason. I’m not sure why I can’t be trusted to relay my prescription to the eye glass store. But let’s assume there’s a good reason. My prescription could have been sent using PGP encrypted email. And I wouldn’t have to ask my eye doctor to send the prescription to the store. They could send it to me, along with their PGP signature that references a public key on the popular key-servers. This would validate that the prescription wasn’t altered by me or any other intermediary. I’m not sure how this works with HIPAA compliance, but I don’t know of a good reason this wouldn’t work. There’s just the bad reason that the secure email market is dominated by non-interoperable proprietary solutions.


Study: Job Applicants With 4-Year College Degree Just As Successful As Those Who Lie About Having 4-Year College Degree

The Onion

I don’t know how real of a problem this is, applicants lying about degrees or experience on their resumes, but I can imagine a cryptographic solution. That would be a digital resume format which contains for each employer, a cryptographic signature for that portion of your resume. When checking the references for a candidate, a prospective employer can call up previous employers to verify dates of employment. But we can cut out the manual steps. This can be done the same way certificate-based digital signatures work with PDFs with the only difference being that instead of one signature validating the whole document, we’d have multiple different signatures, each validating only a portion of the document. The infrastructure costs could be minimal if public keys are hosted on the traditional networks of key-servers used with PGP.


Two new creational design patterns

Polluting Factory Method

I named this the polluting factory method pattern because it relies on mutation. The nifty thing about this pattern is if you squint really hard, it looks like you have named parameters, or especially if you use a multi-line lambda, it looks almost like an object literal.

What I like about this pattern is that there is a clear distinction between required parameters and optional ones. Also, by using the most succinct class syntax in Java, there is relatively little boilerplate.

Lockstep Builder Pattern


The heart of this pattern is having a new class for each required field and a single method on each builder class which returns the next step. Compared to the builder pattern, this goes in the opposite direction. It is very verbose. The point of this pattern is to make object creation as easy as possible. By having only one method on each class, your IDE will practically walk you through creating the object step by step. If you instantiate an object often enough, eventually it might be worthwhile to invest in designing the class this way. Or if you use some form of code generation, that might also tip the scales to make this worthwhile.


Straw Man Proposal: Every Regex Should Have Its Own Class

Regular expressions are commonly written very casually on the fly based on some known examples. Regexes are densely packed with logic that is often a matter of one’s personal style as much as intentional decisions about what that regex should match or not. Many choices are overlooked or made unintentionally by the platform executing the regex. Some examples include whether or not to match across lines, or whether to be greedy (if the author even knows what that means).

A regular expression is usually pure implementation (unless it has embedded comments, which I’ve yet to see in the wild). I have a rule of thumb that most code logic should have two parts: what and how. Any non-trivial piece of logic should be wrapped in a function or class so that the next person coming by doesn’t have to execute the logic in their head to know what it’s doing. They can assume that the code does what it says it does unless they have further reason to doubt it. You could say this is another way of talking about the Single Level of Abstraction Principle.

The most important reason to give every regex its own class is for unit testing. Every regex should be accompanied with a set of examples of what it’s intended to match. Every regex represent bugs waiting to happen, so creating it initially with a set of unit tests prevent regressions of the original test cases and encourage accumulation of additional regressions tests.

Unit testing is a great mental hack to get around happy-path bias. I think regexes are naturally prone to happy-path bias.

Counter: Why not just a function?

Response: Not a bad point. I’m more confident in stating the proposal “Don’t use a regex directly”. In the programming cultures I had in mind, by which I mean those passionate about testing, static functions are frowned upon to the point that even if there’s not a good reason against one in a particular case, a true class is considered better style probably for consistency’s sake. In an FP codebase, I wouldn’t begrudge a regex wrapped in a function.

Counter: What about a checklist for writing regexes? To make sure you’ve considered subtleties like greediness.

Response: That makes sense in the imaginary world where code is written once and seldom changed. In the real world where code is a living document, tests ensure continued compliance.


If a wheel keeps getting reinvented, the most important thing is for everyone to share the test cases that drove them to reinvent the wheel again.