[keygenme] keygenme 5

[qpt^J]

good work there mate, but if i recall correctly, you've keygenned it before?

[KKR_WE_RULE]

yep. That was in Delphi.. As I said above, lost that source.

br

KKR

[_sb_]

qpt^j, nice work on that kgnme8, should I leave a solution here or pm?

[qpt^J]

nice work there mate

sure, you can post it here (like anyone else), i dont see any problems

[_sb_]

you have my solution so, no need for the posting in here.

[Saduff]

I'm trying KGM6. First time solving ECDSA.

Did I get the parameters correct?

It's taking a long time to solve ECDLP.

a = FFFFFFFD // field element defining the point of the curve
b = 31CC59984C1F4 // field element defining the point of the curve
q = 398B479A3C9F3 // field size
n = 398B47BC33879 // order of G
G_x = 1ADD7C665E966 // base point x co-ordinate
G_y = 10C40BB22F5AA // base point y co-ordinate
Qa_x = 200239DB807CC // public key x co-ordinate
Qa_y = 05DD032BD1889 // public key y co-ordinate

Job file for MR.HAANDI's ECDLP solver:

GF := GF(1012325832444403);
E := EllipticCurve([GF|4294967293,876059939881460]);
G := E![472617234852198,294947133781418];
K := E![563102923360204,103148785834121];
/*
FactorCount:=2;
5;
202465173611749;
*/

-- EDIT --

Hmm, maybe a = -3 instead?

Edited August 17, 2011 by Saduff

[qpt^J]

i dont really remember this cme, but yes a=-3

And the best choice to verify params, is playing with ecctool

[Saduff]

All serials do not work for some reason.

Neither do all serials work in KKR's or N1ghtm4r3's keygen.

qptJ.KGM6.Keygen.zip

[KKR_WE_RULE]

It should only take fraction of a second to solve this ecdlp.

Its meant to be broken

*edit*

Hmm..Padding could be a problem.

if length(s1) < 13 then s1 := '0' + s1;

Same for s2.

But if I remember right, I did pad my serial.

Didn't check nightmare's keygen though..

*edit*

You are right.. The problem is there & padding isnt the problem atleast in my keygen. I padded it. Have to check as to whats going wrong.

Edited August 18, 2011 by KKR_WE_RULE

[N1ghtm4r3]

@Saduff: There must be some special conditions on generating K in this case. I already know some of keys don't work and why they don't, but didn't bother to fix.

Edited August 18, 2011 by N1ghtm4r3

[KKR_WE_RULE]

@Saduff: There must be some special conditions on generating K in this case. I already know some of keys don't work and why they don't, but didn't bother to fix.

By K do you mean the random param ? Can you please enlighten me as to whats going wrong ?

[N1ghtm4r3]

My keygen generates prime numbers as K (the random integer), but since N is not prime in this case, for some k's there is no inverse modulo N. so it fails. a simple gcd check should fix the problem.

[KKR_WE_RULE]

I see. Thanx for info

[Saduff]

My keygen generates prime numbers as K (the random integer), but since N is not prime in this case, for some k's there is no inverse modulo N. so it fails. a simple gcd check should fix the problem.

But I have a GCD check when generating K. I make sure k is selected from [1,n − 1] and GCD(k, n) = 1.

Without the GCD check, my keygen would generate an access violation error when the inverse does not exist, due to multiplying with uninitialized FGInt.

[N1ghtm4r3]

So it can be bad implementing or a bug in library of keygenme/keygen, or simply ignoring another simple condition. this is not something you guess, you have to trace/study code to find the problem.