DEV Community: Khaled Hani

How We Increased Shannon Entropy Throughput in Go by 41% Using a Lookup Table.

Khaled Hani — Sun, 16 Aug 2026 07:01:00 +0000

How We Increased Shannon Entropy Throughput in Go by 41% Using a Lookup Table.

Author: Khaled Hani

Repository: Crenox

When building a high-performance Git secret scanner, every microsecond matters.

A pre-commit hook runs on a developer's workstation before every commit, so the scanner has to do a lot of work without adding noticeable latency to the development workflow.

Crenox uses a three-tier detection pipeline:

Tier 1: Aho-Corasick pattern matching across 125+ known provider patterns.
Tier 2: Shannon entropy analysis for high-randomness candidates such as generic tokens, hashes, and credentials.
Tier 3: Context-aware verification to reduce false positives from test fixtures, mock data, and non-secret identifiers.

During optimization of the entropy stage, we found an important opportunity: the standard Shannon entropy formula performs repeated floating-point operations inside a hot loop.

The solution was not CGo, Assembly, or unsafe code.

It was algebra.

By rewriting the entropy equation and precomputing a small lookup table, the benchmark below shows a 41.4% increase in throughput, while maintaining 0 heap allocations per operation.

The Bottleneck: Shannon Entropy in a Hot Loop

Shannon entropy is commonly defined as:

H (X) = - i = 1 \sum k P (x_{i}) lo g_{2} P (x_{i})

For a byte slice, we can define:

n as the total number of bytes.
cᵢ as the number of occurrences of byte value i.
P(xᵢ) = cᵢ / n as the empirical probability of that byte.

A straightforward Go implementation looks like this:

func ShannonNaive(data []byte) float64 {
    if len(data) == 0 {
        return 0
    }

    var freq [256]int

    for _, b := range data {
        freq[b]++
    }

    n := float64(len(data))
    var entropy float64

    for _, count := range freq {
        if count == 0 {
            continue
        }

        p := float64(count) / n
        entropy -= p * math.Log2(p)
    }

    return entropy
}

The implementation is perfectly valid.

The problem is that the calculation happens repeatedly for every non-zero byte frequency.

For each distinct byte, the hot loop performs:

a floating-point conversion,
a floating-point division,
a math.Log2 calculation,
and additional floating-point arithmetic.

When this function is called hundreds of thousands of times, those operations become worth optimizing.

The Mathematical Insight: Factor Out "n"

The key observation is that the probability is:

P (x_{i}) = \frac{c _{i}}{n}

Substituting that into Shannon entropy gives:

H (X) = - c_{i} > 0 \sum \frac{c _{i}}{n} lo g_{2} (\frac{c _{i}}{n})

Now use the logarithm identity:

lo g_{2} (\frac{a}{b}) = lo g_{2} (a) - lo g_{2} (b)

Therefore:

H (X) = - c_{i} > 0 \sum \frac{c _{i}}{n} [lo g_{2} (c_{i}) - lo g_{2} (n)]

Expanding the expression:

H (X) = - \frac{1}{n} c_{i} > 0 \sum c_{i} lo g_{2} (c_{i}) + \frac{lo g _{2} ( n )}{n} c_{i} > 0 \sum c_{i}

Every byte in the input contributes exactly once to the frequency table, so:

c_{i} > 0 \sum c_{i} = n

This simplifies the second term:

\frac{lo g _{2} ( n )}{n} c_{i} > 0 \sum c_{i} = \frac{lo g _{2} ( n )}{n} \cdot n = lo g_{2} (n)

The entire entropy calculation therefore becomes:

H (X) = lo g_{2} (n) - \frac{1}{n} c_{i} > 0 \sum c_{i} lo g_{2} (c_{i})

This is mathematically equivalent to the original Shannon entropy formula.

Why is this useful?

The original implementation calculates:

(count / n) × log₂(count / n)

inside the loop.

The rewritten form only needs:

count × log₂(count)

for each frequency.

More importantly, count is an integer with a bounded range.

That gives us an opportunity to precompute the expensive part.

The Optimization: A Precomputed Lookup Table

For the fast path, we target inputs up to 512 bytes.

The frequency of any individual byte can never exceed the total input length.

Therefore, when:

n <= 512

we know that:

1 <= cᵢ <= 512

We can precompute:

f (x) = x lo g_{2} (x)

for every possible frequency.

In Go:

var xLog2xTable [513]float64

