You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a project I started a few years ago, in 2019-2020.
4
+
I re-worked it recently to merge some versions, make it more readable, add comments, and get all the sources I used.
5
+
6
+
7
+
##### Introduction ######
8
+
9
+
This project is a Python implementation of the General number field sieve to factor integers.
10
+
11
+
Here are some detailed characteristics :
12
+
- Kleinjung 2006 algorithm to find good polynomials
13
+
- Double large prime variation used to collect relations for both algebraic and rational side
14
+
- Batch smoothness test and naive smoothness test available
15
+
- Union-find algorithm to detect cycles. Leveraging the graph structures (one central hub) to fasten the cycle finding when I know there is one.
16
+
- Parallel sieving allowed
17
+
- Parallel Polynomial search
18
+
- gaussian elimination, block Lanczos, Wiedemann algorithms available for the linear algebra step (no parallelization available for now)
19
+
- Lifting and Couveignes methods for computing the algebraic square root, no Montgomery algorithm available for now. (no parallelization for now)
20
+
21
+
##### Sources #####
22
+
23
+
Overall algorithm:
24
+
- "Prime numbers, a computational perspective" by Richard Crandall and Carl Pomerance (really good): https://link.springer.com/book/10.1007/0-387-28979-8
25
+
- "The Development of the Number Field Sieve" by many (really really good): https://link.springer.com/book/10.1007/BFb0091534
26
+
- "A beginner's guide to the general number field sieve" by Michael Case: https://www.cs.umd.edu/~gasarch/TOPICS/factoring/NFSmadeeasy.pdf
27
+
28
+
Kleinjung polynomials search algorithm:
29
+
- "On polynomial selection for the number field sieve" by THORSTEN KLEINJUNG: https://www.ams.org/journals/mcom/2006-75-256/S0025-5718年06月01日870-9/S0025-5718年06月01日870-9.pdf
30
+
31
+
Polynomial metric Ep_score:
32
+
- "A new ranking function for polynomial selection in the number field sieve" by Nicolas David and Paul Zimmerman: https://inria.hal.science/hal-02151093v4/document
33
+
34
+
Double large prime
35
+
- "Factoring with two large primes" by Arjen K. Lenstra and Mark S. Manasse: https://scispace.com/pdf/factoring-with-two-large-primes-1lk9719aco.pdf
36
+
37
+
Batch smoothness test:
38
+
- "HOW TO FIND SMOOTH PARTS OF INTEGERS" by DANIEL J. BERNSTEIN: https://cr.yp.to/factorization/smoothparts-20040510.pdf
39
+
40
+
Gaussian elimination:
41
+
- Took the gaussian elimination code from https://github.com/skollmann/PyFactorise/blob/master/factorise.py#L39
42
+
43
+
Block Lanczos:
44
+
- "A Block Lanczos Algorithm for Finding Dependencies over GF(2)" by Peter L. Montgomery: https://scispace.com/pdf/a-block-lanczos-algorithm-for-finding-dependencies-over-gf-2-ezdu2qt0pp.pdf
45
+
- "A modified block Lanczos algorithm with fewer vectors" by Emmanuel Thomé (really good): https://eprint.iacr.org/2016/329.pdf
46
+
47
+
Wiedemann algorithm:
48
+
- "SOLVING HOMOGENEOUS LINEAR EQUATIONSOVER GF(2) VIA BLOCK WIEDEMANN ALGORITHM" by Don Coppersmith: https://www.ams.org/journals/mcom/1994-62-205/S0025-5718-1994-1192970-7/S0025-5718-1994-1192970-7.pdf
49
+
50
+
Square root algorithms
51
+
- "Computing a square root for the number field sieve" by Jean-Marc Couveignes: https://www.math.u-bordeaux.fr/~jcouveig/publi/Cou94-2.pdf
52
+
53
+
##### running the algortihm #####
54
+
55
+
When running the main.py file, the required argument is --n the number you want to factor.
56
+
57
+
A suitable command looks like "python main.py --n [your_number]"
58
+
59
+
##### config parameters #####
60
+
61
+
I have defined a few parameters directly you can edit in the config file.
62
+
63
+
- batch_smooth_test: If True, the batch smoothness test from Bernstein will be used. Otherwise, the naive (trial division from the prime factor base) approach will be used. Batch smoothness test is generally faster
64
+
- gaussian_pivot: If True, gaussian elimination will ALWAYS be used in the linear algebra step. If you want to use block Lanczos of Wiedemann algorithms, this has to be set to False.
65
+
- lanczos: If True, the block Lanczos algorithm will be used. If False, the Wiedemann algorithm will be used. No matter its value, if gaussian_pivot is True then gaussian elimination will be performed.
66
+
- square_root_couveignes: If True, the Couveignes algorithm is run for the square root step. It requires many primes to be inert. If False, the lifting algorithm is used
67
+
- large_primes_constant: Define the constant that will be multiplied by the last prime in the factor base to obtain the bound for the single large primes. For the double large primes, the bound is this constant multiplied by the last prime in the factor base squared. Both the algebraic and rational sides have the same bounds.
68
+
- block_size: If Block Lanczos or Wiedemann algorithm are used, this sets the block size. In the Wiedemann algorithm, this is only used to compute many matrix-vector products at once, and not to compute the matrix generator of the matrix sequence you obtain.
69
+
- poly_search_nb_poly_coarse_eval: number of polynomials to be generated before doing precise ranking.
70
+
- poly_search_nb_poly_precise_eval: number of polynomials to be kept for precise evaluation.
71
+
- poly_search_prime_bound: maximum size of primes used in the polynomial generation
72
+
- poly_search_nb_roots: number of roots to use in the Kleinjung polynomial generation algorithm. It is the l parameter in the original paper.
73
+
- poly_search_multiplier: leading coefficient of generated polynomials is always a multiple of this multiplier.
74
+
- NB_CPU_POLY_SELECTION: Sets the number of cpu used for running polynomial search. One cpu is always kept as a "leader" that collect polynomial candidates from the workers.
75
+
- NB_CPU_SIEVE: Sets the number of cpu used for sieving. One cpu is always kept as a "leader" that collects relations from the sievers, and the rest of the cpus sieve, test for smoothness, and send their candidate relations to the leader.
76
+
77
+
##### General discussion #####
78
+
79
+
I tried overall to use as few exernal libraries as possible. While this makes the code way harder to write for me, and understand for you,
80
+
I viewed it as a good challenge to write good code, and get to know hard and foreign concepts to me. It took a lot of work, but I got a bug free code,
81
+
and got much more knowledgable on the subroutines thanks to this.
82
+
83
+
Here are some points I consider working on at some point:
84
+
- I still have some work to do to implement the state of the art polynomial search algorithms.
85
+
Right now this generates decent polynomials, but it seems that for high degree, eg 5 or 6)
86
+
there are some useful techniques (rational approximation of root, translations and rotations).
87
+
88
+
- I have to implement the Montgomery algorithm for the algebraic square root computation.
89
+
For the small numbers I have used my algorithm on, it is not a bottleneck yet.
90
+
91
+
- I have to optimize the Union-find algorithm for cycle detection, the version I have right now
92
+
does not seem to be perfect, as I still do many operations to connect two distinct connected components.
93
+
94
+
- No matter how hard I tried, I am stuck on understanding the block Wiedemann algorithm. For now, the best I can do is the scalar one, with some optimizations.
95
+
Namely, I use binary encoding of the blocks of vectors to compute matrix-vector product very efficiently. Then, for each scalar sequence, I compute
96
+
its generator using scalar Berlekamp-Massey algorithm, and use it to update the minimal polynomial of the matrix. I consider working some way to
97
+
compute the matrix generator of the matrix sequence through some algorithm (matrix Berlekamp-Massey or some other).
98
+
99
+
- I have to make the linear algebra step more parallel. Even though it is the fastest of the two main steps of the algorithm, no one likes to wait if it is
100
+
possible to faster.
101
+
102
+
Here are the next steps:
103
+
104
+
- Some optimizations may be possible here and there, but I have already a big amount of work to get fast code. The next step on this topic is switching to C.
105
+
Python is intrisically limited on the topic of speed, as it is compiled on the fly. Just like this project, I have already done part of the C project
106
+
a while ago. I have to rework it to get something on the same level of quality as this Python version.
0 commit comments