7 Cryptography Projects to Build for Your Portfolio

Cryptography is the machinery under most of what Web3 claims to do: proving who authorized a transaction, keeping a message readable only to its recipient, showing that a computation ran correctly without showing what went into it. Reading about those mechanisms and building with them are different skills, and only the second one shows up in a portfolio.

Below are seven kinds of cryptography project, all of them running systems rather than teaching exercises. For each one: what it does, the mechanism underneath, and what tends to go wrong when it is built badly.

1. Signal Protocol

The Signal Protocol provides end-to-end encryption for messaging that works even when the other party is offline. It was built by Open Whisper Systems, is maintained by Signal Messenger, and is used by Signal, WhatsApp, and Google Messages for RCS chats.

It combines two pieces. Extended Triple Diffie-Hellman (X3DH) handles the initial key agreement, establishing a shared secret between two users when only one of them is online. The Double Ratchet algorithm then takes over for the rest of the conversation.

How it works

The Double Ratchet derives a fresh encryption key for every message. That continuous rotation buys two properties:

• Forward secrecy. If a long-term key is compromised, past messages stay unreadable, because the per-message keys that encrypted them were discarded as soon as they were used.
• Post-compromise security. If a session key is compromised, the session repairs itself once the attacker stops participating, and later messages are secure again.

The design assumes keys will eventually leak, and limits what each leak costs, rather than assuming long-term key secrecy holds.

Implementation notes

Use the official libsignal libraries rather than writing your own implementation. Cryptographic protocols are difficult to implement correctly, and the mistakes are rarely visible in testing.

What is left for you to get right: key verification, which Signal surfaces as safety numbers; secure storage of identity keys on the device; and out-of-order or delayed message delivery, which the ratchet has to tolerate without losing state.

2. TLS implementations

Transport Layer Security is the protocol securing nearly all web and API traffic. Implementing it means writing the software that runs the handshake: certificate validation, key exchange, and bulk encryption of the data that follows. Working implementations worth reading are OpenSSL, Google's BoringSSL, and the memory-safe rustls.

TLS establishes an authenticated, encrypted channel over a network anyone can watch. Asymmetric cryptography is used in the handshake to agree on a shared secret; faster symmetric cryptography encrypts the traffic afterwards.

How it works

The handshake negotiates the parameters of the session:

• Cipher suite negotiation. Client and server agree on the algorithms used for key exchange, authentication, and encryption.
• Authentication. The server presents a digital certificate, which the client validates against a trusted certificate authority.
• Key exchange. Both sides derive a shared session key without an eavesdropper being able to reconstruct it. TLS 1.3, published by the IETF as RFC 8446 in August 2018, removed static RSA and static Diffie-Hellman key exchange, so every public-key exchange in 1.3 is ephemeral Diffie-Hellman and provides forward secrecy. The exception is the pre-shared-key-only mode, which RFC 8446 notes gives up forward secrecy unless the pre-shared key is combined with an ephemeral exchange.

Implementation notes

The same rule applies: use a maintained library rather than building from scratch. Configuration is where most of the risk actually sits. Disable SSLv3 and TLS 1.0 and 1.1, enable HTTP Strict Transport Security so browsers will not fall back to plaintext, restrict the accepted cipher suites to modern ones, and keep the library patched. Serious TLS vulnerabilities are usually found in implementations rather than in the protocol.

3. Blockchain cryptography

A blockchain applies three well-understood primitives — hash functions, digital signatures, and Merkle trees — so that mutually distrusting parties can agree on a single ledger. None of the cryptography is new. The arrangement is.

Each block contains a hash of the block before it, which makes the chain tamper-evident. Digital signatures authenticate transactions, so only the holder of a private key can move the assets that key controls.

How it works

• Hash functions. SHA-256 and equivalents produce a fixed-size fingerprint of any input. They link blocks to their predecessors and build the trees below.
• Merkle trees. A tree of hashes over a block's transactions, which lets you prove a single transaction is included in a block without downloading the whole block.
• Public-key cryptography. Digital signatures prove ownership. Bitcoin and Ethereum accounts use ECDSA over the secp256k1 curve; Ethereum validators use BLS signatures, and Solana uses Ed25519. The private key signs, and an address derived from the public key receives.

Rewriting an old transaction means recomputing the hash of its block and every block after it, then persuading the network to accept that chain instead of the existing one. What that costs depends on the consensus mechanism: redoing the proof of work on a chain like Bitcoin, or forfeiting staked capital on a proof-of-stake chain. Ethereum has run on proof of stake since September 2022, so any description of mining ether describes a system that no longer exists.

The terms in this section are defined in the Web3 dictionary.

Implementation notes

Blockchain projects are far more likely to fail at key management than at cryptography. Keep signing keys in hardware wallets or an HSM, use audited libraries for signature generation and verification, and exercise the system on a testnet before it holds anything real. For smart contracts, the equivalent discipline is access control on privileged functions and an external audit before the contract custodies other people's money.

4. Zero-knowledge proofs

A zero-knowledge proof lets one party, the prover, convince another, the verifier, that a statement is true without revealing why it is true. Zcash uses them for shielded transactions. Rollups use them to prove that a batch of transactions was executed correctly, so the underlying chain can check the proof instead of re-running the batch.

Two families are in common use: zk-SNARKs and zk-STARKs. They trade off proof size, proving time, verification cost, and whether a trusted setup ceremony is needed.

How it works

Three properties define a proof system:

• Completeness. If the statement is true and both parties follow the protocol, the verifier is convinced.
• Soundness. If the statement is false, the prover cannot convince the verifier except with negligible probability.
• Zero-knowledge. The verifier learns nothing beyond the fact that the statement is true.

Implementation notes

Use an existing toolchain rather than building a proof system. Circom with snarkjs is the usual entry point. Most of the real work is circuit design: expressing the computation you want to prove in a form the proof system accepts, and doing it efficiently, because proving time grows with circuit size.

Choose the scheme before writing the circuit. SNARKs produce small proofs that are cheap to verify, but many of them require a trusted setup ceremony whose participants must not all collude. STARKs need no setup and rest on hash function assumptions that are expected to hold against quantum attack, at the cost of substantially larger proofs.

5. Post-quantum cryptography

A sufficiently large quantum computer running Shor's algorithm would break RSA and elliptic-curve cryptography — the asymmetric algorithms behind almost every authenticated connection in use. Post-quantum cryptography replaces them with schemes built on problems believed to be hard for quantum and classical computers alike: structured lattices, error-correcting codes, and hash-based signatures.

NIST published the first three standards in August 2024: FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) for key encapsulation, and FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+) for digital signatures. Further algorithms, including HQC, are still going through standardization.

The reason to migrate before quantum computers exist is that encrypted traffic recorded today can be decrypted later. Anything that has to stay confidential for a decade is already exposed.

How it works

• Quantum resistance. The underlying problems are conjectured to be intractable for quantum computers. Conjectured, not proven — these are hardness assumptions, as classical public-key cryptography also is.
• Crypto-agility. A system that can swap one algorithm for another without being redesigned can respond when an assumption breaks. In practice this matters more than any single algorithm choice.

The Open Quantum Safe project publishes open-source implementations of these algorithms and integrations into protocols including TLS and SSH, which is the practical way to try them.

Implementation notes

Start by inventorying everywhere your systems use public-key cryptography. That list is usually longer than expected, and producing it is the real blocker on migration rather than the algorithms themselves.

Test performance early. Post-quantum keys and signatures are larger than their classical equivalents, which shows up in handshake sizes, packet fragmentation, and anywhere a signature is stored per record. Hybrid deployment — running a classical and a post-quantum algorithm together, so the session holds if either one does — is the standard transitional approach and how TLS deployments have handled the change.

6. Secure multi-party computation

Secure multi-party computation (SMPC) lets several parties compute a function over their combined inputs without any of them revealing their input to the others. It is used for joint analytics between organizations that are not permitted to share data, private auctions, and threshold signing, where a key is never assembled in one place.

Two techniques do most of the work. Secret sharing splits each input into shares distributed across the participants, where no share reveals anything on its own. Garbled circuits hide the logic of the computation from the party evaluating it. No single participant holds enough to reconstruct another's data, yet the group arrives at the correct result.

How it works

The protocol is chosen against a threat model. A semi-honest model assumes parties follow the protocol but will learn whatever they can from what passes through them. A malicious model assumes they may deviate in order to break the computation or extract data — a stronger guarantee at a higher cost.

Most protocols split into two phases:

• Preprocessing. Input-independent material such as correlated randomness or garbled circuits is generated in advance, which is the expensive part.
• Online. Once the real inputs exist, the parties combine them with the preprocessed material. This phase is fast and needs comparatively little communication.

Implementation notes

Start with a maintained framework such as MP-SPDZ rather than implementing a protocol yourself. Choose the threat model deliberately, because the performance difference between semi-honest and malicious security is large and the guarantee is not the same.

Budget for the network. SMPC is usually communication-bound rather than compute-bound, so round-trips between parties dominate the runtime, and parties in different regions change the picture entirely. In crypto, the most common production use is threshold signing for custody and multi-party wallets.

7. Key management systems

A key management system (KMS) handles the lifecycle of cryptographic keys: generation, storage, rotation, access control, and destruction. AWS KMS, Azure Key Vault, and HashiCorp Vault are the common platforms.

The point is that raw key material never leaves the system. Rather than embedding a key in code or a configuration file, an application asks the KMS to perform an operation with it. That reduces the attack surface to the KMS's own access policy, and gives a single place to audit.

How it works

A KMS is anchored in a root of trust, usually a hardware security module holding the master keys that encrypt everything else. Around that sit three functions:

• Generation and storage. Strong random keys, stored encrypted under a master key, in a durable and highly available environment.
• Access control. Policies stating which identity may use which key for which operation.
• Audit logging. A record of every key use, for investigation and compliance reporting.

Implementation notes

Grant least privilege first: a service that needs to decrypt with one key should be able to do that and nothing else.

Then plan the failure cases, which is where KMS deployments actually hurt. A KMS outage takes down everything depending on it, so high availability and disaster recovery are not optional. A lost master key is unrecoverable by design, so a key escrow and recovery procedure has to exist before it is needed. Set rotation schedules, and alert on anomalous key use rather than reviewing logs after the fact.

The seven compared

Where to start

• Build one thing end to end. A working TLS handshake between two sockets, or a hash-linked chain of blocks with signature verification, teaches more than reading about either. Keep it small enough to finish.
• Then go deep in one area. Zero-knowledge circuit design and post-quantum migration are both specialist skills. Depth in one is worth more than breadth across all seven.
• Contribute to something that exists. An established open-source cryptography project will have bugs, gaps in documentation, and test coverage to extend. That is also how you get your work reviewed by people who know more than you.
• Write down what you built and why. A README explaining the design decisions, including the ones that turned out wrong, is worth more than a repository with no explanation.

Roles that need this work sit mostly under engineering listings, and what those roles pay is on the salaries page.