func init() {
    for i := 1; i <= 512; i++ {
        xLog2xTable[i] = float64(i) * math.Log2(float64(i))
    }
}

The table contains 513 float64 values:

513 × 8 bytes = 4,104 bytes ≈ 4.01 KiB

That's a very small amount of memory for eliminating repeated logarithm calculations from the hot path.

The Optimized Implementation

The resulting implementation uses the lookup table for inputs up to 512 bytes and keeps the original mathematical calculation as a fallback for larger buffers:

func Shannon(data []byte) float64 {
    n := len(data)

    if n == 0 {
        return 0
    }

    var freq [256]int

    for _, b := range data {
        freq[b]++
    }

    // Fast path for inputs <= 512 bytes.
    if n <= 512 {
        var sum float64

        for _, count := range freq {
            if count > 0 {
                sum += xLog2xTable[count]
            }
        }

        return math.Log2(float64(n)) - (sum / float64(n))
    }

    // Fallback path for larger inputs.
    fn := float64(n)
    var entropy float64

    for _, count := range freq {
        if count > 0 {
            p := float64(count) / fn
            entropy -= p * math.Log2(p)
        }
    }

    return entropy
}

There are two important details here.

1. Why is the table `[513]` instead of `[512]`?

Go arrays are zero-indexed.

A [513]float64 array provides indexes:

0 ... 512

If the input contains 512 copies of the same byte, then:

count = 512

and the implementation needs:

xLog2xTable[512]

Therefore, [513]float64 is the correct size.

2. Why do we need a fallback?

The LUT only covers frequencies up to 512.

For larger inputs, a byte frequency can exceed 512.

Instead of making the lookup table arbitrarily large, we use the original calculation for those inputs.

This keeps the optimization bounded while preserving correctness for larger buffers.

Edge Cases

The implementation also handles the important boundary conditions.

Empty input

n = 0

The function returns:

H(X) = 0

before performing any logarithm calculation.

One-byte input

For:

data = "A"

the only frequency is:

c₁ = 1

Since:

lo g_{2} (1) = 0

the entropy is:

H(X) = 0

Repeated byte

For a buffer containing only "A":

AAAAAAAA...

there is only one possible symbol, so entropy is zero regardless of the length.

Two equally frequent bytes

For:

AB

both symbols have probability 1/2, giving:

H (X) = - (\frac{1}{2} lo g_{2} \frac{1}{2} + \frac{1}{2} lo g_{2} \frac{1}{2}) = 1

The 512-byte boundary

At:

n = 512

the LUT path is used.

At:

n = 513

the fallback path is used.

Both paths implement the same mathematical definition of Shannon entropy.

Benchmark Results

We compared the standard implementation with the LUT-based implementation using Go's benchmark tooling:

go test -bench=. -benchmem

The benchmark run produced:

goos: linux
goarch: amd64
pkg: github.com/crenoxhq/crenox/v2/internal/entropy
cpu: Intel(R) Xeon(R) Platinum

BenchmarkShannonStandard-8       1456561     228.153 ns/op     0 B/op     0 allocs/op
BenchmarkShannonLUT-8            2041219     161.441 ns/op     0 B/op     0 allocs/op

Latency

The standard implementation takes approximately:

228.153 ns/op

The LUT implementation takes:

161.441 ns/op

The reduction in per-operation latency is:

\frac{228.153 - 161.441}{228.153} \approx 29.24%

So the LUT implementation reduces measured latency by approximately 29.2%.

Throughput

Throughput is inversely proportional to time per operation.

From the measured ns/op values:

Throughput_{standard} = \frac{1 0 ^{9}}{228.153} \approx 4.38 M operations/sec

and:

Throughput_{LUT} = \frac{1 0 ^{9}}{161.441} \approx 6.19 M operations/sec

Therefore:

\frac{6.19 M}{4.38 M} - 1 \approx 41.32%

That's approximately a 41.4% increase in throughput.

This distinction is important:

Latency reduction: ~29.2%
Throughput increase: ~41.4%

The N values shown by go test -bench are benchmark iteration counts. They should not be interpreted directly as operations per second.

Zero Heap Allocations

Both implementations report:

0 B/op
0 allocs/op

This means the benchmark observed zero heap allocations per operation.

The optimization therefore improves the computational path without introducing an allocation-heavy data structure or additional runtime dependency.

The frequency table remains a fixed-size array:

var freq [256]int

and the lookup table is also fixed-size:

var xLog2xTable [513]float64

Why the Optimization Works

The important part of this optimization isn't simply the lookup table.

The real performance improvement came from changing the structure of the computation.

The original formula repeatedly evaluates:

P (x_{i}) lo g_{2} (P (x_{i}))

The rewritten formula isolates the expensive component:

c_{i} lo g_{2} (c_{i})

And because cᵢ belongs to a small integer domain on the fast path, the result can be precomputed.

Instead of calculating:

float64(count) * math.Log2(float64(count))

every time, the hot loop performs:

xLog2xTable[count]

That is the central idea:

«Before optimizing the instructions, optimize the computation.»

Complexity Analysis

Both implementations still have the same asymptotic complexity.

For an input of length n:

Frequency counting: $\mathcal{O}(n)$
Entropy calculation: The alphabet is the 256 possible byte values: $\mathcal{O}(256)$

Since 256 is constant:

$$\mathcal{O}(n + 256) = \mathcal{O}(n)$$

So the LUT does not change the Big-O complexity.

Instead, it reduces the constant cost of the entropy calculation.

This is an important distinction in performance engineering:

«An optimization does not need to change Big-O complexity to produce a meaningful real-world speedup.»

Why Not Just Use a Huge Lookup Table?

A natural question is:

«Why stop at 512?»

We could build a much larger table, but there is a trade-off.

The goal is not to replace every possible input with a massive precomputed structure.

The goal is to optimize the common short-input path while keeping:

memory usage small,
initialization simple,
the implementation easy to understand,
and a correct fallback for larger inputs.

The 512-byte threshold is therefore an implementation choice that should be validated against the actual workload.

If profiling shows that larger candidates are common, the threshold can be revisited and benchmarked again.

What We Learned

This optimization reinforced a useful lesson about Go performance.

The first instinct when optimizing a hot path is often to think about:

Assembly
SIMD
unsafe code
CGo
compiler tricks

But none of those were necessary here.

The biggest opportunity was hidden in the mathematical representation itself.

We started with:

H (X) = - \sum P (x_{i}) lo g_{2} (P (x_{i}))

and transformed it into:

H (X) = lo g_{2} (n) - \frac{1}{n} \sum c_{i} lo g_{2} (c_{i})

That exposed a bounded integer input to the expensive part of the calculation.

Once that happened, a small lookup table became possible.

Practical Lessons for Go Performance Engineering

There are several general lessons here:

Optimize the algorithm before optimizing the instructions: A better mathematical formulation can eliminate work that no amount of low-level optimization can make free.
Look for bounded domains: If an expensive function only receives a small set of possible inputs, precomputation can be extremely effective.
Measure instead of assuming: A lookup table is not automatically faster. The only reason to keep this optimization is that the benchmark demonstrates a measurable improvement for the workload being tested.
Keep a safe fallback: The LUT is optimized for a bounded range, but larger inputs still need correct handling. A fallback keeps the optimization from becoming a correctness constraint.
Measure latency and throughput separately: A reduction in ns/op and an increase in throughput are related, but they are not the same percentage. Reporting both makes performance claims much easier to audit.

What This Means for Secret Scanning

Shannon entropy is useful as one signal in secret detection, particularly when dealing with high-randomness candidates that don't match known provider-specific patterns.

But entropy alone is not enough to determine whether a string is a secret.

A high-entropy string can be:

compressed data,
a hash,
an identifier,
generated test data,
or a legitimate random value.

That's why Crenox combines entropy analysis with pattern matching and contextual verification.

The optimization discussed here improves the cost of one component of that pipeline; it does not change the detection model itself.

Conclusion

High-performance Go code does not always require Assembly, CGo, or unsafe optimizations.

Sometimes the highest-leverage optimization starts with a mathematical equation.

In our case, we:

Rewrote the Shannon entropy formula to factor out the input length.
Reduced repeated calculations inside the hot loop.
Used a small lookup table for the bounded frequency range.
Preserved a fallback path for larger inputs.
Maintained zero heap allocations in the benchmark.
Measured a 29.2% reduction in per-operation latency.
Measured a 41.4% increase in throughput.

The complete implementation is part of Crenox on GitHub, an open-source security tool for detecting secrets before they reach your repository.

If you're interested in Go performance optimization, Shannon entropy, secret scanning, Git security, or DevSecOps tooling, the implementation is available for inspection and experimentation.

Final Note on the Benchmark

Benchmark results are dependent on the CPU, Go version, compiler, input distribution, and benchmark methodology.

