Fattorizzazione veloce: una dimostrazione

di il
1 risposte

Fattorizzazione veloce: una dimostrazione

Intanto devo (dobbiamo) scusarmi con il nostro “amico/nemico/semplice conoscente” (come dicevano in una vignetta di Sturmtruppen) @claugoit, perche e' statto trattato “male” ingiustamente. Diciamo che la colpa e' 50/50, perche' ci ha messo anche del suo ;-).

Ma passiamo oltre.

Partento dall'assunto che fattorizzare semiprimi grossi “GENERICI” al momento non e' “praticamente possibile” (NON che sia IMPOSSIBILE, serve solo TEMPO!!!!), il suo approccio funziona per UN SOLO motivo: parte da un'APPROSSIMAZIONE del fattore da cercare (la “chiave”) cosa che un normale algoritmo di fattorizzazione non fa (e quindi sta' UN SACCO DI TEMPO).

Ci ho messo un po', la teoria dei numeri la masticavo 30+ anni fa, ma tutto sommato forse non serve andare  troppo lontano.

Vediamo un po' come potrebbe essere andata.

Siano ‘p’ e ‘q’ due primi, e ‘k’ quella che viene chiamata ‘chiave’. Mentre ‘p’ e ‘q’ devono essere, appunto, ‘primi’, su ‘k’ non c'e' nessuna particolare restrizione: puo' essere un numero qualsiasi (intero, positivo).

Vengono fatti i seguenti passi:

n=p*q
a=n % k = r
b=n - a = n - r

per comodita' usero' ‘r’ al posto di ‘a’.
Nel ciclo vengono fatte le seguenti operazioni:

g = gcd(a,b)
if g != 1: break;
a = a + k
b = b - k

SE ‘g’ e' diverso da 1, ‘g’ e' un fattore di ‘n’, FINE, ALTRIMENTI si incrementa ‘a’ di ‘k’ e si decrementa ‘b’ di ‘k’

Ora riscriviamo ‘a’ e ‘b’ usando ‘r’ all'interno del loop, dove ‘i’ e' l'i-ma iterazione del ciclo

a = r + i*k
b = n - r - i*k = n - (r + i*k) = n - a

Quindi il GCD diventa:

g = gcd(a, b) = gcd(a, n - a)

dovremmo avere che  ‘g’ divide ‘a’ e ‘n-a’, ma poiche' per dividere ‘n-a’ deve poter dividere SIA ‘n’ CHE ‘a’ nello stesso momento, e sappiamo gia' che divide ‘a’, NECCESSARIAMENTE ‘g’ dovra' essere uno dei fattori di ‘n’.

E fin qui non ci piove ;-)

Quindi, tutto quello che ci serve e' trovare un ‘g’ che divida ‘a’.

Ma come e' calcolato ‘a’?

a = n % k

cioe' e' il resto della divisione di ‘n’ con ‘k’, CIOE' ‘n’ puo' essere espresso come

n = k*(n//k) + n%k = k*s + r

('//' divisione intera in Python), con ‘s’ il valore INTERO della divisione di ‘n’ con ‘k’

E QUANTO VALE ‘a’ nel ciclo?

a = i*k + r

QUINDI quando ‘i’ sara' uguale a ‘s’, avremmo che ‘a’ sara' uguale a ‘n’.

-----

Dove sta' il problema? Sta nel fatto che il procedimento funziona per QUALUNQUE semiprimo e QUALUNQUE ‘chiave’, c'e' SOLO da iterare abbastanza volte.

SE uno genera una ‘chiave’ gia' sufficientemente vicina ad uno dei fattori, va da se che lo trova in brevissimo tempo.

-----

Secondo me, partendo dall'ASSIOMA che @claugoit sia “onesto”, nel senso che ha sviluppato il suo lavoro in modo “serio”, da qualche parte sta facendo un ERRORE FONDAMENTALE: in qualche modo si sta' portando dietro l'informazione SPECIFICA sui fattori, e quindi, quando genera la chiave, la genera, SENZA accorgersene, VICINA ad uno di loro.

-----

Tra l'altro, ho provato a modificare la chiave, aggiungendo 1, 10, 100, 1000, ed il sistema continua a funzionare senza problemi (ovviamente ;-) ), l'unica cosa che succede e' che a mano a mano che la chiave si “”allontana"" dal fattore, i tempi di calcolo aumentano (perche' aumentano il numero di iterazioni da fare) e se si allontana abbastanza, possono essere necessari PIU' di 10_000_000 iterazioni e quindi il sistema non trova soluzione.

