Eli Grubb · All Writings

Saying the obvious thing

Eli Grubb — Sun, 28 Jun 2026 00:00:00 GMT

https://www.seangoedecke.com/saying-the-obvious-thing/

I think the bigger reason it’s hard is for the same reason that it’s hard to draw what you actually see. When I look at a person and try to draw them, I’m not drawing the lines and shades my eye sees… I’m drawing what I know the person looks like, which is a kind of stick-figure approximation. It takes time and effort to drop the layer of interpretation and draw what’s actually there.

So you want to deploy FN-DSA

Eli Grubb — Thu, 14 May 2026 00:00:00 GMT

https://keymaterial.net/2026/05/13/so-you-want-to-deploy-fn-dsa/

For the most part, I agree with my fellow cryptography engineers that the best approach to using FN-DSA is to not. However, prohibition is a failed approach, whether we are talking about drugs or about cryptography, so, in the interest of harm reduction, here are the essential caveats for anyone who wants to use FN-DSA, so that they can do so as safely as possible.

Proxies all the way down

Eli Grubb — Mon, 27 Apr 2026 00:00:00 GMT

https://dadrian.io/blog/posts/exe-github/

I played around with exe.dev this weekend and I’m loving it so far - hopefully I’ll find the brain space to write about my adventures. In the meantime, this post from David Adrian demonstrates why exe.dev is worth paying attention to among the ocean of ai-hyped infra bets: it’s all in the details.

Open source security at Astral

Eli Grubb — Sun, 26 Apr 2026 00:00:00 GMT

https://astral.sh/blog/open-source-security-at-astral

For no particular reason, I got around to finally reviewing this article from the uv maintainers. Excellent advice.

Quantum Computers Are Not a Threat to 128-bit Symmetric Keys

Eli Grubb — Mon, 20 Apr 2026 00:00:00 GMT

https://words.filippo.io/128-bits/

A good reminder.

The Future of Everything is Lies, I Guess

Eli Grubb — Wed, 15 Apr 2026 00:00:00 GMT

https://aphyr.com/posts/411-the-future-of-everything-is-lies-i-guess

Modern ML models are astonishingly capable, and they are also blithering idiots. This should not be even slightly controversial.

Kyle Kingsbury recently released the last section of this excellent essay. One of the better attempts to find a common ground between nuance and truth in this rapidly shifting new world. Too much for one sitting? The pdf and epub options are great!

Some humans are full of LLM-generated material now too—a sort of cognitive microplastics problem.

Thoughts on slowing the fuck down

Eli Grubb — Wed, 25 Mar 2026 00:00:00 GMT

https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/

From Mario Zechner, the creator of the pi coding agent. One of the better actors when it comes to forming nuanced takes on this rapidly changing, grifter friendly world.

A tale about fixing eBPF spinlock issues in the Linux kernel

Eli Grubb — Wed, 18 Mar 2026 00:00:00 GMT

https://rovarma.com/articles/a-tale-about-fixing-ebpf-spinlock-issues-in-the-linux-kernel/

Large-Scale Online Deanonymization with LLMs

Eli Grubb — Mon, 02 Mar 2026 00:00:00 GMT

https://www.schneier.com/blog/archives/2026/03/llm-assisted-deanonymization.html

via Schneier on Security

Did recent events leave you wondering “how could LLMs be useful for spying on citizens”? Here’s just one concrete example.

We show that from a handful of comments, LLMs can infer where you live, what you do, and your interests – then search for you on the web. In our new research, we show that this is not only possible but increasingly practical.

Check out the full paper for details.

Buddy Guy: Tiny Desk Concert

Eli Grubb — Sat, 28 Feb 2026 00:00:00 GMT

https://youtu.be/m5XxOLdMSS8

Buddy Guy brought the house down at Tiny Desk, with a feature from rising-superstar Miles Caton.

Once again, thank you Sinners.

Please, please, please stop using passkeys for encrypting user data

Eli Grubb — Fri, 27 Feb 2026 00:00:00 GMT

https://blog.timcappalli.me/p/passkeys-prf-warning/

When you overload a credential used for authentication by also using it for encryption, the ‘blast radius’ for losing that credential becomes immeasurably larger.

Cryptography Engineering Has An Intrinsic Duty of Care

Eli Grubb — Wed, 25 Feb 2026 00:00:00 GMT

https://soatok.blog/2026/02/25/cryptography-engineering-has-an-intrinsic-duty-of-care/

Zero Knowledge (About) Encryption

Eli Grubb — Tue, 24 Feb 2026 00:00:00 GMT

https://zkae.io/

Password managers are an important area with surprisingly little formal analysis and this work emphasized the importance of fixing that.

To be presented at Real World Crypto 2026 and published at USENIX Security 2026.

Full paper can be found here: https://eprint.iacr.org/2026/058.

Bitwarden’s blog post on the subject is here: https://bitwarden.com/blog/security-through-transparency-eth-zurich-audits-bitwarden-cryptography/¹.

Bad Bunny: Tiny Desk Concert

Eli Grubb — Sun, 08 Feb 2026 00:00:00 GMT

https://youtu.be/ouuPSxE1hK4

A super bowl chaser. The only thing more powerful than hate is love.

Fancy cryptography in the wild🎩

Eli Grubb — Sun, 08 Feb 2026 00:00:00 GMT

https://github.com/fancy-cryptography/fancy-cryptography

via Bas Westerbaan

A curated and crowdsourced list of ~*fancy*~ cryptography protocols, currently deployed at scale.

Some rabbit holes I’m falling down:

WhatsApp Encryption, a Lawsuit, and a Lot of Noise

Eli Grubb — Tue, 03 Feb 2026 00:00:00 GMT

https://blog.cryptographyengineering.com/2026/02/02/whatsapp-encryption-a-lawsuit-and-a-lot-of-noise/

It’s been more than forty years since Ken Thompson delivered his famous talk, “Reflections on Trusting Trust“, which pointed out how there is no avoiding some level of trust. Hence the question here is not: should we trust someone. That decision is already taken. It’s: should we trust that WhatsApp is not running the biggest fraud in technology history.

Look for what's true

Eli Grubb — Sun, 01 Feb 2026 00:00:00 GMT

https://dubroy.com/blog/look-for-whats-true/

Advice as old as time but I often forget. Placed well in the context of today’s workplace.

So, You’ve Hit an Age Gate. What Now?

Eli Grubb — Thu, 22 Jan 2026 00:00:00 GMT

https://www.eff.org/deeplinks/2026/01/so-youve-hit-age-gate-what-now

The EFF also has an age verification resource hub. As usual, it’s full of good resources and advice.

LLMs and your career

Eli Grubb — Tue, 20 Jan 2026 00:00:00 GMT

https://notes.eatonphil.com/2026-01-19-llms-and-your-career.html

The jobs that were dependent on fundamentals of software aren’t going to stop being dependent on fundamentals of software … if you like doing software development, I don’t think interesting software development jobs are going to go away.

