diff --git a/main.tex b/main.tex
index 78c85b8d5898d0251e45867b74c52f3ae43afcd8..3886ca4f9708e1bf245092fc62d7336c206e5d03 100644
--- a/main.tex
+++ b/main.tex
@@ -1,12 +1,12 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %
-% Rapport de physique 
+% Rapport de mathématique
 % Document LaTeX
 % Version 1.0 (22.09.22)
 % 
-% Ceci est un rapport sur un TP de physique, ou nous devions
-% simuler un systeme planetaire.
-% Par : Adrian Spycher, Costantino Volta
+% Ceci est un rapport sur un TP de mathématique, ou nous devions
+% cracker une clefs RSA que nous avions intercepté.
+% Par : Adrian Spycher, Flavio Moronne, Jad Tayan
 % 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -244,7 +244,7 @@ bmargin=1.25in]{geometry}
 Pour pouvoir cracker cette clefs RSA, nous avons utilisé la méthode de la factorisation de Fermat.
 C'est un algorithme de décomposition en produit de facteurs premiers d'un entier naturel, autrement dit, il va nous aider à retrouver $p$ et $q$ qui composent $n$.
 
-Cette algorithme dit que tout entier naturel impair $n$ se décompose en la différence de deux carrés qui peuvent être ensuite factorisé, on obtient :
+Dans ca factorisation, Fermat nous dit que tout entier naturel impair $n$ se décompose en la différence de deux carrés qui peuvent être ensuite factorisé, on obtient :
 \[
     n = a^2 - b^2 = (a + b)(a - b) = p \cdot q
 \]
@@ -254,12 +254,12 @@ Dans notre cas, on assicie la valeur de $p$ à $a + b$ et la valeur de $q$ à $a
 Si $p$ et $q$ sont tout deux différents de 1, alors ce sont des facteurs non triviaux de $n$.
 Autrement, on se retrouverait avec $n = n \cdot 1$, qui signifirait que $n$ est premier.
 
-Algébriquement, on voit que
+Algébriquement, on voit que :
 \[
     b^2 = a^2 - n
 \]
 
-Sachant que $a$ et $b$ sont deux nombre entier, on cherche une valeur de $a$ qui vérifie que $b^2$ ait une racine entière.
+Sachant que $a$ et $b$ sont deux nombre entier, on cherche une valeur de $a$ qui vérifie bien que $b^2$ ait une racine entière.
 Le point de départ de $a$ serra $\ \sqrt[]{n} \ $ arrondis au supérieur, car en-dessous, $b^2$ serait inférieur ou égale à 0, ce qui est impossible.
 
 \newpage % prettier
@@ -297,11 +297,12 @@ L'algorithme que nous avons fait se présente alors sous cette forme :
 \end{figure*}
 
 % TODO : add bibliogrpahy
-Pour savoir si $b^2$ avait une racine entière, nous avons utilisé une méthode que nous avons retrouver sur \textit{StackOverflow} qui est basé sur l'algorithme Babyloniens.
-Qui, en passant les détails, parcours différentes valeurs possibles calculé par rapport au nombre donnée.
-Si les valeurs testé ne sont pas la racine, c'est que la racine n'est pas entière.
+Pour savoir si $b^2$ avait une racine entière, nous avons utilisé une méthode que nous avons retrouver sur \textit{StackOverflow} qui est basé sur l'algorithme Babyloniens aussi appelé l'algorithme de Héron.
 
-Après avoir récupérer $p$ et $q$, nous pouvons retrouver la clef privée $d$, notamment, en calculant la valeur de $\phi$ :
+Cette algorithme cherche la racine en calculant, à chaque itération, la moyenne arithmétique de $b^2$, en partant de la moitier de $b$.
+Si une valeurs testé est répété, c'est que la racine n'est pas entière.
+
+Après avoir récupérer $p$ et $q$, nous pouvons retrouver la clef privée $d$, notamment en calculant la valeur de $\phi$ :
 \[
     \phi = (p - 1) \cdot (q - 1)
 \]\[
@@ -327,6 +328,55 @@ Et c'est comme ça que nous avons déchiffré le message.
 % astuces d'implémentation non triviales ou les bugs rencontrés, qui assureront aux prochains agents
 % de ne pas reproduire les mêmes erreurs !
 
+\subsubsection{Le problème du C}
+
+Pour implémenter ces algorithmes, nous avions d'abord choisis de le faire en C.
+Car le C étant compile et très proche de la machine, il est extrêmement rapide par rapport au Python qui était proposé.
+Malheureusement, après avoir implémenter la factorisation de Fermat, nous avons remarqué que le C n'était pas capable de gérer des nombres supérieurs à 64 bits.
+Nous avons essayer d'utilisé les \textit{uint128} pour pallier se problème, mais ce n'était pas suffisant.
+En plus de ne pas être pris en charge par des fonctions triviales comme \textit{printf} ou \textit{sqrt}, une force mystérieuse agissait sur lui de façons à ce qu'il fasse des erreurs de calcule.
+
+Nous avons alors décidé de traduire notre code C en Python de façon à ne plus avoir ces problèmes.
+
+\begin{remark}
+    Nous avons appris que le standard C 23, qui sort en 2023, prendra beaucoup plus en charge le \textit{uint128}.
+\end{remark}
+
+\subsubsection{L'optimisation}
+
+En Python, nous n'avons pas eu de problème, tout à été simple à implémenter.
+Ce qui nous a demandé le plus de réfléxion était l'optimisation du code, afin d'attendre le moins longtemps pour cracker la clef RSA.
+Nous avons remarqué assez vite qu'un problème se trouvait dans la condition de sortie de la boucle \textit{while} de la factorisation de Fermat.
+En effet, nous pensions que trouver une racine entière à l'aide de l'algorithme de Héron était la façon la plus rapide de calculer notre résultat.
+Car pour nous, la fonction \textit{sqrt} de Python était très lente comparé à l'algorithme de Héron, mais en réalité non.
+Nous avons alors choisis de changer la condition en utilisant directement :
+
+\begin{figure*}[!h]
+    \centering
+
+    \begin{subfigure}{.5\linewidth}
+
+        \begin{algorithmic}
+            \setstretch{1.3}
+
+            \While {$(a + sqrt(\text{b2}))(a - sqrt(\text{b2})) \myprogneq n$}
+
+            \State \dots
+
+            \EndWhile
+
+        \end{algorithmic}
+
+    \end{subfigure}
+\end{figure*}
+
+Après avoir changer cette ligne, notre code à été nettement plus rapide, avec une résolution de plus ou moins 45 minutes.
+
+\begin{remark}
+    La factorisation de Fermat fonctionne très rapidement si $p$ et $q$ sont proche, ce qui n'était forcément pas notre cas.
+    Sur une autre clef, nous avons pris 5 minutes.
+\end{remark}
+
 
 \newpage