Armadillo ECDSA-113

[oracle009]

Originally Posted by contextrax

Here is the link to a stripped down source code if anyone wants to have a look.
A GPU version and or Linux version would be great

If any questions then just shoot

ECC Source

Thanks for sharing! The version of ECC Source is 1.00, would you like to share 1.47 or higher version? Thank you very much!

[cjack]

Hey everyone,

I've been working on a GPU-accelerated ECDLP solver specifically targeting Armadillo's ECDSA-113 protection (binary Koblitz curve over GF(2^113)).
The goal: crack the ECDSA-113 certificates used by Encryptionizer (protected with Armadillo) via distributed Pollard's Rho with distinguished points.

Live dashboard: https://ecdlp.protect.cx/

The dashboard shows real-time progress — connected agents, iteration speed, DPs collected, collision probability, ETA, leaderboard with podium for top contributors, and it will display a celebration banner when the curve is solved.

How it works:

Pollard's Rho with Frobenius + negation canonicalization (226x search space reduction)
Table-free GF(2^113) multiplication — 80 registers, zero spills
Lopez-Dahab projective coordinates (no per-step inversions)
~3.5 billion iterations/sec on RTX 5090, ~1.0 G/s on RTX 3060 Ti
Expected solve time: ~19 days on a single RTX 5090 (birthday bound ~6×10^15 iterations)
More GPUs = faster solve. Every GPU contributing brings the ETA down proportionally.

How to join:

Download the agent (Version 1.4.4):
https://ecdlp.protect.cx/download/ArmadilloSolver.zip


Extract and run:
solver_fast.exe --server ecdlp.protect.cx --worker-name "YourName" --worker-notes "Your GPU model"

That's it — zero dependencies, zero install. The agent auto-connects, receives work parameters from the server, and starts grinding.

You can limit GPU usage with --gpu-limit 50 (percentage).
You can stop the agent at any time with Ctrl+C — it saves a checkpoint automatically. When you restart it, it will resume exactly where it left off.

The zip includes both pre-built binaries (ready to run) and full source code with CMake build scripts, so you can review and compile it yourself if you prefer.

Requirements: Any NVIDIA GPU from Maxwell (GTX 900) onwards. The binary includes PTX for universal compatibility — it will JIT-compile for your specific GPU architecture on first launch.
Your contribution shows up on the dashboard leaderboard in real time. When the key is found, everyone who participated gets credited.
Shout-out to this community for all the Armadillo research over the years — this project wouldn't exist without it.

[WhoCares]

can be done in 3 days if 10 cards of RTX 4090?

I ask Gemini (Antigravity) to read the project source code and doc, it gives the following estimation.

The total computational power required for this project can be estimated very precisely mathematically. By combining the theoretical baseline with the optimizations mentioned in the

README.md
, we can calculate the exact requirements.

1. Baseline Mathematical Scale
This system targets ECDSA-113, which is based on a binary Koblitz curve over the finite field $GF(2^{113})$.

Group Order (Total Points): For a 113-bit curve, the order of its large prime subgroup $n \approx 2^{112}$.
Original Pollard's Rho Difficulty: Theoretically, to find a collision in a group of size $n$, the expected average number of steps is $\sqrt{\frac{\pi \cdot n}{2}}$.
Here, $\sqrt{n} = \sqrt{2^{112}} = 2^{56} \approx 7.2 \times 10^{16}$ (about 72 quadrillion iterations).
2. Massive Dimensionality Reduction via Optimization
According to the

README.md
, this project utilizes extremely powerful mathematical optimizations: "Frobenius + negation canonicalization — 226x search space reduction".

Frobenius Endomorphism: On Koblitz curves over $GF(2^{113})$, this mapping can compress 113 different points into a single equivalence class.
Negation: Utilizing the fact that $P$ and $-P$ belong to the same group, the space is halved again (reduced by a factor of 2).
Total Search Space Reduction: $113 \times 2 = 226$ times smaller.
It's crucial to note that reducing the search space by a factor of 226 means the required number of iteration steps is reduced by a factor of $\sqrt{226} \approx 15.03$.

