Jobs at Evervault
Build the web’s encryption engine.
We’re recruiting engineers who are generalists and are comfortable shipping across the Evervault stack & codebase. Our stack includes Rust, Node.js, and AWS Nitro Enclaves. Here’s some things we’re working on:
Infrastructure & distributed cryptosystems
The core challenge for us in building encryption infrastructure is simple: How do we design, architect, and implement globally distributed multi-cloud cryptosystems? At the core of these cryptosystems is the Evervault Encryption Engine (E3).
We know that developers will never want less secure, less robust encryption — so, we’ll never stop innovating on our encryption schemes, key management, and entropy. E3 powers both Relay & Cages.
Relay is a proxy for encrypting data before it touches a backend, and for decrypting it as it’s sent to a third-party API, or is returned to users. One of the problems we’re solving is how to adaptively prevent data leakage and block HTTP requests to unknown & fraudulent URLs.
Evervault Cages are isolated serverless functions for processing encrypted data. Developers deploy their Node.js code to a Cage to process the data they encrypt with Relay or our SDKs.
We'll never stop innovating on lowering Cage latency and making sure any code can be run as a Cage. Allowing companies to share & combine datasets via Cages will bring new challenges as well.
UI, CLI, API, and SDKs
We know that developers will never want slower implementation, so we invest tremendous energy into carefully crafting the interfaces and tools they use to build with Evervault. One of our core focuses over-time will be ensuring standardized omni-language support.
Because our mission is to encrypt the web — and because the web's so vast — a core challenge we have is this: How do you build a cohesive ecosystem of integrations so that Evervault is there for developers when they want to encrypt anything, anywhere, anytime?
As more developers build with Evervault, we’ll have the data to directly see how our mission to encrypt the web is progressing. Building the infrastructure & tools for ingesting and digesting this data will become increasingly important.
While we're singularly focused on building distributed cryptosystems based on standardized cryptography, it's inevitable that we'll implement cutting-edge cryptography in the future.
If you’re curious about the future of cryptography — and Evervault — here are some good starting points (some of which remain impractical):
- Fully-homomorphic encryption (FHE): The problem with standard encryption is that data must be decrypted before it is operated on. FHE ensures that data is operated on only in an encrypted state.
- End-to-end encrypted databases: End-to-end encrypted databases (like CryptDB) are an intermediate design point before FHE, which allow queries over encrypted data.
- Post-quantum cryptography (PQC): Quantum computers will break industry-standard cryptographic systems (like TLS, the security protocol behind HTTPS). NIST is in the process of standardizing PQC algorithms that are secure against quantum computers.
- Secure multi-party computation (MPC): MPC enables a number of independent parties with private data to operate on the aggregate private data and receive the result — without the parties learning each others’ private data.
- Trusted execution environments (TEEs): Industry-standard is encrypting data in transit and at rest. TEEs keep data encrypted while being processed. Evervault was invited to join the AWS Nitro Enclaves Preview.
- Privacy-preserving machine learning (PPML): PPML is where ML and cryptography converge. This article is an insightful introduction to PPML. We’re excited by what OpenMined are doing in this space.
- Format-preserving encryption (FPE): FPE means that the encrypted form of data has the same format, including the length, as the original data.
- Private information retrieval (PIR): PIR is a protocol that allows a client to retrieve an element of a database without the owner of that database being able to determine which element was selected.
- Ownership over your work, and in the company
- Open vacation policy
- Flexible work hours
- Build your dream machine & workspace
- Health insurance
- Paid maternity and paternity leave
- Relocation costs
- Free lunch & dinner
We've designed our hiring process to simulate our day-to-day as much as possible, and to provide you with the opportunity to work with us as much as possible before deciding to join. Here’s what our hiring process looks like for engineers:
- Application: Submit your application including:
- Links to your profiles (e.g. GitHub, Twitter, Substack)
- A technical project(s) you’re particularly proud of — with some explanation of what it does
- Whatever information you think would be most useful — like a short explanation of your accomplishments & background, what you like to work on, and why you’re excited about joining Evervault
- Introduction call: An opportunity for us to get to know you & for you to learn more about Evervault.
- Take-home task: A coding task that helps us understand if you can write clean, maintainable, and well-documented code.
- Coding call: We’ll do an hour coding call where you’ll extend the take-home task. This helps us see what it’s like working with each other.
- Paid (virtual) on-site: We’ll embed you into our current builds as much as possible to see if you can hit the ground running.
- Offer: We aim to go from introduction call to offer made within two weeks.
Sending a solution to one or more of these programming challenges is an effective way of impressing us:
- Build a distributed system with 3 separate worker nodes which dynamically calculates n digits of Pi (π) over
xcycles in a distributed manner, exposing a single
POST /calculateendpoint which accepts
nas its body.
- Build a Node.js module which exposes a single function that accepts a function as its only parameter. Serialize the code for the parameter function and any external dependencies (e.g. npm modules, required functions). Bundle it into a single
index.jsfile which can be run in isolation while maintaining the same functionality.
- Implement a TLS man-in-the-middle forward proxy using HTTP CONNECT, which replaces all instances of foo with bar in outbound requests. Make it as fast/low-latency as possible.
- Build an implementation of the Raft consensus algorithm across n nodes that demonstrates leader election and log replication.