Faster signatures w/o timing attack issue #268
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 3 commits
March 16, 2025 01:02
Huge increase of performance in signing/verifying WITHOUT timing variations that could leak information about secret keys (that made PR dchest#134 unmergeable) ┌───────────────────────────────────────────────────────────────────────────────┐ │ PERFORMANCE IMPROVEMENTS SUMMARY │ ├───────────────────────────────────────────────────────────────────────────────┤ │ • Signing: ~2x faster on M4 Max compared to current implementation │ │ (slightly slower than previous solution) │ │ │ │ • Verification: ~40x faster than current implementation │ │ (~20x faster than previous PR dchest#134 solution) │ │ │ ├───────────────────────────────────────────────────────────────────────────────┤ │ BENCHMARK RESULTS │ ├─────────────────────────────────────────────────────────────────────────────────────────────┤ │ On M4 Max (MBP Nov 2024), tested in Chrome Version 134.0.6998.89 - arm64: │ │ │ │ THIS PR │ │ sign 787 ops 0.64 ms/op 1573.69 ops/sec [+91.1%] │ │ sign.open 8641 ops 0.06 ms/op 17261.29 ops/sec [+4067.3%] │ │ │ │ PR dchest#134 with risk of timing attacks │ │ sign 889 ops 0.56 ms/op 1775.51 ops/sec [+115.6%] │ │ sign.open 454 ops 1.10 ms/op 906.55 ops/sec [+118.9%] │ │ │ │ CURRENT IMPLEMENTATION │ │ sign 412 ops 1.21 ms/op 823.34 ops/sec - │ │ sign.open 208 ops 2.41 ms/op 414.18 ops/sec - │ └─────────────────────────────────────────────────────────────────────────────────────────────┘
Huge increase of performance in signing/verifying WITHOUT timing variations that could leak information about secret keys (that made PR dchest#134 unmergeable) ┌───────────────────────────────────────────────────────────────────────────────┐ │ PERFORMANCE IMPROVEMENTS SUMMARY │ ├───────────────────────────────────────────────────────────────────────────────┤ │ • Signing: ~2x faster on M4 Max compared to current implementation │ │ (slightly slower than previous solution) │ │ │ │ • Verification: ~40x faster than current implementation │ │ (~20x faster than previous PR dchest#134 solution) │ │ │ ├───────────────────────────────────────────────────────────────────────────────┤ │ BENCHMARK RESULTS │ ├─────────────────────────────────────────────────────────────────────────────────────────────┤ │ On M4 Max (MBP Nov 2024), tested in Chrome Version 134.0.6998.89 - arm64: │ │ │ │ THIS PR │ │ sign 787 ops 0.64 ms/op 1573.69 ops/sec [+91.1%] │ │ sign.open 8641 ops 0.06 ms/op 17261.29 ops/sec [+4067.3%] │ │ │ │ PR dchest#134 with risk of timing attacks │ │ sign 889 ops 0.56 ms/op 1775.51 ops/sec [+115.6%] │ │ sign.open 454 ops 1.10 ms/op 906.55 ops/sec [+118.9%] │ │ │ │ CURRENT IMPLEMENTATION │ │ sign 412 ops 1.21 ms/op 823.34 ops/sec - │ │ sign.open 208 ops 2.41 ms/op 414.18 ops/sec - │ └─────────────────────────────────────────────────────────────────────────────────────────────┘
|
I dedicate any and all copyright interest in this software to the Anyone is free to copy, modify, publish, use, compile, sell, or |
Test run and benchmark run on PR
|
Unfortunately, there can be an overflow with Uint32Arrays, as this requires more bits. See #187 for a similar discussion and a quick test. The tests in this PR also fail if you run: |
…nto faster-signatures
…arking Restructured workflow into specialized jobs for targeted testing and benchmarking Added separate test jobs for nacl.js and nacl-fast.min.js Implemented comprehensive benchmarking with detailed performance comparisons Added visual performance indicators (🟢 improvements, 🔴 regressions, ⚪ neutral) Updated Node.js from v16 to v22 Added test artifacts for better debugging and analysis Enhanced PR comments with detailed benchmark comparisons and performance metrics Added contextual notes about benchmark variation thresholds
Enhance GitHub Actions workflow with comprehensive testing and benchmarking
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On M4 Max (MBP Nov 2024), tested in Chrome Version 134.0.6998.89 - arm64:
THIS PR
PR #134
CURRENT IMPLEMENTATION
The migration from Float64Array to Uint32Array preserves constant-time behavior because:
carry = Math.floor((x[j] + 128) / 256))x[j] &= 255)v = t0 + c + 65535; c = Math.floor(v / 65536); t0 = v - c * 65536