The State of OpenSSL for `pyca/cryptography`

Eli Grubb — Wed, 14 Jan 2026 00:00:00 GMT

https://cryptography.io/en/latest/statements/state-of-openssl/

Daniel Caesar: Tiny Desk Concert

Eli Grubb — Thu, 08 Jan 2026 00:00:00 GMT

https://youtu.be/rMWjbb2l5BE

Daniel Caesar returned to Tiny Desk this week 😌

Also worth revisiting his first appearance from 2018: https://youtu.be/PBKa-AAy_vo

University of Utah finds tape with only known copy of UNIX V4 hidden in storage

Eli Grubb — Wed, 07 Jan 2026 00:00:00 GMT

https://www.sltrib.com/news/education/2026/01/07/university-utah-finds-tape-with/

Hidden in storage, a University of Utah research associate happened upon the only known copy of this ‘revolutionary’ software

Stories like this revitalize my love for computing PLUS it’s great seeing the Flux research group highlighted 🫶.

Internet Security Research Group (ISRG) 2025 Annual Report

Eli Grubb — Tue, 06 Jan 2026 00:00:00 GMT

https://www.abetterinternet.org/documents/2025-ISRG-Annual-Report.pdf

A cool reminder that Let’s Encrypt, Divvi Up, and Prossimo are all run by the same org.

What can strong engineers do that weak engineers can't?

Eli Grubb — Tue, 06 Jan 2026 00:00:00 GMT

https://www.seangoedecke.com/weak-engineers/

One way to tell a weak engineer in a discussion thread about some problem is to see who is bringing in specific facts about how the system currently works, and who is making purely general recommendations that could apply to any system. If their messages could all be public tweets, they’re probably not adding much value.

Against Cipher Agility in Cryptography Protocols (2019)

Eli Grubb — Mon, 29 Dec 2025 00:00:00 GMT

https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols

Behind the Scenes with iOS Security (2016)

Eli Grubb — Mon, 29 Dec 2025 00:00:00 GMT

https://blackhat.com/docs/us-16/materials/us-16-Krstic.pdf

Ivan Krstić at Black Hat 2016, video available

It's not your codebase

Eli Grubb — Mon, 29 Dec 2025 00:00:00 GMT

https://www.seangoedecke.com/not-your-codebase/

Signatures are like backups (2024)

Eli Grubb — Mon, 29 Dec 2025 00:00:00 GMT

https://alexgaynor.net/2024/sep/09/signatures-are-like-backups/

Key Transparency: Introduction, recent results, and active research areas - Melissa Chase

Eli Grubb — Tue, 23 Dec 2025 00:00:00 GMT

https://youtu.be/GKn0wqwQHCw

The legendary Melissa Chase recently gave a perfect introduction to Key Transparency, including recent results/active areas.

Building a Transparent Keyserver

Eli Grubb — Sat, 20 Dec 2025 00:00:00 GMT

https://words.filippo.io/keyserver-tlog/

Invisible Salamanders Are Not What You Think (2024)

Eli Grubb — Sat, 20 Dec 2025 00:00:00 GMT

https://soatok.blog/2024/09/10/invisible-salamanders-are-not-what-you-think/

Picking parameters (2022)

Eli Grubb — Sat, 20 Dec 2025 00:00:00 GMT

https://www.imperialviolet.org/2022/03/15/pickingparameters.html

Experimenting with Post-Quantum Cryptography

Eli Grubb — Wed, 19 Nov 2025 00:00:00 GMT

https://www.wolfssl.com/documentation/manuals/wolfssl/appendix07.html

Your job is to deliver code you have proven to work

Eli Grubb — Tue, 18 Nov 2025 00:00:00 GMT

https://simonwillison.net/2025/Dec/18/code-proven-to-work/

We need to deliver code that works—and we need to include proof that it works as well. Not doing that directly shifts the burden of the actual work to whoever is expected to review our code.

What Every Programmer Should Know about How CPUs Work • Matt Godbolt

Eli Grubb — Wed, 12 Nov 2025 00:00:00 GMT

https://youtu.be/-HNpim5x-IE

The Typestate Pattern in Rust

Eli Grubb — Fri, 07 Nov 2025 00:00:00 GMT

https://cliffle.com/blog/rust-typestate/

Cryptography-specific chaser: Implementing As-Safe-As-Possible, Misuse-Resistant Cryptographic Libraries: Part I.

clipping.: Tiny Desk Concert

Eli Grubb — Wed, 05 Nov 2025 00:00:00 GMT

https://youtu.be/h0-k7vW9Xek

Arenas in Rust (2021)

Eli Grubb — Thu, 16 Oct 2025 00:00:00 GMT

https://manishearth.github.io/blog/2021/03/15/arenas-in-rust/

Too Much Crypto (2019)

Eli Grubb — Sun, 05 Oct 2025 00:00:00 GMT

https://eprint.iacr.org/2019/1492.pdf

JP Aumasson on Too Much Crypto in 2025:

Too Much Crypto hasnt aged … [as expected, just diminishing returns from incremental high-complexity/memory cryptanalysis.]

Should I Switch From Git to Jujutsu?

Eli Grubb — Thu, 02 Oct 2025 00:00:00 GMT

https://etodd.io/2025/10/02/should-i-switch-from-git-to-jujutsu/

The UK Is Still Trying to Backdoor Encryption for Apple Users

Eli Grubb — Wed, 01 Oct 2025 00:00:00 GMT

https://www.eff.org/deeplinks/2025/10/uk-still-trying-backdoor-encryption-apple-users

Don't wait for FHE, encryption-in-use is possible today*!

Eli Grubb — Fri, 26 Sep 2025 00:00:00 GMT

* This post is an extension of a recent social media thread.*

Fully Homomorphic Encryption (FHE) is really cool! LaurieWired’s recent thread on the topic has great pointers, check-it-out!

However, FHE isn’t the only answer to “encryption-in-use”. Other solutions exist that are efficient, employ well-established cryptography, and are deployable today!

There is just one small catch:

Why not FHE?

FHE’s draw comes from its universality, it’s called fully homomorphic encryption for a reason. But performance concerns in practical use are real.

Laurie references the recent speedups; unfortunately most of the breakthroughs fail to address the complexity inherent to FHE, instead optimizing constant factors.

For example, Zama’s recent blog post¹ cites impressive speed ups to 64-bit encrypted addition and multiplication, clocking in at 8.7 milliseconds and 32 milliseconds per operation, respectively.

That’s a real performance improvement and awesome to see! I recommend you check out the full post for all the juicy details.

But Zama’s experiments were on an AWS hpc7a.96xlarge instance, with 192 cores and 768 GiB of memory,² so let’s compare it with unencrypted add and mul on Apple’s 2020 M1 chip.