The numbers in this article represent the specific benchmark run shown above. They should be treated as measured results for that environment, not as a universal speedup across every system.

For production performance work, run the benchmark multiple times and compare results with a statistical benchmark tool such as benchstat.

Repository: https://github.com/crenoxhq/crenox

[Boost]

Khaled Hani — Wed, 22 Jul 2026 05:38:25 +0000

Khaled Hani

Jul 22

Crenox – A pre-commit secret scanner 100 faster than Gitleaks (built with Flat DFA + Aho-Corasick in Go)

#programming #opensource #security #productivity

1 min read

Crenox – A pre-commit secret scanner 100 faster than Gitleaks (built with Flat DFA + Aho-Corasick in Go)

Khaled Hani — Wed, 22 Jul 2026 03:52:04 +0000

Hey Dev,
I built Crenox — a lightweight pre-commit security hook that prevents accidental commits of API keys, passwords, and credentials before they ever reach your repository.

The core philosophy is simple: stop secrets at the edge, not after the damage is done. Remediating a leaked secret costs ~13× more than preventing it.

What makes it different:

Instead of regex-based matching, Crenox uses a Flat DFA Engine combined with Aho-Corasick multi-pattern matching on 92 known secret signatures, followed by Shannon entropy analysis for unknown secrets, and context-aware false-positive suppression.

The numbers speak:

Scanned 697 files (14.7 MB) from the kubernetes/kubectl repo in 43ms (Gitleaks: 5.25s on the same repo) Scanned 4,804 files (44 MB) from the Django repo in 212ms (Gitleaks: 7.5s) Zero dependencies, zero config needed — single static binary, ~7.5 MB Supports crenox:ignore for false positives, .crenox.yaml for customization, SARIF output for CI/CD Works on Linux, macOS, Windows, and even Android/Termux

Built by one developer because I was tired of secret scanners that were either too slow for pre-commit use or too expensive to run on every PR.

GitHub: https://github.com/crenoxhq/crenox

Website: https://crenoxhq.github.io/crenox

I'd love to hear your feedback — especially from anyone who runs secret scanning at scale. What's your biggest pain point with current tools?

How My Open-Source Scanner Caught a Crypto Scammer Exposing Their Own Keys

Khaled Hani — Sat, 11 Jul 2026 06:37:35 +0000


Exposing the keys in the GitHub Issue	The Phishing Site (Notice the Spotify option)

There is a golden rule in cybersecurity: the weakest link is almost always human error. But what happens when that human error comes from a malicious actor trying to orchestrate a crypto phishing scam? The result is surprisingly comedic.

Here is the story of how my newly built open-source secret scanner, Sentinel, accidentally neutralized a Tether (USDT) phishing operation during a routine benchmark.

The Setup: Testing in the Wild

I recently released Sentinel, a statically compiled, context-aware Git secret scanner and pre-commit hook written in Go. After fine-tuning its engine to achieve near-zero false positives, I decided to benchmark it "in the wild" by scanning random, recently updated repositories on GitHub.
The goal was to see if Sentinel could catch edge-case credentials that traditional, regex-heavy tools often miss or drown in noise. During the scan, Sentinel instantly flagged a critical severity finding in a rather suspicious repository.

The Catch: AI Copy-Paste Gone Wrong

Upon inspecting the flagged file, the issue was immediately apparent: a fully exposed, hardcoded Firebase configuration object containing the API key, project ID, and messaging sender ID.
It was a textbook case of a script kiddie asking an AI for a web login template and blindly copy-pasting the frontend code into a public repository. They had effectively handed over the administrative keys to their backend infrastructure before the project even launched.

The Phishing Site: Logging into Crypto with Spotify?

Out of professional curiosity, I checked the Vercel deployment linked to the repository. The project was attempting to impersonate Tether (USDT), the world's largest stablecoin. It featured the official logo, a catchy slogan, and a login prompt designed to harvest credentials.
However, because the scammer had blindly copied a generic consumer application template, the authentication options presented to the victims were:

Continue with Google
Continue with Phone
Continue with Spotify Yes, the threat actor was attempting to steal cryptocurrency wallets by asking victims to authenticate via their music streaming accounts. It was a masterpiece of absolute incompetence.

The Confrontation