3. Absolute Computing Power Required (Total Steps)
Combining the above two conditions:

Expected Total Steps $\approx \frac{\sqrt{\frac{\pi \cdot 2^{112}}{2}}}{\sqrt{226}}$
Estimated Result: $\approx 6.0 \times 10^{15}$ steps (That is 6,000 Tera-steps or 6 quadrillion steps).
This is the expected value of the total steps required to break this curve.

4. Conversion to Physical Time
We can plug this astronomical number into the GPU performance benchmarks provided in the

README.md
:

1x RTX 5090 has an approximate speed of ~3.5 G/s (3.5 billion steps per second).
$6,000,000,000,000,000 \div 3,500,000,000 \approx 1,714,285$ seconds $\approx$ 19.8 days.
1x RTX 4090 has a speed of ~2.5 G/s (2.5 billion steps per second).
Estimated time $\approx$ 27.7 days.
1x RTX 3060 Ti has a speed of ~1.0 G/s (1.0 billion steps per second).
Estimated time $\approx$ 69.4 days.
Summary
In the face of modern computing power, a 113-bit elliptic curve has completely lost its security.

Since this is a distributed system, if dozens of hackers or security researchers participate and pool together the equivalent computing power of ten RTX 4090 GPUs, it would take less than 3 days (around 66 hours) to compute the required 6 quadrillion steps globally, triggering a hash collision and capturing the private key.

Originally Posted by cjack

Hey everyone,

I've been working on a GPU-accelerated ECDLP solver specifically targeting Armadillo's ECDSA-113 protection (binary Koblitz curve over GF(2^113)).
The goal: crack the ECDSA-113 certificates used by Encryptionizer (protected with Armadillo) via distributed Pollard's Rho with distinguished points.

Live dashboard: https://ecdlp.protect.cx/

[cjack]

Hey WhoCares,

Great analysis! Gemini nailed the math — the numbers are spot on.

To confirm:

Expected steps: ~6.0 × 10^15 (this matches our server's calculation)
10x RTX 4090 at ~2.5 G/s each = 25 G/s total
6.0 × 10^15 / 25 × 10^9 ≈ 240,000 seconds ≈ ~2.8 days (~67 hours)
So yes, 10 RTX 4090s would crack it in roughly 3 days on average.

One small caveat worth mentioning: Pollard's Rho is probabilistic, so the actual time follows a geometric distribution. You could get lucky and find it at 50% of the expected steps, or unlucky and need 2-3x more. But on average, the estimate is correct.

And I can see you're already on the dashboard with your RTX 4070 — welcome aboard and thanks for contributing! Right now we have 4 agents running at a combined ~3.25 G/s, with ~163 trillion iterations done and 6% probability reached. The hunt is on!

[WhoCares]

congrats, there are more full speed RTX 5090s joined.

Originally Posted by cjack

Hey WhoCares,

Great analysis! Gemini nailed the math — the numbers are spot on.

To confirm:

Expected steps: ~6.0 × 10^15 (this matches our server's calculation)
10x RTX 4090 at ~2.5 G/s each = 25 G/s total
6.0 × 10^15 / 25 × 10^9 ≈ 240,000 seconds ≈ ~2.8 days (~67 hours)
So yes, 10 RTX 4090s would crack it in roughly 3 days on average.

One small caveat worth mentioning: Pollard's Rho is probabilistic, so the actual time follows a geometric distribution. You could get lucky and find it at 50% of the expected steps, or unlucky and need 2-3x more. But on average, the estimate is correct.

And I can see you're already on the dashboard with your RTX 4070 — welcome aboard and thanks for contributing! Right now we have 4 agents running at a combined ~3.25 G/s, with ~163 trillion iterations done and 6% probability reached. The hunt is on!

[cjack]

Thanks WhoCares!

Yeah, the cavalry has arrived — 10x RTX 5090 at full speed! Jumped from 3 G/s to 38 G/s overnight. ETA went from 23 days down to less than 2 days!

The dashboard is looking beautiful right now. If everything goes well, we should have the key by tomorrow. Stay tuned!

[WhoCares]

server restarted? 502 Bad Gateway

Better add auto "retry" for agent exe for Unattended run(or run agent exe in an endless loop of batch file).
Currently it simply exits if server error encountered.

Originally Posted by cjack

Thanks WhoCares!

Yeah, the cavalry has arrived — 10x RTX 5090 at full speed! Jumped from 3 G/s to 38 G/s overnight. ETA went from 23 days down to less than 2 days!

The dashboard is looking beautiful right now. If everything goes well, we should have the key by tomorrow. Stay tuned!

[cjack]

Originally Posted by WhoCares

server restarted? 502 Bad Gateway

Better add auto "retry" for agent exe for Unattended run(or run agent exe in an endless loop of batch file).
Currently it simply exits if server error encountered.

Yes, sorry about that — we had to restart the server to deploy some fixes. The good news is: both issues are now resolved in v1.3.1!

Agent auto-reconnect: The agent no longer exits when the server goes down. It will:

Retry registration forever if the server is unreachable at startup
Keep computing and show SERVER OFFLINE - retrying... if the server drops mid-run
Automatically reconnect, re-register and resume when the server comes back
No more batch file loops needed!
Grab the updated agent from the same download link — look for v1.3.1 printed at startup to confirm you're running the new version.

[cjack]

Agent v1.3.3 released! Download updated from the same link or from here:

hxxxs://mega.nz/file/thxBWAIb#DkB8VygjaZEPQpU6Qsm6mZOdW5hizZuQZ3ejmms34q0

What's new:

Auto-reconnect: if the server goes down, the agent keeps computing and reconnects automatically when it's back — no more manual restarts or batch file loops
Faster heartbeats: reduced HTTP timeouts to prevent false "offline" status on the dashboard when multiple agents share the same network
Version tracking: your agent version now shows up in the dashboard

We'll briefly restart the server in a few minutes to deploy the matching update.

Agents running v1.3.3 will reconnect on their own. Older agents may need a manual restart.

Currently running 20x RTX 5090 in parallel — 70 G/s and climbing. ETA under 21 hours!

[cjack]

Server Update v1.4.0 — Auto-Keygen on Solution
* No Agent update needed *

https://ecdlp.protect.cx/

What's new in v1.4.0:

When the ECDLP is solved, the server now automatically forges a valid Armadillo serial using an integrated keygen (based on AKT v0.4 source by mrexodia & Sigma)
The dashboard displays the forged serial in a dedicated "FORGED SERIAL" banner — ready to copy & paste
BasePoint Init seed persisted per-project, so keygen works across server restarts
Fixed UTF-8 decode crash when agents send GPU names with non-ASCII characters

Currently running 24 Agents in parallel — 73 G/s and climbing. ETA 10h 9m

[WhoCares]

@cjack

There is sth. wrong with my agent.

1. The computing speed is toggling between 591 M/s and 1.4 G/s.
2. And the card name "5070 Ti" should be "4070".
3. My agent becomes #1 of leaderboard.

Maybe collide with another agent?

[cjack]

Originally Posted by WhoCares

@cjack

There is sth. wrong with my agent.

1. The computing speed is toggling between 591 M/s and 1.4 G/s.
2. And the card name "5070 Ti" should be "4070".
3. My agent becomes #1 of leaderboard.

Maybe collide with another agent?

Hey WhoCares, thanks for reporting the speed issue!

The toggling between 591 M/s and 1.4 G/s is actually expected behavior when using --gpu-limit — it's a duty-cycle mechanism (compute burst → sleep → compute burst). The reported speed alternates between instantaneous (high) and averaged (low). Nothing wrong there, that's by design.

However, while investigating this I stumbled onto something bigger: your agent was over-reporting iteration counts by roughly 50× compared to the actual Distinguished Points it produced. All 27 other agents had a perfectly normal DP/iteration ratio (around 100%), while yours was sitting at ~2%.

This caused the dashboard to show inflated progress (135% instead of the real ~91%). We've now corrected the totals and the ETA is accurate again.

Possible cause: are you by any chance running multiple instances of the solver with the same --worker-name? That would explain it — each instance reports its own iteration count to the server, but the DP production doesn't scale proportionally if they're all fighting for the same GPU.

Quick check:

Make sure you have only one solver_fast.exe running per GPU
If you want to use multiple GPUs, use --device N to assign each instance to a different GPU, with different worker names
I've also added a server-side guard (v1.4.2) that validates the DP/iteration ratio per agent, so this kind of inflation can't happen again regardless of the cause.

Thanks for being part of the battle! Your GPU is doing great work.

[WhoCares]

I confirmed there is only one process for solver_fast.exe.

My command is:
solver_fast.exe --server ecdlp.protect.cx --worker-name "WhoCares" --gpu-limit 100 --worker-notes "RTX 4070" --resume

And I have no 5070 Ti card. Only one NVIDIA card.

Shall I remove "--gpu-limit 100"?
I originally set it to 50, but later I got lazy and just changed it to 100 without removing that parameter.

Originally Posted by cjack

Quick check:

Make sure you have only one solver_fast.exe running per GPU
If you want to use multiple GPUs, use --device N to assign each instance to a different GPU, with different worker names
I've also added a server-side guard (v1.4.2) that validates the DP/iteration ratio per agent, so this kind of inflation can't happen again regardless of the cause.

[cjack]

Originally Posted by WhoCares

I confirmed there is only one process for solver_fast.exe.

My command is:
solver_fast.exe --server ecdlp.protect.cx --worker-name "WhoCares" --gpu-limit 100 --worker-notes "RTX 4070" --resume

And I have no 5070 Ti card. Only one NVIDIA card.

Shall I remove "--gpu-limit 100"?
I originally set it to 50, but later I got lazy and just changed it to 100 without removing that parameter.

Thanks for checking! Good news — the issue wasn't on your end at all. We tracked it down to a bug in the solver itself.

The problem: init_worms() used a deterministic hash based only on thread ID. This meant every time an agent reconnected (server restart, network hiccup, etc.), it replayed the exact same random walks from the exact same starting points — producing identical DPs. Since there were several server restarts yesterday, most iterations across ALL agents were duplicated work.

Your --gpu-limit 100 is fine, no need to remove it (100 = no throttling, same as not having the flag).

The fix is in agent v1.4.0 and above — worm initialization now uses a session-unique seed (time ^ PID), so every session and every agent gets different starting points.

Download the new agent directly from the server here:
https://ecdlp.protect.cx/download/ArmadilloSolver.zip

Just replace solver_fast.exe and restart. Your same command line works perfectly.

[cjack]

Agent v1.4.4 Available!

Hey everyone,

A new solver version v1.4.4 is available for download from the dashboard. If you're still running v1.4.2 or v1.4.3, please update ASAP.

https://ecdlp.protect.cx/download/ArmadilloSolver.zip

What's fixed:

v1.4.2 and v1.4.3 had a worm initialization bug that caused massive overlap between agents — up to 99.9% of your DPs were duplicates that the server already had. In other words, most of your GPU cycles were wasted computing points that other agents had already found.

v1.4.4 uses a chained pre-hash algorithm for worm seeding that guarantees unique starting points across all agents, regardless of launch timing or PID.

Results after deploying v1.4.4:

DP yield: 99.3% (verified across all 28 agents on the leaderboard)
Zero overlap between agents
Speed unchanged: ~3.5 G/s per RTX 5090
Fleet total: 89 G/s with 29 active agents
Progress so far: 3.6%, ETA ~5.5 days
How to update:

Just download the new ArmadilloSolver.zip from the dashboard page and replace your solver_fast.exe. No config changes needed — same command line as before.

The dashboard is live at the usual address if you want to check your agent's stats.

Every GPU counts — let's crack this code!