An M1 addition is ~1 cycle, and multiplication is ~3 cycles.³ On a 3.2Ghz chip, a.k.a. 3.2 billion cycles per second, that’s 0.3125 nanoseconds or 0.0003125 microseconds or 0.0000003125 milliseconds per add. And 0.9375 nanoseconds or 0.0009375 nanoseconds or 0.0000009375 milliseconds per mul. This doesn’t take into account the M1’s multiple cores or the CPU’s internal parallelism.⁴

That’s a 27,840,000-34,133,133X gap between FHE and unencrypted computation, and the gap only grows more plain as the computation grows in complexity.⁵

However, many people much smarter than I are all in on FHE, and I’m still bullish on it long term.

If not FHE, then what?

So what can we do, in practice, today?

The term fully homomorphic encryption begs the question, is there such a thing as partially or somewhat homomorphic encryption? Yes!

System design is all about compromise. By softening some of FHE’s guarantees (universal applicability, specific security properties) other approaches gain performance. While these schemes aren’t universal, they address a large percentage of the everyday computation many businesses are doing. And many only have a performance overhead of 5-30%!

Searchable Encryption

An underrated approach is Searchable Encryption (SE). With SE, you can search, filter, and perform analytics on structured data. SE isn’t applicable to every possible computation over encrypted data, but some of the most common (sum, avg, count, min, max) have realistic solutions.⁶

From startups like Blind Insight⁷ to big companies like MongoDB’s Queryable Encryption,⁸ searchable encryption is about to hit production-ready.

Oblivious RAM

“Oblivious” computation comes from relaxing the strict security guarantees of encryption.

While encryption guarantees complete secrecy, oblivious schemes only guarantee indistinguishability from “similar” computation patterns. Your data and operations aren’t completely private, but you still get a haze of deniability in return for performance gains.⁹ ¹⁰ Oblivious RAM (ORAM) is an oblivious scheme built for general computation.¹¹

There’s even brand new research that combines SE and ORAM techniques to enable semantic text search over encrypted data via a privacy-preserving Retrieval Augmented Generation (RAG) system.¹² RAGs are a hot topic today due to their relevance in vector databases and LLMs. End-to-end encrypted vector database soon? 👀

Somewhat Homormorphic Encryption

It turns out, Somewhat Homomorphic Encryption (SHE) is a real, formally defined, thing! Instead of restricting the type of encryption, SHE sets a maximum on the complexity of the possible computations over encrypted data.

By setting a upper bound at initialization, cryptographic system designers can make assumptions that allow for optimizations to the total system’s performance complexity.

SHE is still an emerging area of research, gaining popularity in recent years, with regular exciting theoretical breakthroughs.¹³

Conclusion

I didn’t even scratch the surface on the nifty tricks and applications of these schemes. And there are other, adjacent, techniques I didn’t have time to mention.¹⁴

Feedback: If you’re interested in any research I’ve mentioned here, if I forgot your favorite primitive/protocol, or if you’d like to disuss anything related to applied cryptography and systems send me an email.

A Tour of WebAuthn (2024)

Eli Grubb — Wed, 24 Sep 2025 00:00:00 GMT

https://www.imperialviolet.org/tourofwebauthn/tourofwebauthn.html

Shooting Moving Masters Zemeckis Style (2021)

Eli Grubb — Mon, 22 Sep 2025 00:00:00 GMT

https://youtu.be/lhyV097_Q-g

Don't write bugs

Eli Grubb — Fri, 19 Sep 2025 00:00:00 GMT

https://www.teamten.com/lawrence/programming/dont-write-bugs.html

`TIGER_STYLE`

Eli Grubb — Wed, 17 Sep 2025 00:00:00 GMT

https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TIGER_STYLE.md

Add asserts everywhere.

Also see matklad’s What is an Invariant?.

Burroughs' B6500/B7500 stack mechanism (1968)

Eli Grubb — Tue, 16 Sep 2025 00:00:00 GMT

https://people.eecs.berkeley.edu/~culler/courses/cs252-s05/papers/burroughs.pdf

Lord of the `io_uring`

Eli Grubb — Wed, 10 Sep 2025 00:00:00 GMT

https://unixism.net/loti/index.html

`Scrypt` is Maximally Memory-Hard (2016)

Eli Grubb — Wed, 10 Sep 2025 00:00:00 GMT

https://eprint.iacr.org/2016/989.pdf

Inside Zig's New Writer

Eli Grubb — Wed, 03 Sep 2025 00:00:00 GMT

https://joegm.github.io/blog/inside-zigs-new-writer-interface/

"Clean" Code, Horrible Performance (2023)

Eli Grubb — Tue, 26 Aug 2025 00:00:00 GMT

https://youtu.be/tD5NrevFtbU

TIL: Testing Secure Zeroization in Zig with Custom Memory Allocators

Eli Grubb — Wed, 20 Aug 2025 00:00:00 GMT

or, How Zig’s explicit memory management makes it easy to test your sanitization guarantee

While spending the summer learning Zig I have come to love and appreciate one of the language’s core philosophies: what you see is what you get.

In Zig, there’s no operator overloading and memory allocations are always explicit. Simply reading the code should reveal exactly what your software is instructing the computer to do. If a library allocates memory, the idiomatic approach is to accept a memory allocator as an input, so callers can pick the memory management strategy that matches the end use-case.

There are exceptions,¹ and other languages have reasons they allow such abstractions, but I’ve enjoyed working in this style. It aligns well with my current interests and experience. When I return to other, more “sugary”, languages, using Zig has improved my feel for where the “hidden” allocations and functionality are.

An idea begins to form

In particular, this is useful for testing that your custom memory management strategies are, actually, working. My first “real” Zig project, the Zecrecy library, zeros out sensitive data before freeing the memory to mitigate the impact of Heartbleed-style vulnerabilities.

Because Zig is explicit and its docs are still maturing, you are reading the standard library’s source code by the time you build much more than “hello world”.² I’d read the code for the std.mem.Allocator interface, along with several of the allocator implementations in the standard library, so I felt confident enough to try it when the idea popped into my head: a custom allocator that panics if asked to free non-zero memory.

Of course, this is not a novel idea. I learned it from the Zig Standard Library’s testing Allocator, a nifty implementation that takes advantage of Zig’s memory management paradigm. In testing, use std.testing.allocator when a call requests a memory allocator. The test will panic if the allocator detects any memory leaks during testing.³

To improve Zecrecy’s testing quality, I wrote ZerosOnlyAllocator. It’s pretty simple, it wraps a child allocator to handle the actual allocations. This has a couple benefits:

I don’t have to write my own allocation logic just for a bit of testing, and
If the child allocator is std.testing.allocator, then I get memory-leak detection in the same test run!

The core “functionality” lies in the free() function:

