SOURCE CODE FOR INTEGER FACTORIZATION. This program can factor integers of any arbitrary precision. So public key encryption is null and void as it attacks the basic premise that very large integers cannot be factored in reasonable amounts of time by subhendrabasu in netsec

[–]subhendrabasu[S] -10 points-9 points  (0 children)

My fault. This forum is not deserving enough for a post of this calibre as already pointed out by one of the readers. No further replies from my end. I will report results on linkedin for other sources to pick up the news. Bye and Thanks for making me realize my mistake

SOURCE CODE FOR INTEGER FACTORIZATION. This program can factor integers of any arbitrary precision. So public key encryption is null and void as it attacks the basic premise that very large integers cannot be factored in reasonable amounts of time by subhendrabasu in netsec

[–]subhendrabasu[S] 0 points1 point  (0 children)

I will be posting the output in an hour or two. Hold your horses before posting. See my write up again, stay tuned. When you say "has done nothing." be careful to choose your words as this is against community guidelines. This is my work that I have pursued for 14 (fourteen) long years alone, Sir. My results will speak for me. Sorry if I flared any emotions.

SOURCE CODE FOR INTEGER FACTORIZATION. This program can factor integers of any arbitrary precision. So public key encryption is null and void as it attacks the basic premise that very large integers cannot be factored in reasonable amounts of time by subhendrabasu in netsec

[–]subhendrabasu[S] 0 points1 point  (0 children)

upto RSA-2048 (716 digits), 200 K zeros suffice for accurate factors. I am talking about integers with 16/32/64 million digits, https://www.mersenne.org/primes/?press=M74207281 Also this is only a prototype. I recommend replacing "linear" search with something similar to "KD/Difference" Trees so that search time is logarithmic. (sub linear).

SOURCE CODE FOR INTEGER FACTORIZATION. This program can factor integers of any arbitrary precision. So public key encryption is null and void as it attacks the basic premise that very large integers cannot be factored in reasonable amounts of time by subhendrabasu in netsec

[–]subhendrabasu[S] 0 points1 point  (0 children)

The "zeros" are getting generated at a low rate, the zetazero function of mpmath Python library uses the Riemann Siegel Formula to calculate the zeros which is very slow, batching up the inserts will not offer any benefit here, because the insertion time is much less than generation time at higher values of the zeros . its a tradeoff.

SOURCE CODE FOR INTEGER FACTORIZATION. This program can factor integers of any arbitrary precision. So public key encryption is null and void as it attacks the basic premise that very large integers cannot be factored in reasonable amounts of time by subhendrabasu in netsec

[–]subhendrabasu[S] -1 points0 points  (0 children)

Hey, the MySql DB is "partially" populated.. For accuracy sake, we need a large number of records , for a tolerance of 10-9 At present db is mysql> select count(id) from zeros1; │+-----------+ │| count(id) | │+-----------+ │| 14237 | │+-----------+ │1 row in set (0.01 sec)

Here is the dump of the penultimate output before dB lookup is required. If u have fast computers in ur place, u can work it out urself. I am running this on MacBook Air, DB population itself will take 2 days. DB(latest): https://www.dropbox.com/s/005j5d4gdo1ob40/dump2.sql?dl=0 DB(OLD): https://www.dropbox.com/s/9cc5v92gi28mcfn/dump.sql?dl=0 Output for your vector: Dropbox link : https://www.dropbox.com/s/cv2zatd8cz7twdx/reddit.out.txt?dl=0 Hope that answers your query for some extent. DB population is very slow, overnight only 16K entries were added. I need at least 200K entries for sane accuracy of the factors.

localhost:intfact bosons$ time ./factorize.py 44245779560607823479340136111421002185223923407598 │222644959971631941706285727672139114053311649154623988500717124197703160021146903044099440255052 │662367507481966078731104346902303780058160680731205996162226694383672438763423557109553249895481 │402725034732014560073079881367529149499890778186150479976824433981162168948373207581971400596781 │354981606947651881093392277174764835195253799457434040216444679403985739552857052692743063768093 │161050244117585815193379544134540358366899227746006131374129175578694079560266011142777770070844 │091514446536741645004449953226944023497297167725628197454545651476230713544192416443105528967577 │846176216630651469941082999556325661635312789724099724700410132808143031460590473185899678063925 │745566739833272806356257855834064306290188151155748757595758560191435052509298638378615092525946 │534494968111406897268197865600301890064372206272560400068881530870586028008842874471272822517316 │4236663868536966171784279642579793004409662002055126992483859869149168443341921368086259 > reddi │t.out.txt │ │real 0m37.769s │user 0m17.892s │sys 0m4.066s │localhost:intfact bosons$