We have now collected 4.6 million ecc points (expected 6.5 million) which give above 2^51 number of iterations.
I was expecting 2^52 number of iteration to solve but this is based on luck.
The exact number of iterations today is: 0xAD87E`3B2BA1AE

The order of the fixed point on this curve is 2^112 bit and usually to solve we need above sqrt(2^112) number of iterations. That is 2^56.
Because of the frobenius and the negation map we get a speedup of sqrt(113*2) which gives around 2^52.

If anyone wonder why we need ~6.5 million points to solve then that is something i chose when I selected the properties on the distinguished point.
The properties is actually the hamming weight of the ecc points x coordinate in normal base.
If the number of bits is 25 we have a distinguished point. If I have selected a lower bit count we would have needed less points but also needed more iterations to find one. If I have selected a higher bit count we would have needed more points but less iterations to find one.
To many of them would flood my server and increased the offline work load. To few and we might need to search more and the chances of solving drops.
If my calculations are correct then with 25 bit prop I will need about 25gig of RAM on my offline server to solve. On this server I have 32 gig RAM.
If this blow then I need to find a server with more RAM of recode my offline solver to solve on disk and not load everything to memory.


The birthday paradox is explained on this page: https://en.wikipedia.org/wiki/Birthday_problem

And we can see here that the group is 365 and that sqrt(365) is ~19.
To have a 50% chance of solving (find a collision) we need 23 people which is above 19. With 19 we have like a 40% changes of collision.

So since we are a bit below sqrt(2^52) I would guess we are in the area of
25% chance of solving.
That table also shows that that chances of solving increases rapidly the more points we get.

But also you can see that to be 100% sure of solving we need like 365 people which gives us 2^112 iterations. Of course that is the worst worst case scenario and will probably never happen.

These algorithms based on luck is a bitch :)

Oh and my last attack on this curve (different target) I solved with only 1.5 million points. I guess I was extremely lucky.

Sorry for explaining the obvious but there might be some that is not to familiar with solving DLP / ECDLP.

Since I use the negation map then one might end up in fruitless cycles.
My solver will try to detect them if they are small (max 256 points) and restart the current worm. But if they are more that 256 points the solver wont detect them.
These fruitless cycles will not give us anything and will only use cpu and reduce speed.
On my solver I print out some info in the status bar. You will see something like this:
LowDCnt: 146 (1/2048) W:123 T:5000

The LowDCnt is the lowest distinguished point count from any worm.
The (1/2048) is how many worms that have this count and the W:123 is which worm that have this count. T:5000 is the time used on the worm with the lowest count but will be restarted if the solver is stoped etc.

Now say that W:123 will go into a fruitless cycle then the LowDCnt will stay at 146 for all time and this is bad.
What I do from time to time is take a screen shot of the solver and after some days I compare the screen shot with the solver. If W:123 is the same and LowDCnt is unchanged I restart the worm. I have not encounter this yet but perhaps all of you running can do the same check.
Now if you see this then I would really like to get a copy of your save state file and you should also now stop the solver and delete the savestate and restart. That is the easy way to get out of a fruitless cycle.

If you wonder what a worm is then because of the cost of a field inversion I used the Montgomery trick to reduce them. To do so I have to split the work so that I can update many points at the same time. This is where name name worm comes from.
On a dual core HT cpu you will see 1024 worms and on a quad core HT you will see 2048 and so on. So on a quad core 2048 points (worms) are updated simultaneously to get the max speed. When a point is updated (a new point is found) then you can look at it as if it's crawling around if the group and when two of these worms collide we have a solution. Of course they need to crawl to the nearest distinguished point but they will both follow the same path when they collide coz of the random walk function f().

Joined the club; the solver seems pretty effective with my 8 logical cores @ ~99% (~45M iterations/s) utilization and it's not even frying my machine :)

One quick question/suggestion: I'm using v1.42, which seems to be the latest/current one; but is there (or shouldn't there be) an update-notification within the solver itself, to ensure we're all on the same page ?

What do you mean by an update notification?
If or when we solve I will inform everyone using this thread that we are done and can stop the solver.
I will also inform this in the server msg you see when you get the server statistics.

Or did you think of something else?

-

All of the solver ecc threads is started with IDLE priority only. This is done so you should be able to use your pc while it's running.

No I simply meant an update to the solver .exe it self :)
I get that the status and data itself will be updated through the Server-stats.

For example if you would encounter a bug (i.e. want to push a fix) or have some improved attack algorithm.

Ofcourse for this specific EC-113 Arma curve it's not very likely (since most crunching already has been done); but perhaps for a future version attacking a different curve or using different (non Arma) Crypto-constraints. ECC is everywhere nowadays, so I can imagine another iteration some day ...

I did a more accurate calculation and I see now we have a 18% change of solving.
Here is the formula based on the wiki birthday page:
100*(1-exp(-((0xAD87E3B2BA1AE)**2)/(2*(2**112/(2*113)))))

Put this into google and it should print out ~18.36
0xAD87E3B2BA1AE is the current iteration of today

When we hit 2^52 iterations we have a ~35.69% chance of solving.
100*(1-exp(-((2**52)**2)/(2*(2**112/(2*113)))))

2^53 would give ~83% so I don't think we need to go this far

Need more CPU's :)

Ah I see now.
Well if I started to push new exe files then I guess none would dare running it :)
Of course they needed to be digitally signed so no one could just hack my server and send out new updates but then everyone must trust me :)
The solver exe file I have made public was uploaded to virus total so you could check it before you run it. I think asking more from any one running it would be a bit to much.

Anyone else would like to comment on this? Would you run a self up gradable exe from someone you don't know?

It doesn't have to be an auto-update feature; it could just advertise it as in 'There is a new version x.xx; download here: ...'. Great stuff on adding the probability btw; is that like a hardcoded message or does it use the mentioned formula in (semi-) real-time ?

Under different circumstances i would have joined the project. Unfortunately a power surge about 9 months ago has fried up my windows machine, leaving me with a macbook air with the processing power of a potato-powered flashlight.

However, i find the coordinated effort and the explanations given to this thread to be of much more value than the final product of this specific project. Could I entice you guys (especially contextrax, who seems to be the initiator and coordinator of the venture) to release (apart from the obvious final product, the private key) a paper describing the chronicle of the effort, explaining the methods used, and perhaps suggesting pointers for future collaborative efforts on similar projects (with emphasis on how a distributive attack system should be designed?).

For now it's hard coded manually.

@Abaddon: Much of the theory & math behind attacking a 113 bit Koblitz curve it can be found in the whitepaper contextrax already linked (and others; there's quite a lot of research on it actually). But I certainly second your suggestion about the implementation optimalisation & distributed coordination details.

Would love to see this project turn into an open source framework for future alike distributed projects, but I do realize that it would take some serious effort by contextrax (and hopefully others) to get there (plugin architecture, accounting, redundancy, result verification distribution algorithms, etc) ...

Hi guys,

I convinced a friend of mine to join sieving; but he's running Linux Mint 18.x and using Wine to run the solver tool; which is running just fine and reporting works as well (I can see his points in my solver stats-screen just fine), but when he tries the [Get Server Statistics], he always get a 'Server Error' (and the error-log holds no additional data).

Anyone a clue ? His machine is reported as Win64 in the local-statsfile ...

It's a bit strange that reading server stats wont work while posting points do.
You could ask him to try again coz I just moved my server to a different provider.
Also the Win64 is a hard coded value in the solver so there is no OS detection there.
If I make a linux version then this field will be updated.

ECDLP Solved

Start date 2017.08.22
Solution found on 2018.01.19

The two colliding points was both found on my own computers.
Number of points collected is 11.423.593
Total number of iteration used is 0x1AE3F1`AE655476 (7 568 976 546 976 886)
The probability for solving at this point was 71.2% (Using both negation and frobenius map). This is a bit on the unlucky side. I was really hoping to get a solution before this.
The average number of iteration to find a distinguish point is 0x277E13F9. If I was to do this again I would lower this value.
Fastest point was found after only 0x2D iterations and the longest run to find one was 0x2`9F20FA67 iterations
Loading all points into memory required 348 Meg of RAM and it took about 3.5 min to load them and to calculate the solution.


Different CPU speeds running the solver v1.47:
Intel Core i7-6700 @ 3.40 GHz was able to get 52 million iterations/sec. (4 cores + HT)
Intel Core i5-4590 @ 3.30 GHz got 31 million iterations/sec
Intel Core i5-4250U @ 1.30 GHz got 14 million iterations/sec. (2 cores + HT)

Pub = Secret*Base

Thank you contextrax for your work (and the math!) and for sharing the results.
Great job!

Just want to add this statement (IMHO it was missing from the post above :)) ... forgive me if it's inappropriate:

Thank you also to all who, in the shadows or in a gray area (lol :D), helped with running the tool and seeding results :)

Best Regards,
Tony

glad to provide many cpu's times to help with it.

Isn't it against the forum rule to write thanks?

Anyway. Thanks for joining in on this.

Indeed it is, lol! ;)

I do appreciate your hard work and I sincerely hope that mr.exodia adds this functionality to his AKT!

Cheers mate!

Hi, is it possible to write down all your discovery and translate into a PDF ?

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

Be my guest :)

Thank's for sharing ECC Source contextrax!
Excuse me for my ignorance but, how to calculate the 8 ecc_curve_array[] parameters of an armadillo protected application?

The first four of them does not need to be changed for a amradillo protected target.
They are the hamming weight, A in the koblitz curve equation (y^2 + xy = x^3 + Ax^2 + B), point order and cofactor.
The last four is the x,y coordinate for the base point and public point in polynomial base.
Armadillo uses a 32 bit's seed for the base point so you will have to use arma source code to calc these values. They are however i the Type 2 Optimal Normal Base and you will have to do base conversion of them to go to x^113+x^9+1
But for testing speed or making a linux or GPU version then this is not necessary.

The test curve that I use have A in the equation set to "0". This result in a different curve used for testing only. The order of this curve is 0x2000000000000000480DCA1242B1C and contains the factors:
Prime factor : 2 - (2 bits)
Prime factor : 2 - (2 bits)
Prime factor : 18B9 - (13 bits)
Prime factor : 1A89A0F - (25 bits)
Prime factor : 31F1F2A998BD31AF391 - (74 bits)
(Found by schoof2 from miracl library. "schoof2.exe 0 1 113 9")

This makes is pretty good for testing (coz of the low order) and the test curve base point has a order of 0x31F1F2A998BD31AF391. (74 bit)
You will also notice that the equivalence classes is maintained in all these subgroup (They all contain 113*2 as factors of p-1) which of course is typical for a koblitz curve.

For base conversion you could make a matrix B=[1, b, b^2....,b^(m-1)] (m=113 for this base)
Multiplying b^m*B^-1 should give you a polynomial base and to go from this base to x^113+x^9+1 you can use one of the 113 roots.
For root finding you can use magma or sage or some other algo if you want to make one yourself.

Hope this helps.

Hello! This is really cool, but isn't Armadillo discountinued? I am asking because I couldn't find it's homepage anymore.

Yes that is true but there is still allot of programs that uses it for protection and for licensing coz of the "unbreakable" elliptic curve system they use :)

Hi Contextrax, I have a VERY BAD target that I'm trying to reverse since a lot of time! The problem here is that it use A LOT of protected executables, so, maybe, the right way will be attacking the ECDSA certificate itself :)
Need support to calculate the last 4 ecc_curve_array[] parameters.
If you can help I'll extract the public certificate and post it here asap.
I think that a tool to calculate the 8 ecc_curve_array[] parameters will be AMAZING :) :)

Maybe you share the target with us so we can check?

Yes sure! Here the link:

h**ps://mega.nz/#!V8RFxCDL!7JYuUUybRoJelyZwNvp8yB-LmkBGKEeJA_uUjfmxNls

I've put into the zip just the registration app and a trial key (expired on november 2017 but if you set the clock back it'll work).
As serial number use the string "Evaluation".

Hope to start the bruteforcing soon :) Curious to see how many time will take!

You want to break 4 113 bit's ECC curves by solving ECDSA?
We used like 6 months last time so unless you have access to a lot of CPU's this will take forever.

can u share the target?

What is more important in bruteforcing - CPU GHz speed or # of cores?

I see that you have a mathematical or physical profile.
You have tried to use your models to find the protection system of flex_LM
It also uses an ECC protection system.
(If I'm wrong, please correct me)

Yes, but flex uses more stronger ECC

im think there is not necesary do many with that app , i will send some private msj
x64dbg (no plugins)
hide command
bp in 00402A90 as hw bp and start to check
is posible use the values (provided) or any fake.
here must be the end:


if not have the program, will call to program regedit values , im think there not must be a normal app with armadillo (minimum protection)

BR, Apuromafo

About the importance of privatevalue in the example before exposed:
generating a licence for apuromafo for x86+x64 (is the same cert shortv3 lv10)

->

tool:ATK 0.4
Ecdsa Public: 1570789295,4089747062247003654720736468506441,10111618751385367037406972360317044
(Curve SEED : 1570789295
Base Point x : 4089747062247003654720736468506441
Base Point y : 10111618751385367037406972360317044)
Private:1984557253727814641989266002264698
name:apuromafo
Sym:BDA4FA1C
press generate and see:

name:apuromafo
serial:000017-MC8PXU-6U3PC3-3V93J6-Y9MCJ5-7GF1E8-TRWK3F-JUGJV6-4QFZNC-TW0YVM


in advanced log
in my pc, both armadillo was registred with my user+serial generated using atk0.4

BR, Apuromafo

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!

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.

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.

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!

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