/// Panics if the memory is not zeroed before freeing.
fn free(
    ctx: *anyopaque, 
    buf: []u8, 
    alignment: mem.Alignment, 
    ret_addr: usize
) void {
    const self: *ZerosOnlyAllocator = @ptrCast(@alignCast(ctx));
    for (buf) |byte| {
        if (byte != 0) @panic("non-zero byte freed");
    }
    self.child_allocator.rawFree(buf, alignment, ret_addr);
}

I love this kind of thing because it only gains value the more tests I add. Test setup is only three lines:

const ZerosOnlyAllocator = @import("testing/ZerosOnlyAllocator.zig");
var zeros_only_allocator: ZerosOnlyAllocator = .init(std.testing.allocator);
const allocator = zeros_only_allocator.allocator();

Now, every single test automatically verifies our core security guarantee with zero additional effort.

Debugging detour

Except! The first time I ran unit tests using the shiny, new, custom allocator, every single test panicked:

~/zecrecy> zig test src/secret.zig
thread 3381248 panic: non-zero byte freed
~/zecrecy/src/testing/ZerosOnlyAllocator.zig:59:24: 0x104dbc753 in free (test)
        if (byte != 0) @panic("non-zero byte freed");
                       ^
~/.cache/zig/p/N-V-__8AAPWKhxNMNK6YniIioDpRryBzI7DMp0hJB4rExlGU/lib/std/mem/Allocator.zig:147:25: 0x10236238f in free__anon_5332 (test)
    return a.vtable.free(a.ptr, memory, alignment, ret_addr);
                        ^
~/zecrecy/src/secret.zig:120:34: 0x10235e12b in deinit (test)
            secret.allocator.free(secret.data);

Turns out, my assumption that reading the standard library once makes one an expert was, unsurprisingly, wrong. The custom allocator’s logic was correct, but the standard library contained some unexpected functionality that broke my assumptions:

/// From `std.mem.Allocator`:
///
/// Free an array allocated with `alloc`.
/// If memory has length 0, free is a no-op.
/// To free a single item, see `destroy`.
pub fn free(self: Allocator, memory: anytype) void {
    const Slice = @typeInfo(@TypeOf(memory)).pointer;
    const bytes = mem.sliceAsBytes(memory);
    const bytes_len = bytes.len + 
                      if (Slice.sentinel() != null) @sizeOf(Slice.child) else 0;
    if (bytes_len == 0) return;
    const non_const_ptr = @constCast(bytes.ptr);
    @memset(non_const_ptr[0..bytes_len], undefined);
    self.rawFree(non_const_ptr[0..bytes_len], .fromByteUnits(Slice.alignment), @returnAddress());
}

All tests panicked because std.mem.Allocator.free⁴ writes undefined into freed memory before calling .rawFree. In Debug and ReleaseSafe modes Zig fills undefined bytes with a debug pattern (0xAA) to catch use-after-free bugs,⁵ which meant my test allocator saw non-zero bytes.

The solution? Bypass the layer altogether and call .rawFree() directly.⁶ Now, we can verify zeroization at the layer closest to deallocation.

mem.Allocator.free does what it does for a reason, and I don’t skip it lightly. The name .rawFree is meant to make you nervous. For example, in Debug or ReleaseSafe mode, setting all bytes to undefined means you get some use-after-free protection that we could be losing by calling .rawFree instead.

However, in this case, I felt comfortable with this choice after familiarizing myself.

The first three lines of Allocator.free are because memory can be anytype, so the code verifies memory is a slice, handles a potential sentinel, etc. This the only function I call .rawFree in is .deinit, which only accepts slices. No @typeInfo magic needed.

What about the @memset? Zecrecy uses standard library’s crypto.secureZero function to wipe memory, which uses techniques intended to avoid optimization removal. However, those techniques have their own flawed history and corner cases. Test reinforcement is always valuable, never take security for granted.

Outside of actually calling .rawFree, the only change I is to return early if the data length is 0. This has no security/correctness benefits but offers a small performance bump by avoiding the virtual function call when it’s not needed. Due to the nature of the library (how often will someone will be initializing a secret of length 0?), I think even if I had skipped this no-op opportunity, the .rawFree call is fine.

And boom! All tests pass:

~/zecrecy> zig test src/secret.zig
All 15 tests passed.

With each one, I can feel a tiny bit better knowing all secrets were actually zeroed before they were freed.

Conclusion

The effort required was low for the value gained, I’ve barely scratched the surface of using custom memory allocators to improve testing.⁷ Reducing the “black box” opaqueness that sometimes hangs like a fog over unit tests is a nice tool to have. I’m optimistic that Zig’s upcoming async/IO changes will provide similar opportunities to get surgical during testing.

And, of course, building test harnesses that enforce application invariants is far from unique to Zig. It’s a powerful technique with demonstrated value. Zig’s win, for me, is in making every decision explicit and shoving the reality of an implementation into your face at all times. You naturally think deeper about how to wield the verbosity in your favor.

Have any cool, weird, or otherwise nerdy uses you’ve gotten out of Zig’s memory management explicitness? Do you have a favorite method for testing your system’s security guarantees? Send me an email or a message!

TL;DR:

Zig 0.15.1 Release Notes

Eli Grubb — Wed, 20 Aug 2025 00:00:00 GMT

https://ziglang.org/download/0.15.1/release-notes.html

Shredding Your Garbage: Reducing Data Lifetime Through Secure Deallocation (2005)

Eli Grubb — Mon, 18 Aug 2025 00:00:00 GMT

https://www.usenix.org/legacy/publications/library/proceedings/sec05/tech/full_papers/chow/chow.pdf

From USENIX Security 2005!

without [secure deallocation], data can remain in memory for days or weeks, even persisting across reboots.

The span from first write to last read is the ideal lifetime. The data must exist in the system at least this long. The span from first write to deallocation is the secure deallocation lifetime. The span from first write to the first write of the next allocation is the natural lifetime. Because programs often rely on reallocation and overwrite to eliminate sensitive data, the natural lifetime is the expected data lifetime in systems without secure deallocation.

Jujutsu For Busy Devs

Eli Grubb — Mon, 04 Aug 2025 00:00:00 GMT

https://maddie.wtf/posts/2025-07-21-jujutsu-for-busy-devs

Zero Knowledge Proofs Alone Are Not a Digital ID Solution to Protecting User Privacy

Eli Grubb — Wed, 30 Jul 2025 00:00:00 GMT

https://www.eff.org/deeplinks/2025/07/zero-knowledge-proofs-alone-are-not-digital-id-solution-protecting-user-privacy

High-assurance zeroization (2023)

Eli Grubb — Tue, 29 Jul 2025 00:00:00 GMT

https://eprint.iacr.org/2023/1713.pdf

TIL: compile with a locally patched Zig standard library via `--zig-lib-dir`

Eli Grubb — Fri, 25 Jul 2025 00:00:00 GMT

alt-title: find a way to narrow down the scope of your comparisons (and compilations).

