Zeroing memory on free

tobyjaffey · December 26, 2024, 11:35pm

I have some code which handles sensitive data. I’m manually zeroing important items using std.crypto.secureZero(), but eventually I’m going to forget something.

All of my allocations are made in a per-session arena allocator, is there a way I can get at the arena before destruction and just zero it entirely?

I can see how to do this with a FixedBufferAllocator, but then I lose dynamic sizing. Perhaps there’s a way to hook an allocator to zero as each item is freed?

andrewrk · December 26, 2024, 11:55pm

github.com/ziglang/zig

use case: constant time operations for crypto

opened 04:50PM - 23 Nov 18 UTC

andrewrk

proposal accepted research

Here's a simple example of this problem: Let's say you're writing a password …checker. Your algorithm looks like: ```zig // vulnerable function fn checkPass(hashed_password: []const u8, guessed_password: []const u8) bool { // assume hashed_password.len == guessed_password.len for sake of example for (hashed_password) |byte, i| { if (guessed_password[i] != byte) return false; } return true; } ``` This is vulnerable to a timing attack. The early return in the for loop allows the attacker to measure the statistical difference in duration for various passwords, and eventually guess every byte of the hashed password. This is just one example; timing attacks are a fundamental challenge when writing robust cryptographic algorithms. The reason that this is a special use case is that it breaks from a foundational premise in the rest of Zig: that the goal of the compiler is to interpret the semantic meaning and then emit whatever machine code it can to make it go fast. Here the goal is different: make it go the same amount of time regardless of the input. Typically crypto implementations resort to using hand-written, hand-verified assembly code for this, because the optimizer cannot be trusted given that it does not share the premise of constant time code. So I'd like to research what it would look like to support this use case at the language level in Zig. My first thought is to have something like this: ```zig timeconst { // in this block all math operations become constant time // and it is a compile error to call non timeconst functions } ``` This block would guarantee that all code inside it completes in the same amount of time regardless of the inputs to the block. If this guarantee could not be satisfied then there would be a compile error. We would probably need some builtin primitives such as `@timeConstMemCompare`, as calling `std.mem.eql` would cause a compile error, since that function does not have the `timeconst` property. One thing that a comprehensive proposal should do before getting accepted is look at a real world project, such as BoringSSL, and port the constant time parts of it to the proposal's semantics, to prove that the semantics would be applicable and useful.

The language cannot handle this use case correctly until something like this is implemented.

tobyjaffey · December 27, 2024, 7:38am

This whole issue thread is fascinating, even if I don’t understand all of the detail.

From a pragmatic point of view, I was planning to handle this app-side rather than relying on the language by adding small randomised delays around crypto operations to help prevent timing attacks.

I am not a crypto/security expert, and certainly won’t be making claims about the real-world safety of my code. However, I’m finding std.crypto (mostly) very capable and understandable for my uses.

Regardless, my original question was about zeroing memory automatically on free. I’ve just stumbled on this great set of example allocators which I think explains most of what I need GitHub - nektro/gimme: A yummy collection of useful Allocators.