Exetools  

Go Back   Exetools > General > General Discussion

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 03-15-2026, 00:46
WhoCares's Avatar
WhoCares WhoCares is offline
who cares
 
Join Date: Jan 2002
Location: Here
Posts: 468
Rept. Given: 11
Rept. Rcvd 32 Times in 25 Posts
Thanks Given: 69
Thanks Rcvd at 247 Times in 94 Posts
WhoCares Reputation: 32
@cjack

Please confirm whether the issues described in the attachment are real bugs. Thanks.
Attached Files
File Type: zip MayBeBug.zip (1.2 KB, 3 views)
__________________
AKA Solomon/blowfish.
Reply With Quote
The Following User Gave Reputation+1 to WhoCares For This Useful Post:
Jupiter (03-16-2026)
  #2  
Old 03-15-2026, 01:06
cjack's Avatar
cjack cjack is offline
Family
 
Join Date: Jan 2002
Posts: 170
Rept. Given: 196
Rept. Rcvd 176 Times in 34 Posts
Thanks Given: 332
Thanks Rcvd at 219 Times in 64 Posts
cjack Reputation: 100-199 cjack Reputation: 100-199
Hey WhoCares,

I owe you a correction — and a big one.

In my previous reply, I said your point #3 (walk partition not Frobenius-invariant) was "a legitimate optimization opportunity, not a correctness bug." I was wrong, and I want to be upfront about it.

After a deeper analysis, we realized this is actually the root cause of why our collision is taking so long. Here's what we found:

The walk function uses p = x.lo & 31 (actual affine x bits) for the partition. Since τ(x,y) = (x², y²) produces completely different low bits, walks through P and τ(P) diverge immediately. There's no walk merging between orbit members, which means the 226× Frobenius speedup we assumed in our probability formula was never active.

The numbers speak for themselves:

What we thought: P = 94.5%, past the median, "just unlucky"
Reality: P = 1.28%, only 14% of the way to the median
Search space: We were walking in ORDER (5.19×10³³), not ORDER/226 (2.30×10³¹)
The canonicalization at DP time is mathematically correct (the server handles all Frobenius cases perfectly, as I described before), but it only helps with DP-space birthday collisions — which are negligible at our DP count (expected: 2.6×10⁻¹⁵). The dominant mechanism is walk merging, and that requires Frobenius-invariant iteration.

We're already working on the fix. The plan is to implement canonical lifting at every walk step:

Canonicalize the current point each step (112 squarings in GF(2¹¹³) — cheap in binary fields)
Use canonical x bits for the walk partition
Adjust (a,b) coefficients by λ^i at each canonicalization
Walk from the canonical representative
Cost: ~25-35% overhead per step. Gain: 226× from walk invariance. Net: ~178× speedup.

With this fix, the post-fleet timeline goes from years to weeks — completely changes the game.

You nailed the critical issue. Your analysis was more right than our initial review gave it credit for, and I should have dug deeper before replying. This is exactly why external reviews matter — thank you for pushing on this.

We'll keep you posted on the implementation progress.

Last edited by cjack; 03-15-2026 at 01:34.
Reply With Quote
The Following 2 Users Say Thank You to cjack For This Useful Post:
Abaddon (03-19-2026), Jupiter (03-16-2026)
Reply

Tags
bolero, ecdlp

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Replacing ECDSA in Target (arma) Mynotos General Discussion 3 11-22-2019 00:49


All times are GMT +8. The time now is 21:31.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( Since 1998 )