While benchmarking the impact of Zig removing inlines from their standard cryptography library, my naive initial approach compared the changes from the perspective of the Zig project as a whole, not just the standard library itself. In reality, this meant every time I modified a Zig crypto implementation while experimenting, even just to call std.debug.print, I was rebuilding the entire project from source.

The Zig build system feels powerful and I’m planning out a new project to coat myself in all the grimy details¹. In the meantime, I got started with Loris Cro’s excellent Zig Build System Basics video, and the existing documentation. I followed the Zig wiki’s instructions for building from source on both mac and linux.

But, of course, there’s a flag for that:

$ zig build --help

Usage: zig build [steps] [options]

...

Advanced Options:
  ...
  --zig-lib-dir [arg]          Override path to Zig lib directory
  ...

We can input the path of the lib directory containing an instantiation of the Zig standard library and zig build will compile without extra steps or linking. Now instead of feeling stuck at the bird’s eye view of the entire Zig source, it’s much easier to quickly compare and contrast the small nudges and curiosities.

Just call:

zig build --zig-lib-dir ../zig-master/lib

Those familiar with the ziglang codebase may note that the directory for the standard library isn’t lib/, it’s lib/std/. This means that --zig-lib-dir allows us specify a lot more than just the standard library for injection, we’re just scratching the surface here².

Benchmarking changes is much smoother now. I simply point my script to the appropriate git worktree directory for each version and away we go!

Madrid Culture Nuances

Eli Grubb — Thu, 05 Sep 2019 00:00:00 GMT

Last Updated: 05-September-2019

I am spending this fall in Madrid working at the IMDEA Software Institute with Dario Fiore. This is my first time in Europe and I feel extremely lucky that it is for an extended period of time so I have a chance to shallowly experience daily life here.

This post is an on-going, incomplete, extremely biased look at the little and unique things I’ve noticed about the culture here compared to what I am used to.

Obviously there is no scientific rigour behind any of this. These are just things that stood out to me with my background of being raised in Utah and having fairly recently moved to the Washington D.C. area and what things I have happened to notice. What I’ve noticed may not actually true. Or maybe where I’m from is the same way and I have just been ignorant to that fact. This is all very subjective and is more a collection of anecdotes than a document meant to inform.

The personal space bubble is much smaller here. Whether sitting or standing, whether on the metro or in line or at a park, the standard bubble of personal space seems smaller here. Just enough smaller that you notice how often people end up there. It’s taken some getting used to that strangers are comfortable being that close even when they don’t necessarily have to be.

Madridians love to sit. If there is an open seat on the metro, it is immediately taken by the next passenger. Related to my previous point, it doesn’t matter if there are people in the seats beside it, you take the open seat. When someone gets up from a bus bench or a metro seat if there are people standing by they immediately fill the new opening. In my experience on metros in the US people are just as likely to stand as to sit directly next to a stranger. That is not a problem here.

There is much more smoking in public spaces. I have heard that the rates of smoking are very high here and that pretty much everyone smokes. I have had no experience to confirm or deny that. However, there is a definite increase in the number of people smoking in public areas. I am not sure if the concept of a designated smoking area is a thing here.

Dinner really is eaten very late. It’s definitely been an odd experience for me to find that when it’s warm it doesn’t matter if it’s 11pm on a Tuesday night, as you walk around the streets of Madrid you will find many people eating dinner and drinking wine at outdoor seating from restaurants and bars. You generally don’t have to walk more than 10-15 minutes to find a restaurant that is at least 80% full at that time.

There is no rush or promptness in day to day life. Everything moves somewhat slowly. Most meetings are held “around” a time instead of at a specific time. There is a common attitude of things will happen when they happen. Unless the next metro train is about to leave. Then you must full on sprint to take it because suddenly waiting 5 minutes for the next one would be too much.

There are very few fat people here. As an overweight person I have noticed that in fact, yes, obesity is a very American problem. I don’t see many other fat people and I certainly do not see any my age. I believe I have gotten more than a few stares for being a member of such a small group.

They refer to their metro lines by number. This may not be weird for other Americans who have lived in other cities, but both the public light rails in Salt Lake City and Washington D.C. are colloquially referred to by the line’s color. However, due to the size of the city and the resulting metro system, it becomes hard to refer to the “blue line” when there are several shades of blue. Instead you would ask whether someone had taken the 10 or the 5 to get there.

Odd tcsh issue on alpine linux [UPDATED]

Eli Grubb — Mon, 05 Feb 2018 00:00:00 GMT

I’m currently working with alpine linux, trying to port some existing systems over to this minimal OS. It’s not an easy task. Currently my issue is with tcsh. It seems that tcsh is triggering some kind of core dump every time it is called. Here’s the output when it’s called:

(nil) current memory allocation:                                                                                
free:       0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0                       
used:       0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0                       
        Total in use: 0, total free: 0                                                                          
        Allocated memory from 0x55bd1509d000 to 0xffffffffffffffff.  Real top at 0x55bd1509d000                 
nbytes=64: Out of memory

I’ve been googling and going through alpine’s bug tracker but there’s no mention of tcsh in there system beside the day they committed it to their repository. It is worth noting that the package is currently in the testing branch of their apk package manager so there were no guarantees. It is interesting that there seems to be literally no evidence anyone else has run into this issue. Also somewhat intriguing is the fact that the alpine maintainers have no documented interest in moving tcsh to a stable branch anytime soon. I agree that it’s probably an outdated tool, but still popular enough it should have higher priority.

If anyone has any potential solutions shoot me an email.

UPDATE (February 12, 2018):

Having submitted the bug to the Alpine Linux issue tracker, I received a pointer to a patch in the openwrt project that seems to fix this issue. At the very least, tcsh actually boots and seems to function as a shell once it’s applied. I’m going to work on either getting the patch committed to the actual alpine package repo or build a custom tcsh for my system with the patch.

UPDATE 2 (February 27, 2018):

This patch has now been committed to alpine’s apk repository. This took a little more effort than expected, and there’s definitely still some open issues with the package before it can be moved from the edge branch to the main package repo branch. As referenced in the linked github PR, the musl libc appears to break a lot of basic functionality in tcsh. As you can see here the number and nature of regression tests failed is somewhat alarming. However, by hand testing shows that basic functionality needed for my project works. Who knows, maybe it will convince some old-timers to switch to a more modern shell like bash ;).

It does however, bring up an interesting conversation about whether there is sufficient motivation for these issues to ever be fixed. The last few remaining active tcsh developers have no desire to work to get their package working with an upstart libc like musl and musl developers have no motivation to work on supporting a shell none of their target users actively rely on. I think my work has fallen into a rather small demographic.

Alpine Package Names

Eli Grubb — Wed, 08 Nov 2017 00:00:00 GMT

As part of my research work in the Flux Research Group I’ve been working very closely with Alpine Linux. My current project involves translating a bunch of scripts for building a particular Ubuntu image into the same process for an Alpine image. As such, I’ve had the fun of finding packages in Alpine’s apk package manager that are currently being installed through apt-get. This is just a quick post to serve as a reference for inconsistencies I’ve found across the two, and the packages I installed instead.

