Skip to content

🛡️ Sentinel: [CRITICAL] Fix timing attack in remote static key verification#58

Closed
igorls wants to merge 1 commit intomainfrom
fix-timing-attack-noise-handshake-17018935198270756533
Closed

🛡️ Sentinel: [CRITICAL] Fix timing attack in remote static key verification#58
igorls wants to merge 1 commit intomainfrom
fix-timing-attack-noise-handshake-17018935198270756533

Conversation

@igorls
Copy link
Owner

@igorls igorls commented Mar 4, 2026

🛡️ Sentinel: [CRITICAL] Fix timing attack in remote static key verification

Vulnerability:
The consumeInitiation and consumeInitiationFast functions in src/wireguard/noise.zig used std.mem.eql to compare the decrypted initiator_static key against self.remote_static. std.mem.eql is not constant-time and terminates early upon finding a mismatch, exposing a timing oracle. This could allow an attacker to determine the expected remote static key by observing the timing of handshake rejections.

Impact:
A timing attack could theoretically leak the expected remote_static key during the handshake process, which is a critical security property of the Noise IK protocol.

Fix:
Replaced std.mem.eql(u8, ...) with std.crypto.timing_safe.eql([32]u8, ...) to ensure that the static key comparison is performed in constant time, eliminating the timing side-channel. Added security documentation comments explaining the change.

Verification:

  • zig build passes
  • zig build test passes
  • zig build -Doptimize=ReleaseSafe passes
  • All changes are under 50 lines.

PR created automatically by Jules for task 17018935198270756533 started by @igorls

…cation

Co-authored-by: igorls <4753812+igorls@users.noreply.github.com>
@google-labs-jules
Copy link
Contributor

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

Copilot AI review requested due to automatic review settings March 4, 2026 10:52
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Addresses a timing side-channel in the WireGuard/Noise responder handshake by switching remote static key verification to a constant-time equality check, preventing early-exit comparisons from leaking information via timing.

Changes:

  • Replaced std.mem.eql with std.crypto.timing_safe.eql when validating the decrypted initiator static key in consumeInitiation and consumeInitiationFast.
  • Added inline security comments documenting why constant-time comparison is required.
  • Logged the vulnerability and prevention guidance in .jules/sentinel.md.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
src/wireguard/noise.zig Uses constant-time comparison for remote static key verification during handshake consumption and documents the rationale.
.jules/sentinel.md Adds a Sentinel entry describing the timing-attack class and the required prevention pattern.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +20 to +23
## 2023-10-27 - [CRITICAL] Timing Attack on Remote Static Key Verification
**Vulnerability:** The functions `consumeInitiation` and `consumeInitiationFast` in `src/wireguard/noise.zig` used `std.mem.eql` to compare the decrypted `initiator_static` key against `self.remote_static`. `std.mem.eql` terminates early on the first mismatch, creating a timing oracle. This could allow an attacker to perform a timing attack to determine the expected remote static key during the handshake processing.
**Learning:** It is easy to accidentally use `std.mem.eql` for comparing public keys or decrypted public keys when validating expected peers, especially when the key itself is public but the expected value is part of the secret handshake state.
**Prevention:** Always use `std.crypto.timing_safe.eql` for any comparison involving cryptographic keys, even public keys, when the comparison occurs within a cryptographic protocol or handshake where timing could leak information about the internal state or expected peer.
Copy link

Copilot AI Mar 4, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new Sentinel entry is dated 2023-10-27 but is appended after 2026 entries, which breaks the apparent chronological ordering of this log and makes it harder to scan. Consider either using the actual discovery/fix date for this entry, or moving it to the correct position in the file based on date order.

Copilot uses AI. Check for mistakes.
@igorls
Copy link
Owner Author

igorls commented Mar 9, 2026

Closing: superseded by docs audit fixes and direct commits to main. See PR #67 (merged) for codec bounds check, and direct commit for timing-safe fix in noise.zig.

@igorls igorls closed this Mar 9, 2026
@google-labs-jules
Copy link
Contributor

Closing: superseded by docs audit fixes and direct commits to main. See PR #67 (merged) for codec bounds check, and direct commit for timing-safe fix in noise.zig.

Understood. Acknowledging that this work is now obsolete and stopping work on this task.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants