Frank DENIS random thoughts.

00f.net · English

Frank DENIS blog

atom

Open the feed

https://00f.net/atom.xml

Last post: Sep 8, 2026
Posts in 24 h · 7 days · 30 days: 0 · 0 · 2
Our last check: Answering
Served from: France
Format: atom

Posts

What our queue read from this feed. Open one to read it here, or go to the site that published it.

Semi-public Git repositories
Sep 8, 2026 · original
Okay, maybe I’m just messy, but I’m sure the story below will resonate with a lot of developers. It often starts with a small file I’m not planning to commit. I’m trying something, so I write a test. Or I figure out how to deploy the project to one of my servers and put the commands in a script. It assumes my directory layout, my set of installed tools, and probably something I’ve forgotten to document, but it works for me. That’s all I need from it. Then I add some notes about things to fix or try, along with an idea for a feature that might go nowhere. None of this is ready to publish, but it belongs with the project, so I keep it in the checkout. After a while, my checkout looks pretty different from what someone gets by cloning the repository. The public code is there, along with all the little things that help me maintain it. And those little things stick around. They show up every
Base84 deserves a place in file names
Sep 8, 2026 · original
The TurboCrypt git and file encryption tool was originally designed for Unix systems. And it used to encrypt file names and encode the resulting ciphertext using Base91. Why Base91? Because it’s a perfect fit for encrypted file names, producing strings that can be stored as valid files on Unix and macOS. “But my filesystem can store arbitrary file names”! That may be true for some filesystems, but this is without taking libraries and applications into consideration. For example, the macOS Finder would not like this at all. So, Base91 worked fine for encrypted file and directory names. Then people asked for Windows support, where several characters in the Unix filesystem-safe alphabet are forbidden. So, TurboCrypt is switching to Base84. Something surprisingly not defined nor (apparently) used anywhere, even though it’s a perfect fit for anything that should be encoded as portable filesys
Why compiling Rust to WebAssembly is slow
Aug 18, 2026 · original
Compiling Rust to WebAssembly with debug info is slower than it should be. Sometimes unbearably slower. For example, here’s a 40-line Rust reproducer that takes 50 seconds to build with debug info and 1.5 seconds without it. This reproducer was reduced from a crate ( ed25519-compact ) where enabling debug info made compilation ~40x slower, but the bug itself is broader and affects all Rust code compiled to WebAssembly to varying degrees. This is actually a known LLVM bug that had already been reported and fixed for clang . But the fix is incomplete. Debug info becomes records in the instruction list Cargo has a debug setting to control debug info. debug = 2 asks LLVM for full DWARF information, which very few people use in practice with WebAssembly, but which people like to enable anyway (if only because debug = true is an alias for debug = 2 ). This debugging data is designed for profil
An improved attack on 7-round AES
Jul 29, 2026 · original
Recently, Milad Nasr and Nicholas Carlini used an AI model to improve an earlier attack on seven-round AES-128 . And Satoru Kanno (@satokan3) wrote a great explanation of the result in Japanese . Here’s a walkthrough based on his blog post and my understanding of the results, in English. TLDR: Don’t panic. It’s an incremental improvement to an impractical reduced-round attack. Full AES-128 remains unaffected. But what’s interesting is how the researchers used an AI model to find the improvement. What the result actually covers Standard AES-128 has ten rounds. But this attack stops after seven. So, this is not the real cipher. But studying reduced-round ciphers is a common practice in order to better understand the security margin of a primitive. A better attack on seven rounds is useful research, but it says nothing alarming about the complete cipher. The attack also needs about 2^105 ca
AES gets swizzled
Jul 15, 2026 · original
There’s an old problem with AES when implemented in software: it’s either slow or insecure. AES has a state of sixteen bytes, and a round has four steps: SubBytes replaces every byte using the AES S-Box. ShiftRows moves bytes to different columns. MixColumns combines the four bytes in each column. AddRoundKey XORs another sixteen-byte value. And SubBytes is the annoying part, because it applies a random-looking permutation to every byte: SBox(0x00) = 0x63 SBox(0x53) = 0xed ... An obvious way to implement that is by using lookup tables. But here’s the problem: the lookup indices are secret data, and accessing a cache line that was just accessed and is still in the cache is slightly faster than accessing other addresses. Taking advantage of this, an adversary on the same machine can learn information about the secret indices. For example, DJB recovered AES keys from remote timings , and Os

Discovered by the rss-feed-index crawler, which checks each feed at most once a month.

Same record as JSON: https://api.agentalog.com/api/feeds/fd_00f_net_7df6c254c1b28802. More from this site: 00f.net in the Feeds tab.