Ubuntu (16.04)	Alpine (3.6)
libtool-bin	libtool
libssl-dev	openssl-dev
libboost-dev	boost-dev
iputils-ping	iputils
perl-modules	???
libwww-perl	perl-libwww
tcsh	tsch@testing*
ksh	mksh
brctl	bridge-utils

* tcsh is currently only found in the testing branch of apk. You have to add the link to the testing branch to /etc/apk/repositories as described here.

If anyone has any corrections, questions or additions to this short list feel free to reach out to me on twitter or by email.

Some Thoughts... On Designing My New Site

Eli Grubb — Thu, 30 Mar 2017 00:00:00 GMT

It has been a while. How are you? I’m tired. It’s almost 2am here.

I’m hoping to post more here now, both about Computer Science based topics and about other things that peak my interest.

This is the first of a couple “Some Thoughts…” posts that are going to come out over the next few days. I’ve been thinking about a lot lately and trying to put more of it down.

I spent most of the night tonight redesigning/rebuilding my personal homepage. I wanted to build a page that would best help me in my path forward. I based the design off of Andy Pavlo’s site, Edward Yang’s site, my old homepage and just the general design and organization I’ve seen PhD students use.

One of the points in Matt Might’s amazing undergrad CS major advice column that’s always hit hardest with me is his emphasis of a portfolio over a resume. While building out my new homepage I’m trying to focus on that idea. My goal is a nice-looking, simple page that allows people to easily get to know me and my experience. However, since my long term goals more and more involve academia, I’m also trying to emphasize my research experience and give it a look that is familiar for those who have experience with academic personal sites.

The tweaking will continue for the foreseeable future. I’ve also come across how barren my side projects section is. In the near future I plan to build out a user level threads library and I’ll add it to the list once it’s semi-functional. Over the summer I’m also planning on building a rudimentary DBMS as I study the designs of database kernels, so that will be added as well.

Anyways, I believe it’s a huge improvement over its old form. Hopefully this more accurately represents who I am.

On Rejection

Eli Grubb — Wed, 29 Mar 2017 00:00:00 GMT

I wrote a post a while back about my experience interviewing with Microsoft for an internship in the Fall of 2015. I never got around to updating my blog, but I did not get an offer.

Instead, I spent last summer interning at Goldman Sachs. Excuse me, I wasn’t an “intern”, I was a “Technology Summer Analyst”. Let me tell you, I still hate putting that title on my resume.

Goldman Sachs was an okay experience. I met some really cool people there, especially my fellow interns. However, the culture was a major turn off. While the internship experience was great, the impression I got from my time there was that full time employees were often overworked and in the long term, the growth and learning of employees was not a priority. It didn’t help that the full time offer I received at the end of the summer was nothing to write home about.

This last fall I interviewed around again, planning for another internship for this coming summer. Another year older and wiser too, I had slightly more success in my efforts.

I received an offer from Instructure who had declined me last year.
I received an offer from Qualtrics who I had turned down last year.
I got to a final round interview with Facebook but they ultimately decided not give me an offer.
My resume was once again swallowed up by Google’s black hole.

And, once again, I got to a final round interview with Microsoft. I flew out to Seattle this past fall and really enjoyed my stay. I got to visit my cousin (he’s since moved to the bay area) and one of the days it was raining so I went and enjoyed the water.

The interview portion of the trip went well too, I thought. I had three interviews, all with very great people. They were part of the Office 365 team working on the web version of Microsoft’s Office products. While I won’t go into detail like my last post, these are the basics of my interview questions:

Given two strings of character trees, one preorder and one in order, recreate the tree.
Given an array of size N, containing the integers from 0 to N, find all that are missing. For both the case where each number exists once and where numbers can be repeated.
Given a 2D array filled with Xs representing walls, and an S representing the start and an E representing the end, find the shortest path from S to E.

I have never felt so confident coming out of an interview as I did that afternoon. I had nailed every question and felt like I had a reasonable connection with all my interviewers for the time spent together.

I waited eagerly to see if I would get an offer from Microsoft. My buddy Tanner received his offer from Microsoft the day of the interview, but I went back to my hotel room empty handed.

I waited until the end of the next week with no response. I sent a follow-up email to my recruiter, who asked for my patience.

Another week, another email.

And again.

Then, exactly one month to the day, I finally received an email confirming that Microsoft wouldn’t be moving forward with an offer at this time. It hurt. While last year I could name 20 different mistakes and moments of frustration, this time had felt different. It hurt all the more because I have no idea what I would do differently even if I could hit the redo button.

The timing didn’t help either. I had to extend my offer from Qualtrics and was in a weird place interviewing with Facebook because I was strung along for a full month after my interview, despite being told I would hear back in less than two weeks.

Rejection is a bitch. When you get your hopes up and they’re cut from under you, that fall hurts. There is no getting around it.

I ended up accepting Qualtrics’ offer, so I’ll be spending my summer in Provo. I’m excited about experiencing a more startup-esque, free flowing culture than I’m used to. I’m less excited about the city. I’m grateful for the opportunity and can’t wait to see what adventures await me.

It still stings. But there’s nowhere to go but up. And one rejection doesn’t mean the end of the world. And, unfortunately, there’s a whole lot of rejection in my future, especially considering my career choice. An entire world of possibilities is still ahead of me. Can’t wait to see what’s next.

gitignore_global

Eli Grubb — Fri, 02 Oct 2015 00:00:00 GMT

I need git for every change I make anywhere on my computer apparently.

Today while working on a project for CS 3500 I ran into a curious bug that made me wonder what in the world I was thinking at the time.

In trying to commit some .dll files as resources to my Visual C# app in Visual Studio I came to the odd realization that they weren’t actually included in my repo. Curious.

It got even weirder when I manually right-clicked and added it to my git. Yet when I clicked commit I got an error claiming that I wasn’t committing any files even though they were both RIGHT THERE. Curiouser and curiouser.

Finally I was able to debug my issues when I happened upon some extremely helpful git commands thanks to this stack overflow post.

