Processor stuck at 25% when multithreading

[GaEL]

Hi !

I'm currently running yafu 1.34 on cygwin to factor a 95digits key and try to decrypt a .vvv file.

All is running on a Win 7 Pro 64bits virtual machine (12GB RAM + 4 Intel Xeon E5630 entirely dedicated to my VM)

I ran the factor command during 3 hours and the system is so slow.
You can check the screen in attachment file below.

In fact, processor is stucked at 25% and never exceed this value. I've modified the yafu.ini file with threads=4 inside.

I don't know what is wrong with my configuration.

Could someone help me ?

Thank you for reading ;)

Gael

[wombatman]

Is the yafu.ini file in the same folder as the .exe? Your other option would be to pass "-threads 4" instead.

[VBCurtis]

You say 95 digits, but your screenshot says 145 digits. Which is it? 95 digits should take about an hour. 145 should take a few days.

[Dubslow]

IIRC correctly, the built in ECM is not multithreaded. To get multithreaded ECM, you should download a copy of GMP-ECM and tell yafu where to find the executable (via yafu.ini).

If you are sure your number is in fact a key, you should run "siqs(c95)" instead of "factor()" (which looks for small factors by ECM first).

If it is really a 145 digit key like your screenshot suggests, then use "nfs()" instead of "siqs()".

[chalsall]

Originally Posted by Dubslow

IIRC correctly, the built in ECM is not multithreaded..

Then what might be the issue(s), if any?

[Dubslow]

Originally Posted by chalsall

Then what might be the issue(s), if any?

If you mean why is the code this way, you'd have to ask Ben.

If you mean how does this result in the symptoms described, then it's simply because OP's yafu is falling back to the builtin ecm (in lieu of the preferred external GMP-ECM), which is singlethreaded only so it only runs the one thread.

[GaEL]

Thanks all of you for answering. So in the order :

- wombatman => yafu.ini is in the same folder as yini.exe. I'll try with "-threads 4" this is always stuck at 25%.

- VBCurtis => indeed there's 145 digits, excuse me for my mistake.

- I'm gonna try with nfs(). I also forget to specify the gmp-ecm path

Simultaneously I ran a yafu builded version on Debian 64x with 4 threads and it works fine (I mean all cpu near 100%). But yes, 145 digits should take a long time, even if there's the 4x Xeon.

I'm going to apply your tips on my machine and let you know how's it's going on.

Thank you again

[GaEL]

Well, i tried with nfs() and siqs()

for both it returns " input must be odd" (in attachment file)

Is that a key problem or my config goes wrong ?

(btw, it runs well with factor(), approximately 3-4 hours following the program ;) )

[jasonp]

factor() tries a succession of techniques that strip out progressively larger and larger factors before moving to SIQS and NFS. The latter two assume this has already happened.

Most if not all of these Teslacrypt numbers have small factors, so they are not conventional RSA keys where nothing but nfs() or siqs() would work on them. You'll need to remove the small factors first, and then feed any leftover composite numbers to nfs() or siqs().

[science_man_88]

Originally Posted by jasonp

factor() tries a succession of techniques that strip out progressively larger and larger factors before moving to SIQS and NFS. The latter two assume this has already happened.

Most if not all of these Teslacrypt numbers have small factors, so they are not conventional RSA keys where nothing but nfs() or siqs() would work on them. You'll need to remove the small factors first, and then feed any leftover composite numbers to nfs() or siqs().

my results from dividing the number by two then factoring to 2^32 ( the others aren't confirmed prime at last check) :

(08:41) gp > factorint(%,2^32)
%5 =
[11 1]

[73 1]

[574528669691 1]

[41130962080332043 1]

[671931392138040966258679495931 1]

[1412768518150334124463466996272612543385875055672753209158271382496594505413952262750345115376871 1]

edit: never mind factorint doesn't have a limit only a flag for what type of algorithm to use. edit: rerunning without a flag. 2^32 wouldn't have a flag bit set so it probably wouldn't matter doh.

[bsquared]

Originally Posted by science_man_88

my results from dividing the number by two then factoring to 2^32 ( the others aren't confirmed prime at last check) :

(08:41) gp > factorint(%,2^32)
%5 =
[11 1]

[73 1]

[574528669691 1]

[41130962080332043 1]

[671931392138040966258679495931 1]

[1412768518150334124463466996272612543385875055672753209158271382496594505413952262750345115376871 1]

edit: never mind factorint doesn't have a limit only a flag for what type of algorithm to use. edit: rerunning without a flag. 2^32 wouldn't have a flag bit set so it probably wouldn't matter doh.

You mistyped the OP's number. I translate it as

3602649853484214179983415445666301940354495565543916242311221257561512738889505000235719414385939551029113564292002198303081881671314596809680484560821278

which seems to match what the OP posted (it is producing a similar factorization so far, stuck at a C145).