I could not let this slide. I navigated to the scammer's GitHub repository, opened a public Issue, and left them a piece of professional advice.
Issue Title: If you want to scam someone, you must first learn how to protect yourself.
Comment: "Ask the AI you used about the dangers of leaving this information public, you fool. Learn first before you experiment."
By exposing their keys publicly in the issue and highlighting the flaw, their Firebase project was flagged, effectively neutralizing the phishing attempt before it could claim any victims.

The Technical Takeaway

While the story provides a good laugh, it highlights a severe reality in modern software development:

AI Code Generation is a Double-Edged Sword: The blind reliance on AI-generated code without understanding environment variables (.env) is causing a massive spike in leaked secrets.
Standard Tools Miss Context: Many traditional scanners rely heavily on mathematical entropy and might ignore loosely structured configurations if they do not match strict regular expressions. This architectural flaw is exactly why I built Sentinel. It does not just look for random strings; it utilizes lexical context-awareness to catch hardcoded assignments. This ensures that whether you are a senior engineer making a late-night mistake or a clueless scammer copying code, your secrets are caught before they enter the version control history.

Secure Your Code (Don't be like our Tether guy)

If you want to ensure you never accidentally push your API keys, AWS credentials, or database connection strings to GitHub, take a look at Sentinel. It installs in seconds as a pre-commit hook and runs silently in the background, utilizing a three-tier detection pipeline built for speed.
🔗 Check out Sentinel on GitHub
If you enjoyed this case study, consider dropping a star on the repository, and let me know in the comments about the most absurd bug or leak you have ever encountered in the wild.

How to block API keys from leaking to Git with zero performance overhead

Khaled Hani — Tue, 07 Jul 2026 15:05:21 +0000

Hello everyone,

I wanted to share Sentinel, an open-source, statically compiled Git pre-commit hook and credentials scanner written in Go.

The project was born out of frustration with existing tools. Most secret scanners are either written in heavy runtime languages (Python, Node.js) that delay developer commit times, or they consume substantial memory footprints (sometimes over 150 MB RSS) just to scan a few staged lines of code.

Our goal was simple: block credential leaks at the local commit stage with a tool that runs under 30ms and consumes less than 12 MB of RAM.

Technical Architecture & Optimization Decisions

To keep the scan latency sub-30ms without sacrificing recall accuracy, we built a three-tier pipeline:

Flat DFA Trie Representation: Rather than relying on pointer-heavy tree structures ([256]*acNode) for the Aho-Corasick automaton, Sentinel compiles rule prefixes into a flat, contiguous, integer-indexed DFA table ([128]uint16). This keeps the trie lookup memory footprint under 500 KB and limits total Resident Set Size (RSS) to ~11 MB (the baseline overhead of the Go runtime).
Buffer-Pooled Base64 Pipeline: Staged assets often contain encoded configurations. To decode and scan inline Base64 data, we implemented a thread-safe sync.Pool for reusable byte buffers. Reusing buffers across the scanning loop completely eliminates heap allocations on the hot path.
Context-Aware Suppression: To eliminate the developer-fatiguing false positives common in entropy-based scanners, Sentinel uses context validation. It checks assignment syntax (LHS vs. RHS), comments, file extensions, and variable names (e.g., ignoring variables prefixed with mock, fake, or dummy) before raising an alert.

Performance Benchmarks

Here is a performance snapshot comparing Sentinel v2.0.5 against Gitleaks and TruffleHog on standard hardware (octa-core ARM64 workstation):

Metric	Sentinel v2.0.5	Gitleaks v8.30.1	TruffleHog v3.95.7
Binary Size	11.6 MB	42.5 MB	185.0 MB
Peak RAM (RSS)	11.2 - 11.6 MB	15.0 - 16.8 MB	152.9 - 155.7 MB
Staged File Scan	30 - 40 ms	210 - 220 ms	7.13 - 11.41 s
Git History Scan	60 - 140 ms	160 - 260 ms	6.32 - 9.05 s
Dependencies	None (Static)	None (Static)	Python Runtime

Quick Start

Sentinel is fully self-contained and has native support for Linux, macOS, and Android/Termux.

You can install it directly via Go:

go install https://github.com/sentinel-cli/sentinel/v2/cmd/sentinel@latest

Or download the pre-compiled binary for your architecture from our releases page, then protect your repository:

# Initialize the pre-commit hook in the current repository
sentinel install

# Or set it up globally for all future repositories
sentinel install --global

Looking for Feedback

We would love to hear your feedback on the architecture, custom rule compiler, or general implementation. The repository is open-source under the AGPLv3 license.
Project repository: https://github.com/sentinel-cli/sentinel
Thank you for your time, and I look forward to your suggestions!

.

Khaled Hani — Mon, 06 Jul 2026 19:47:04 +0000

Khaled Hani

Jun 28

I built Sentinel: A blazing fast, regex-free secret scanner in Go 🛡️

#showdev #go #performance #security

1 min read

[Boost]

Khaled Hani — Mon, 06 Jul 2026 07:58:25 +0000

Khaled Hani

Jun 28

I built Sentinel: A blazing fast, regex-free secret scanner in Go 🛡️

#showdev #go #performance #security

1 min read

I built Sentinel: A blazing fast, regex-free secret scanner in Go 🛡️

Khaled Hani — Sun, 28 Jun 2026 02:55:34 +0000

If you’ve ever used standard secret scanners (like Gitleaks or TruffleHog) in a heavy CI/CD pipeline, you’ve probably hit the "Catastrophic Backtracking" wall. A massive minified JS file slips in, the regex engine chokes, and your pipeline freezes.

I got extremely frustrated with the performance bottlenecks and false positives, so I decided to rewrite the architecture from scratch.

Meet Sentinel, an enterprise-grade, ultra-fast pre-commit scanner written in Go.

🔥 How it’s different:

Aho-Corasick Engine: Instead of relying purely on Regex, the core engine uses an Aho-Corasick automaton. It scans massive payloads in strict O(n) linear time.
Pre-Decoding Layer: It detects Base64 strings in-memory, decodes them dynamically, and feeds them back into the entropy pipeline to catch nested K8s/GCP keys.
Blob Aggregation: Multi-line certs (like JKS or PEM) are aggregated into a single CRITICAL alert instead of blasting you with 50 lines of fragmented noise.
100% Silent: Zero "skipping binary file" logs. It acts as a true silent guardian—natively using git ls-files for traversal.

📊 The Doomsday Benchmark

I built a "Doomsday Payload" (15MB of compressed minified strings mixed with 100+ structural baits like UPPER_SNAKE_CASE constants).
Result: Sentinel ripped through it in ~1.5s with a flawless 100% signal-to-noise ratio.

It is fully open-source under the AGPL-3.0 license. I'd love for the community to try it out, read the code, and give me some harsh feedback!

GitHub Repo: https://github.com/sentinel-cli/sentinel

DEV Community: Khaled Hani

How We Increased Shannon Entropy Throughput in Go by 41% Using a Lookup Table.

The Bottleneck: Shannon Entropy in a Hot Loop

The Mathematical Insight: Factor Out "n"

The Optimization: A Precomputed Lookup Table

The Optimized Implementation

1. Why is the table [513] instead of [512]?

2. Why do we need a fallback?

Edge Cases

Empty input

One-byte input

Repeated byte

Two equally frequent bytes

The 512-byte boundary

Benchmark Results

Latency

Throughput

Zero Heap Allocations

Why the Optimization Works

Complexity Analysis

Why Not Just Use a Huge Lookup Table?

What We Learned

Practical Lessons for Go Performance Engineering

What This Means for Secret Scanning

Conclusion

Final Note on the Benchmark

[Boost]

Crenox – A pre-commit secret scanner 100 faster than Gitleaks (built with Flat DFA + Aho-Corasick in Go)

Crenox – A pre-commit secret scanner 100 faster than Gitleaks (built with Flat DFA + Aho-Corasick in Go)

How My Open-Source Scanner Caught a Crypto Scammer Exposing Their Own Keys

There is a golden rule in cybersecurity: the weakest link is almost always human error. But what happens when that human error comes from a malicious actor trying to orchestrate a crypto phishing scam? The result is surprisingly comedic.

The Setup: Testing in the Wild

The Catch: AI Copy-Paste Gone Wrong

The Phishing Site: Logging into Crypto with Spotify?

The Confrontation

The Technical Takeaway

Secure Your Code (Don't be like our Tether guy)

How to block API keys from leaking to Git with zero performance overhead

Technical Architecture & Optimization Decisions

Performance Benchmarks

Quick Start

Looking for Feedback

.

I built Sentinel: A blazing fast, regex-free secret scanner in Go 🛡️

[Boost]

I built Sentinel: A blazing fast, regex-free secret scanner in Go 🛡️

I built Sentinel: A blazing fast, regex-free secret scanner in Go 🛡️

🔥 How it’s different:

📊 The Doomsday Benchmark

1. Why is the table `[513]` instead of `[512]`?