1 Risposte

  • Re: Fattorizzazione veloce: una dimostrazione

    Intanto ti ringrazio e mi scuso anche io

    La tua analisi però mi sembra molto semplicistica… che cosa fa n%chiave , n-a? una semplice operazione di divisione a modulo.

    Questa è algebra conosciuta e chiaramente uno pensa, embeh che c'è di particolare?

    Cambiare la distanza della chiave non ti allontana dal fattore ma ti allontana dalla soluzione. Certo, la chiave non è così precisa che se la cambi di poche migliaia non trova più la soluzione, semplicemente allunghi la ricerca.

    Ora… Parliamo seriamente per favore. Il fatto che con una sola chiave si possano trovare tutti i semiprimi dal punto di partenza alla 10000*2**100, lo trovi normale.  Se hai analizzato il programma avrai visto che comunque vengono trovati tutti alla stessa distanza e in più mischiati a caso. e ciòe qualsiasi fattore primo entro ll limite random può moltiplicare qualsiasi fattore primo anch'esso dentro il random ed essere fattorizzato alla stessa velocià. Non è che i fattori più lontani vengano fattorizzati peggio dei fattori più vicini. Vero?

    Quello che dici tu è verissimo, la tua analisi, le tue dimostrazioni, ma quello che non capisco è… Ma se era così facile perchè nessuno ci ha mai pensato a dimostrare che semiprimi non banali da 5000bit si possono fattorizzare facilmente?

    Ti prego, è una domanda seria.

    Inoltre vorrei chiederti un'altra cosa. “Hai detto: SE uno genera una ‘chiave’ gia' sufficientemente vicina ad uno dei fattori, va da se che lo trova in brevissimo tempo”

    Come generi la chiave che si avvicini il più possibile ai due fattori, in particolare quando questi sono molto distanti tra loro?

    Questo può valere per i semiprimi che sono generati vicini a un quadrato… Piazzi il punto di partenza vicino alla radice e voilà. Ma non è questo il caso. Difatti gli algoritmi conosciuti come ECM i semiprimi vicini ai quadrati o alle potenze li becca subito. Ma non risolve i miei e questo vuol dire che sono distandti dai quadrati e dalle potenze. Esattamente come sono i numeri RSA, distanti tra loro, dai quadrati, e dalle potenze.

    I due fattori non hanno niente a che fare con questo algoritmo, perchè come l'hai messa giù tu è come dire che se io invece di contare da zero per trovare il fattore primo contassi da un numero vicino al fattore, ci metterei molto meno a trovarlo. Non funziona così l'algoritmo. Nella maggior parte dei casi, soprattutto nei fattori molto grandi e molto distanti, la chiave si trova a una distanza tale tra i due fattori che ti ci vorrebbe un secolo per raggiungerli

    Hai provato a fattorizzare questi semiprimi con altri algoritmi di fattorizzazione? 

    Ti ricordi quello che mi hai risposto nel Gennaio 2023? “Hai detto:30 cifre (decimali) non e' un gran numero di cifre: e' circa 2^100 cioe' due interi a 64 bit si inizia a ‘ragionare’ con numeri nell'ordine di 2^1024, 2^2048, 2^512.  QUI si che ti ‘siedi’ ;-)” 

    Grazie comunque per la risposta.

Devi accedere o registrarti per scrivere nel forum
1 risposte