newsgroups-index (beta)

Current group: sci.crypt

Re: Surrogate factoring approach, analysis

Re: Surrogate factoring approach, analysis  
jstevh at msn.com
 Re: Surrogate factoring approach, analysis  
Bryan Olson
From:jstevh at msn.com
Subject:Re: Surrogate factoring approach, analysis
Date:20 Jan 2005 16:16:18 -0800
I figured, well, why not try.

I'm running the numbers this guy put up through my current program
which is at the Yahoo! group.

Tim Smith wrote:
> In article <1104591454.431335.128080@z14g2000cwz.googlegroups.com>,
> jstevh@msn.com wrote:
> > It turns out that the analysis behind my surrogate factoring
approach is
> > rather easy to walk though with a few basic equations.
> >
> > That should mean I can get people to take me seriously, but you are
> > Usenet, and the problem is held by the math community, so clear
evidence
> > may not work!
>
> All you have to do is show that it works. Here are some composite
numbers
> to test on. Each is the product of two primes whose length is up to
the
> number of bits specified.
>
> Do a couple of examples from the 8 bit or 16 bit section to
illustrate how
> the method actually works, then see if you can do some from the 128
bit
> section.
>
> ====== factors up to 8 bits ======
> 57599

( 239 241 )

I'm copying output from the program, so that's direct output, though I
am leaving out some of the extra information it gives.

> 43139

Skipping...trivially factors as the program has a prime list up to 200.

> 24523

Same as above.

> 34121

Same as above.

> 35953

Same as above.

> 19043

Same as above.

> 33043

Same as above.

> 20567

Same as above, as again, the program automatically will check for
primes up to 200, so these are trivial factorizations for it, not worth
putting up.

> 36089

Same as above.

> 37769

Same as above. Hopefully more interesting below.

>
> ====== factors up to 16 bits ======
> 1996465633

( 35141 56813 )

> 2348221831

Couldn't find factors.

> 3574886741

( 57679 61979 )

> 3172590413

Couldn't find factors.

> 2514657533

Couldn't find factors.

> 1388161393

( 36217 38329 )

> 2335689907

Couldn't find factors.

> 2493433781

( 41879 59539 )

> 1840902013

( 39451 46663 )

> 2095611269

Couldn't find factors.

>
> ====== factors up to 24 bits ======
> 135247262314741

Couldn't find factors.

> 239937525733091

Couldn't find factors.

> 119059652313451

Couldn't find factors.

> 177805283351779

Couldn't find factors.

> 140979690859369

Couldn't find factors.

> 137305167623353

( 11173213 12288781 )

Whew! It's taking a lot longer now as the program really isn't built
for large numbers, yet. It's a proof of concept prototype not built
for speed.

I was worried it might not factor any numbers of this size.

Most of the time is taken with factoring T, the surrogate, and it's
possible that it's not decomposing it fully, but it got at least one.

Each factorization is taken a few minutes now...

> 156432070838873

Couldn't find factors.

I suspect it didn't fully factor T, looking at the factorization it
gave.

For those of you who don't know, T is the surrogate factored to factor
the target, which I call M. Yes, originally in the paper T was to be
the target, but I found my original approach didn't work, and I didn't
feel like changing T in all the equations.

So the program factors T, the surrogate, and then uses that
factorization to get y, and then calculates x, which it checks to see
if it has a gcd with M, the target.

That's how all the factorizations I've given have been done...using my
theory.

> 84697211728937

Couldn't find factors.

> 151766760236149

Couldn't find factors.

> 137083650684517

Couldn't find factors.



The code is at

http://groups.yahoo.com/group/sufactor/

in purple.jar, which does include the source.

Ok, it's took a long while with the numbers above, so I'm stopping
here.

Each attempt was a single pass with j calculated by taking floor(M/2),
getting its residue with respect to 6, and subtracting that. Then T =
M^2 - j^2.

And I used A = 8(92647), and I don't know if that made a difference as
I'm just trying things now.

It is a prototype program, though it is strangely slower than I'd hoped
with these numbers.

And I know, now more of you will make fun of me for such a pathetic
result, but I already said it doesn't factor everything.

If it did, I wouldn't be talking about it publicly.

The question is, what are the limits? Why does it factor some numbers
and not others? It looks from this little experiment like it's getting
worse as the numbers get bigger which is a bad sign, but what are the
mathematical reasons why?

Remember, this is from my theory, a theory you won't find in textbooks,
and if you had Newton write an algorithm based on congruence of squares
soon after he discovered it, would he write the Number Field Sieve?

Think about it before more you yucks decide to make fun of me.
James Harris
From:Bryan Olson
Subject:Re: Surrogate factoring approach, analysis
Date:Fri, 21 Jan 2005 01:01:53 GMT
jstevh@msn.com wrote:
[...]
> The question is, what are the limits? Why does it factor some numbers
> and not others? It looks from this little experiment like it's getting
> worse as the numbers get bigger which is a bad sign, but what are the
> mathematical reasons why?

I expect those results are telling us something. If you recall
your previous "surrogate factoring" algorithm, it was simply
checking the greatest common divisor of the target and some not-
so-interesting numbers. The method amounted to "trial GCD".

The tendency to find small factors and miss large ones is what
we'd expect from such guess-and-check methods when the guesses
are more or less arbitrary.


--
--Bryan
   

Copyright © 2006 newsgroups-index   -   All rights reserved   -   Impressum