diff --git a/assets/sass/_content.scss b/assets/sass/_content.scss
index 4d22693..025d838 100644
--- a/assets/sass/_content.scss
+++ b/assets/sass/_content.scss
@@ -189,7 +189,7 @@ table.table {
 
         .text {
             margin-left: 2px;
-            text-decoration: underline;
+            text-decoration: none;
         }
 
         &:hover {
diff --git a/content/posts/2022-03-03-clangd-in-nix.md b/content/posts/2022-03-03-clangd-in-nix.md
new file mode 100644
index 0000000..ca8918f
--- /dev/null
+++ b/content/posts/2022-03-03-clangd-in-nix.md
@@ -0,0 +1,34 @@
++++
+title = "Clangd in Nix"
+date = 2022-03-03
+tags = ["nixos"]
++++
+
+I've been using [Nix][NixOS] a lot recently since it handles dependency
+management very cleanly, but one gripe that I've been having is that when I'm
+doing C/C++ development work using `nix develop`, all my dependencies are
+actually in the Nix store in `/nix`, so my [clangd] editor plugin won't be able
+to find them.
+
+Fortunately, clangd supports looking for a file called `compile_commands.json`,
+which describes the compilation commands used for each file, with absolute paths
+for all dependencies.
+
+For [CMake]-based projects, there's an option to dump this information
+automatically into the build directory, which I typically then symlink into my
+project's root directory for my editor to find and apply to my files. Here's the
+snippet:
+
+```cmake
+# Generate the `compile_commands.json` file.
+set(CMAKE_EXPORT_COMPILE_COMMANDS ON CACHE INTERNAL "")
+
+if(CMAKE_EXPORT_COMPILE_COMMANDS)
+  set(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES
+    ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES})
+endif()
+```
+
+[NixOS]: https://nixos.org/
+[clangd]: https://clangd.llvm.org/
+[CMake]: https://cmake.org/
diff --git a/content/posts/2022-03-03-learn-by-implementing-elliptic-curve-crypto.md b/content/posts/2022-03-03-learn-by-implementing-elliptic-curve-crypto.md
new file mode 100644
index 0000000..8d6c10a
--- /dev/null
+++ b/content/posts/2022-03-03-learn-by-implementing-elliptic-curve-crypto.md
@@ -0,0 +1,106 @@
++++
+title = "Learn by Implementing Elliptic Curve Crypto"
+date = 2022-03-03
+tags = ["crypto", "learn-by-implementing"]
+draft = true
+math = true
+toc = true
++++
+
+Good places to start (in terms of usefulness):
+
+- [A relatively easy to understand primer on elliptic curve cryptography][2] by Cloudflare
+- [Elliptic-curve cryptography][3] from Practical Cryptography
+- [Elliptic-curve cryptography][1] on Wikipedia
+
+[1]: https://en.wikipedia.org/wiki/Elliptic-curve_cryptography
+[2]: https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/
+[3]: https://cryptobook.nakov.com/asymmetric-key-ciphers/elliptic-curve-cryptography-ecc
+
+I'm writing this post because there's a lot of good posts out there introducing
+the elliptic curve formula, but not many that continue with getting from there
+to actually encrypting and decrypting messages. Maybe this is a good thing for
+discouraging people from writing insecure ECC implementations and using them in
+production, but it's not great for understanding the algorithm.
+
+> **DISCLAIMER:** I'm not a cryptographer! This is not a cryptographically
+> secure implementation, only used to demonstrate how the algorithm works. Read
+> [the SafeCurves intro][4] for some of the attacks a custom ECC implementation
+> may overlook.
+
+[4]: https://safecurves.cr.yp.to/index.html
+
+## Basic Ideas
+
+ECC starts with the idea that starting with an elliptic curve formula like $y^2
+= x^3 + ax + b$ that operates over a finite field $\mathbb{F}_p$, and defining a
+_custom_ addition operation over two points, you can form a cyclic structure
+where adding a point to itself some number of times gets you back where you
+started.
+
+The interesting thing about this cyclic structure is that given the starting
+point $G$, also called the **generator** and some number $n$, you can find the
+$n$th element of that cycle $n \times G$ really quickly (in $\log(n)$ time). But
+if you're only given $G$ and $n \times G$, you can't figure out what $n$ is
+unless you brute force every possible number $n$ could be.
+
+What cryptographers have done is develop several sets of curve parameters that
+are publicly known, that include $a$, $b$, and the generator point $G$. Then
+users of the curve will just pick some $n$ and publish $n \times G$, and because
+of the difficulty of the elliptic curve discrete logarithm problem, $n$ will
+remain secret.
+
+There's some constraints on the properties of the curve parameters and $G$, but
+I won't go too far into that here since the proven curves have satisfies all
+those constraints.
+
+Once we have the curve and a keypair, there's all sorts of different
+cryptographic schemes that we can now build on top of these foundations:
+
+- Encryption
+- Signatures
+- Diffie Hellman
+
+## Implementation
+
+I'll be implementing this using [Go]. I chose it for the ability to define
+methods out of order and independently of their associated structs, as well as
+their built-in big-integers library. This is required for compiling the Go
+module:
+
+[Go]: https://go.dev/
+[Markout]: https://git.mzhang.io/michael/markout
+
+```go
+package elliptic
+import (
+  "math/big"
+)
+```
+
+> You can run this blog post using [Markout]:
+> ```
+> markout -l go content/posts/2022-03-03-learn-by-implementing-elliptic-curve-crypto.md > /tmp/ecc.go
+> go run /tmp/ecc.go
+> ```
+
+### Math primitives
+
+```go
+type CurveParams struct {
+  P *big.Int
+}
+
+
+```
+
+## Cryptographic applications
+
+These are some of the cryptographic primitives you can build over the above
+implementation.
+
+### Encryption
+
+### Signatures
+
+### Key exchange