Using the described techniques I found a file in my Documents folder (no where near or associated with my C# development) titled “gitignore_global”. This document explicitly set git to ignore several visual studio specific files including, you guessed it, *.dll.

I renamed the file and what do you know? It all committed nice and easy now! WOO HOO!

I still have no idea why I created that file in the first place. And why in my Documents folder that has nothing to do with any of my development projects??

I’m still scratching my head. Oh well. I guess that’s better then banging it against my desk in frustration.

Sometimes even the best technologies are just plain dumb.

Interviewing with Microsoft

Eli Grubb — Wed, 16 Sep 2015 00:00:00 GMT

Yesterday I had the amazing opportunity to interview with one of the most prolific software companies in the world: Microsoft.

A few weeks back a couple of Microsoft Reps visited Campus and I gave them my resume. Last week I received a call from a Microsoft rep to set up an on campus interview. This post is just to detail what it was like and some of the questions I was asked to help others prep for similar situations.

Scattered through the interview were the typical job interview questions:

“Why do you want to work for Microsoft?”
“Tell me about a time you had trouble in a group?”
“Tell a me a bit about yourself.”
ETC.

In the 30ish minute interview there were also 2 problem solving questions.

Problem #1: ftoa

The first was to build a ‘ftoa’ function. That is a method that takes in a string like “1234” or “25” and returns the integer form of it: 1234 or 25.

Answer:

The solution is pretty simple once you think about it:

public static int myStringToInteger(String str) {
	int answer = 0, factor = 1;
	for (int i = str.length()-1; i >= 0; i--) {
		answer += (str.charAt(i) - '0') * factor;
		factor *= 10;
	}
	return answer;
}

It’s just based on the ASCII values of char’s that are integers being the same distance from ‘0’ as that integer really is from 0.

Now, this method does contain an error. Ints are inherently 32-bit and you have a risk of overflow. Since these are signed integers that will occur once answer > 2^31 - 1. For your own little brain teaser, see how you would handle dictating this as a Long (which is basically a 64-bit integer). The twist is you can only use ints.

HINT: Instead of answer, use two values like int answerHi and int answerLo to detail the more significant 32-bits and less significant 32-bits respectively.

Problem #2: Lightbulb Dropping

The other problem solving question was a logic puzzle.

Let’s assume your research department built a lightbulb that is supposed to be ‘indestructible’. Obviously, you are skeptical of this claim and decide to test it for yourself.

You have access to a 100 story building and exactly 2 of these lightbulbs. (They are really expensive)

Using just these supplies how can you test what floor the lightbulb will break at when dropped?

And, how can you optimize this algorithm to minimize the number of drops in the worst case scenario?

For the record, you can develop and optimize an algorithm down to where the worst case scenario is 19 drops.

I’ll give you a minute to work it out.

HINT: What happens if you drop a lightbulb and it doesn’t break?

Answer:

Now, the simplest algorithm is to realize that if you drop a lightbulb and it doesn’t break, you can drop it again! So if you start at floor one and successively move up dropping it at each floor until it breaks you will know exactly what floor it can no longer survive the landing force. However, worst case scenario, you are going to be dropping this lightbulb 100 times! Let’s make use of both of our lightbulbs and optimize the number of drops.

Optimizing it is simple. Let’s say you deside to drop the first lightbulb every 5 levels. When it breaks you simply need to do the original algorithm from the last known safe level. I.e. if you drop your lightbulb and it’s safe at levels 5, 10, 15, 20, and 25 but breaks on 30 all you need to do is take your second lightbulb and drop it at levels 26, 27, 28 and 29 to see which level is the breaking point! If it doesn’t break at any of those levels then you know that level 30 is the breaking point.

Of course this would result in a worst case scenario of 24 drops. To get rid of those last few drops it turns out dropping from every 10th floor results in the best worst case scenario.

Conclusion:

All in all, it was a very enlightening experience. I would like to thank Microsoft for the opportunity to interview with them and everyone cross your fingers that I hear back from a recruiter in 3 weeks time.

Wish me luck!

Testing Class Libraries with C# in Visual Studio

Eli Grubb — Tue, 08 Sep 2015 00:00:00 GMT

When building a Class Library for my CS 3500 class we are required to build our own little testing suites on our machines. These tests aren’t to be uploaded to the GitHub repository for our project, but obviously it is necessary if we want to build a functioning program. As this is my first foray into the world of C# and, more importantly, Visual Studio, I found it slightly difficult to figure out out to write even rudementary Console Application tests for my Class Library. This post is to act as a reminder as to how to successfully add a ConsoleApplication Project to a solution and use it to test a Class Library.

Note: This was done using Visual Studio 2015 Enterprise and any differences in your setup is probably a result of this

Once you have your initial Class Library created with a class and method you would like to test, you will find yourself to run any tests within the same project. Due to Class Librarys compiling down to .dll files and not something like a .exe there is no way to run that project directly. Instead you need to create another project that does compile down to a .exe and have it reference your Class Library

The first thing you will do is select File -> New -> Project…

In this case I am testing my project using a Console Application so I will choose Visual C# -> Windows -> Console Application as my application type.

It doesn’t matter what your project’s name is, but for simplicity I suggest using the format Test. In this case since I’m working on a Class Library called Formula Evaluator I’m naming my Console Application FormulaEvaluatorTest.

Make sure it’s in the same location as your Class Library Project and add to the existing solution to ensure continuity.

After you create this new project it will open up it’s Program.cs file which contains what this whole process is about, the Main Function. Now you have a program that can actually execute operations. However, you are not quite done.

To ensure you have access to your Class Library in your new project, in the Solution Explorer right-click on your Console Application and select Add -> Reference…

Select Projects -> Solution from the left hand column and find your Class Library in the center pane. Make sure that it’s checkbox is checked, then hit OK. You should now be able to write the line using MyClassLibrary in your console application without any errors.

You are just about done. But wait! When you attempt to run your Console Application, you probably end up with this error:

Your solution is automatically choosing your Class Library to run when you run the solution as a whole and this just doesn’t work. Like we discussed earlier, since Class Libraries compile down to a .dll file you cannot run it. You need to run the .exe file that your Console Application compiles down to.

To change this you simple right-click on your Console Application and select Set as StartUp Project

Now when you hit the Start button on the top toolbar to run your solution, it is your Console Application that will run.

Happy (C#) Hacking!

UPDATE 9/16:

I finally learned how to do this with unit tests. And I feel rather silly now that I’ve been taught. Simply replicate my process but instead of selecting a console application, select the “Tests” category on the left and choose a Unit Test Application. Unit Tests are so much better than testing with a Console Application and I’m not looking back. But that’s mainly because of how silly I feel not knowing how to use unit tests before.

Hello World

Eli Grubb — Mon, 07 Sep 2015 00:00:00 GMT

Welcome to my world

On this blog I will be discussing things that either interest me or bug me. Mostly this will consist of software and general Computer Science issues, but there may be other things that crop up. I’m glad you could join me.

The Power of an Artist

Eli Grubb — Thu, 01 Aug 2013 00:00:00 GMT

October 9, 2018: This post is an old draft of mine on Medium, written sometime in mid-2013. It has now been moved here, for the record and your groans.

I have recently become interested in what an artist is. I maybe even slightly thought I could be one.

But, how?

So, I looked up the definition of artist: “a person who produces works in any of the arts that are primarily subject to aesthetic criteria” or “a person whose work exhibits exceptional skill”.

The thing is, that doesn’t satisfy me.Because, while I know that we all can be artists, and I know that we all could do work that “exhibits exceptional skill”, true artists are not just about showing off what they’ve done. They’re about much, much more.

We are all contributing in one way. We all have to power to effect other’s lives, and even cause everlasting changes. But, once again, how? How can we do something that alters the very destiny of those around us? Because it’s only when we create something that makes a difference, that we can truly call ourselves an artist.

One of my favorite artists once said:

See life’s a beautiful struggle, I record it

Hope it helps you maneuvering through yours

Whatever our medium is, this is all we can do before we become an artist.

Whether you’re a rapper, a singer, a musician,

Whether you’re a painter, a sculptor, a sketcher,

Whether you’re an author, a journalist, a writer,

Whether you’re a politician, a speaker, a leader,

Whether you’re a programmer, a CEO, a visionary,

Whether you’re a architect, a fashion designer, or a wedding planner,

No matter who you are, or what you do:

You can be an artist.

As soon as your work becomes not about making the money, or making a name for yourself, but about the lives of the people who experience your work everyday, that’s how you know. That’s when you become an artist, and that is when you feel, and can exercise the power of one. They are powerful, I promise. The artists are the ones who will shape and effect the future of this planet. They’re the ones who you should be friends with. Or better yet, become an artist yourself.

If Only You Would Just Ask

Eli Grubb — Mon, 29 Jul 2013 00:00:00 GMT

October 9, 2018: This post originally appeared on Medium. It has now been moved here.

I adore my little 3-year old cousin Brooklynn. She has me wrapped around her little finger. She’s an adorable girl, and I’d do anything for her, but today I learned an important lesson from her.

We were racing around my driveway, her on her cute little pink princess bike. Her mother, my aunt, calls to her, it’s time for her to come inside to eat dinner.

As Brooklynn hops up and runs off towards her mother, I gently remind her that she needs to put her bike away.

“Can you please put my bike away Eli?” she sweetly asks me.

Of course I can. How can I say no to adorable little Brooklynn?

And yet, as I walked away, carrying the pink princess bike, I consider what I had just done. Was I creating a spoiled personality, rotten and expected others to serve her? Was I making life too easy for her, leading her to expect everything to be done for her in life?

Then something occurred to me. There was a key difference to our interaction then there was to those of one who is spoiled.

She had asked me to put the bike away.

All too often you worry about seeming out of hand. You worry about upsetting other people around you. It bothers you to think that your request, your needs could be a bother to someone else.

But if you would just ask, whole worlds of possibility can open up to you.

You should never be afraid to ask when you are in need of something.

What’s the worst they can say? “No”?

If you aren’t willing to ask others for help when you need it, you are going to be left carrying everything on your own shoulders. Why would you do everything by yourself, be forced to find your own out of the way solution to your problems, when a simple question, a plea for help can have it possibly solved so much quicker?

A 2008 study by US National Library of Medicine found that we as people are far too pessimistic when it comes to the success of asking:

“People underestimated by as much as 50% the likelihood that others would agree to a direct request for help”

Why are we so afraid, so determined that everyone is out to refuse us? As people, we cannot and should not get hung up on the idea that others don’t want to help us. We should want to help others, and at least hope that others want to help us.

The difference between being spoiled and being someone who is willing to ask for help, is that simple question. By asking that question, Brooklynn was showing that she wasn’t spoiled brat who expects everything to be done for her, but a polite girl who is willing to ask for help when she feels she needs it.

At least I like to think so.

Eli Grubb · All Writings

Saying the obvious thing

So you want to deploy FN-DSA

Proxies all the way down

Open source security at Astral

Quantum Computers Are Not a Threat to 128-bit Symmetric Keys

The Future of Everything is Lies, I Guess

Thoughts on slowing the fuck down

A tale about fixing eBPF spinlock issues in the Linux kernel

Large-Scale Online Deanonymization with LLMs

Buddy Guy: Tiny Desk Concert

Please, please, please stop using passkeys for encrypting user data

Cryptography Engineering Has An Intrinsic Duty of Care

Zero Knowledge (About) Encryption

Bad Bunny: Tiny Desk Concert

Fancy cryptography in the wild🎩

WhatsApp Encryption, a Lawsuit, and a Lot of Noise

Look for what's true

So, You’ve Hit an Age Gate. What Now?

LLMs and your career

The State of OpenSSL for pyca/cryptography

Daniel Caesar: Tiny Desk Concert

University of Utah finds tape with only known copy of UNIX V4 hidden in storage

Internet Security Research Group (ISRG) 2025 Annual Report

What can strong engineers do that weak engineers can't?

Against Cipher Agility in Cryptography Protocols (2019)

Behind the Scenes with iOS Security (2016)

It's not your codebase

Signatures are like backups (2024)

Key Transparency: Introduction, recent results, and active research areas - Melissa Chase

Building a Transparent Keyserver

Invisible Salamanders Are Not What You Think (2024)

Picking parameters (2022)

Experimenting with Post-Quantum Cryptography

Your job is to deliver code you have proven to work

What Every Programmer Should Know about How CPUs Work • Matt Godbolt

The Typestate Pattern in Rust

clipping.: Tiny Desk Concert

Arenas in Rust (2021)

Too Much Crypto (2019)

Should I Switch From Git to Jujutsu?

The UK Is Still Trying to Backdoor Encryption for Apple Users

Don't wait for FHE, encryption-in-use is possible today*!

Why not FHE?

If not FHE, then what?

Searchable Encryption

Oblivious RAM

Somewhat Homormorphic Encryption

Conclusion

A Tour of WebAuthn (2024)

Shooting Moving Masters Zemeckis Style (2021)

Don't write bugs

TIGER_STYLE

Burroughs' B6500/B7500 stack mechanism (1968)

Lord of the io_uring

Scrypt is Maximally Memory-Hard (2016)

Inside Zig's New Writer

"Clean" Code, Horrible Performance (2023)

TIL: Testing Secure Zeroization in Zig with Custom Memory Allocators

An idea begins to form

Debugging detour

Conclusion

Zig 0.15.1 Release Notes

Shredding Your Garbage: Reducing Data Lifetime Through Secure Deallocation (2005)

Jujutsu For Busy Devs

Zero Knowledge Proofs Alone Are Not a Digital ID Solution to Protecting User Privacy

High-assurance zeroization (2023)

TIL: compile with a locally patched Zig standard library via --zig-lib-dir

Madrid Culture Nuances

Odd tcsh issue on alpine linux [UPDATED]

Alpine Package Names

Some Thoughts... On Designing My New Site

On Rejection

gitignore_global

Interviewing with Microsoft

Problem #1: ftoa

Answer:

Problem #2: Lightbulb Dropping

Answer:

Conclusion:

The State of OpenSSL for `pyca/cryptography`

`TIGER_STYLE`

Lord of the `io_uring`

`Scrypt` is Maximally Memory-Hard (2016)

TIL: compile with a locally patched Zig standard library via `--zig-lib-dir`