Newsgroup: it.comp.sicurezza.crittografia
Titolo: RSA-384, tempo stimato?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Messaggio principalmente per Cristiano, che *già so* che saprà rispondermi:
oggi come oggi, allo stato dell'arte della fattorizzazione, quando tempo
serve per rompere una RSA da 384bit?
Parlo di "singoli" o piccoli gruppi, non di organizzazioni o grossi
effort distribuiti...
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj9Hkc0ACgkQaJiCLMjyUvsoUgCfRu9xGTeCEJ5oefwbluQv6RvT
Xy8An16IzJ+wfJyo0hZH6a0aNK5Y/Pew
=1OC3
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
L.A.P.O. wrote:
| Messaggio principalmente per Cristiano, che *già so* che saprà
rispondermi:
| oggi come oggi, allo stato dell'arte della fattorizzazione, quando tempo
| serve per rompere una RSA da 384bit?
OK, non ho avuto voglia di aspettare... ho fatto da solo ^_^
(è in inglese, sorry)
http://www.emule-project.net/board/index.php?act=ST&f=2&t=23047&st=20#entry176551
That's the point.
Moreover numbers with 384 are "fairly easy" to factor also with *ONE*
PC, today.
Let's try to do an educated guess:
http://www.crypto-world.com/announcements/RSA120.txt
this is the original RSA-120 (digits, not bits) challenge solution: the
author itself estimates the effort in 830 MIPS*years.
RSA-120 (though the friends call him 227 010481295 437363334 259960947
493668895 875336466 084780038 173258247 009162675 779735389 791151574
049166747 880487470 296548479) is a 397 bit number, and it is the
smallest "solved challenge" with more than 384 bits.
Today's CPU have got how much power?
Let's search some test with Google... found:
http://www.pcstats.com/articleview.cfm?art...eid=1340&page=5
it seems that today you can manage to have 9000 MIPS processing power
with not much hassle (i.e. with regular components bought in regular
shops: the article is talking about an Athlon-XP 3000+ CPU).
830 MIPS*years is around 300k MIPS*days
With a 9000 MIPS CPU you can do that in barely 33 days.
With *ONE* of them.
But as punksc said is not so difficult to find 33 of those "modern PCs"
(or maybe 100 "much less modern PCs") and crack a 384-bit key in less
than 24 hours.
Of course it takes some "time" and some "will", but creating a
leecher-mod *already* needs some time&will so that is not a big problem.
I consider this "not enough security".
If your concern is clients.met file size, changing from 384 to 512 bits
is a mere increase from a 1Mb file to a 1.333Mb file.
*BUT* the security increase is exponential, not linear as the file size.
Even using 768 bits keys would only "double" the clients.met size,
though it would be, today, *IMPOSSIBLE* to break.
Changing from a "1-day some-friends-in-the-block" effort to "impossible
to do today, no matter the money spent" just *DOUBLING* the size of a
file that is likely 1000 times smaller than the shared files.... seems
crazy to me.
But, at least changing from 384 to 512 bits, with only 33% file size
increase would already avoid the problem for some years (*I* wouldn't
use anythink less that 768 bits, anyway).
http://www.rsasecurity.com/rsalabs/challen...ing/rsa155.html
Yes, RSA-155 (512 bits) *HAS* been broken, but was a "month-long, many
many people involved" effort...
This rises a question to me, btw: is the key size FIXED or is eMule
prepared to use any key size (or maybe in a range) the remote client is
using? That would be *VERY* useful (and quite easy) to do and would
create less "problems" in the future.
Ok ok, I know the answer "use the source, Luke"...
[half an hour later, editing the message]
I see.
The code is quite general (except that ClientCredits.cpp often uses 80
instead of MAXPUBKEYSIZE as defined in ClientCredits.h and the
client.met format doesn't allow more than 80 bytes keys).
So much more key bits could be used, not even changing the clients.met
file format (and size!).
So the "too big file" reason is moot, after all.
VERY Good =)
(i.e. a mod with selectable key size could be done easily and should
work flawlessy with other clients.)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj9HvCEACgkQaJiCLMjyUvvTogCbBzftJmHGwrfUwyE27Bzj4LYM
C5QAn1fL4CzxaPLl/PD1eN00u9sfekCB
=/Fa2
-----END PGP SIGNATURE-----

 With a 9000 MIPS CPU you can do that in barely 33 days.
Questo significa che l'algoritmo usato e il sistema che fattorizza devono
essere circa 110 volte più veloci del mpqs che ho usato io (ma che ha
scritto uno più bravo di me) e dei miei pc (usati per l'esperimento).
Il primo punto invalicabile è la velocità delle cpu: invece di usare il mio
P4 da 1,5 GHz possiamo utilizzarne una il doppio più veloce (mi risulta che
attualmente siamo a circa 3 GHz di clock). Anche il fsb della cpu è
aumentato rispetto a quello del mio P4 (ora è a 800 MHz).
In definitiva, per il pc potremmo ipotizzare un incremento *ottimistico*
delle prestazioni (rispetto a quello usato da me) di circa 4 volte (ma è
molto ottimistico).
Quindi dovremmo avere un algoritmo 110 / 4 = 27,5 volte più veloce del "mio"
mpqs. E qui la stima è più difficile.
Potremmo utilizzare il number field sieve (che attualmente è er mejo)
ottimizzato fino all'inverosimile.
La libreria che uso io (miracl) mi risulta che sia la più veloce per la
gestione dei numeri interi di lunghezza indefinita (almeno tra le 4 librerie
che ho provato io).
E` possibile che si riesca a scrivere un nfs 27 volte più veloce del già
ottimizzato mpqs? Direi di no.
Per esperienza (e null'altro) posso dire che un raddoppio di velocità è già
una cosa fuori dal normale, però (sempre per fare gli ottimisti) possiamo
prevedere una triplicazione della velocità rispetto al "mio" mpqs.
Alla fine di tutte queste considerazioni abbiamo: 110 / (4 * 3) = 9. Manca
ancora un fattore 9 per fattorizzare *oggi* un modulo da 384 bit in 33
giorni. E io non so proprio dove pescarlo. :-)
Attualmente, se le mie considerazioni *ottimistiche* sono fondate, risulta
che fattorizzare un modulo da 384 bit in meno 300 giorni (in *media*) non
sembra verosimile utilizzando uno dei migliori pc che si può trovare nei
comuni negozi.
Per concludere, dai risultati che ho ottenuto è emerso che con probabilità
di circa il 10% *potrebbe* capitare che il tempo richiesto sia inferiore del
20% rispetto al tempo medio. Questo significa che fattorizzando 10 moduli da
384 bit *con mpqs*, 1 potrebbe essere fattorizzato in tempo_medio * 0,8.
Ma cambiando algoritmo cambierebbe anche la variazione tra tempo medio e
tempo minimo di fattorizzazione, per cui questa constatazione è valida solo
per l'implementazione di mpqs che ho usato io.
Cristiano

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cristiano wrote:
| Poi ho fattorizzato (sempre con lo stesso mpqs) 75 moduli da 120 a 210 bit
| con un P4 da 1,5 GHz.
| Estrapolando i tempi ottenuti, risulta che un modulo da 384 bit lo
| fattorizzerei in circa 2,2e8 secondi: circa 7 anni.
Mhh.
Ci dev'essere qualcosa sotto...
|>830 MIPS*years is around 300k MIPS*days
| Non capisco: 830 / 365 = 2,27 MIPS*days = 227 kIPS*days (se proprio
vogliamo
| usare kIPS).
1 anno sono 365 giorni, non il contrario
Se servono 830 MIPS "per farlo in un anno", mi pare normale che "per
farlo in un giorno" ne servono 365 di più, non di meno ^_^
Quindi 830*365=300k e non 830/365=2.27
| Questo significa che l'algoritmo usato e il sistema che fattorizza devono
| essere circa 110 volte più veloci del mpqs che ho usato io (ma che ha
| scritto uno più bravo di me) e dei miei pc (usati per l'esperimento).
In realtà quella stima di 830 MIPS*yr l'ho presa dall'articolo citato,
non ho fatto "prove pratiche"... però essendo un annuncio ufficiale
della soluzione di un RSA challenge l'ho considerato "attendibile".
E' del 1999 ma suppongo che comunque usi l'allora "stato dell'arte".
Ho ricontrollato i miei calcoli e continuano a sembrarmi giusti... però,
appunto, mi baso su numeri "sulla fiducia" mentre tu hai fatto "prove
concrete", quindi le cose porebbero essere diverse da come descritte...
Oggi purtroppo devo lavorare che sono troppo in arretrato, appena ho un
momento farò nidagini più approfondite...
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj9IzlIACgkQaJiCLMjyUvvELgCeO4Py8Ksdx9nDaktOyq35nuli
b8IAn2fzZN/BHvNfU/44CQwRZT3HL3sW
=nr8r
-----END PGP SIGNATURE-----

 vogliamo usare kIPS).
Ovviamente manca uno 0: 2270 kIPS (ma č meglio usare MIPS).
Cristiano

 un momento farò nidagini più approfondite...
Allora ci risentiamo. Buon lavoro.
Cristiano

 In realtà quella stima di 830 MIPS*yr l'ho presa dall'articolo citato,
A proposito, esiste una definizione ufficiale di MIPS?
Cristiano

A proposito, esiste una definizione ufficiale di MIPS?
No afaik, e i piu' accorti parlano infatti di bogo-MIPS quando si
confrontano prestazioni di calcolo di architetture diverse, oppure di
Meaningless Indicator of Processor Speed :-))
-- 
Linux Registered User #181013
[Exokernels] Although one approach to eliminating bloated, buggy,
unreliable operating systems is to make them smaller, a more radical
one is to eliminate the operating system altogether.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cristiano wrote:
|>In realtà quella stima di 830 MIPS*yr l'ho presa dall'articolo citato,
| A proposito, esiste una definizione ufficiale di MIPS?
Credo che l'unica sia il nome stesso "milioni di istruzioni per secondo".
Di quale CPU? nessuno lo dice.
CISC O RISC? è ben diverso, ma nessuno lo dice.
Che tipo di istruzioni? qualcosa del tipo "non float", dato che se no
sarebbero MFlOpS e non MIPS, ma "non float" è comunque molto generico
(oggi magari no, ma ricordo che sul 386 la differenza tra una somma e
una divisione intera era tipo 1:50).
Sì, esatto... è un'unità di misura parecchio "farlocca" ^_^
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj9JNq4ACgkQaJiCLMjyUvvcYgCgwP0lQMRQPDhpg0H5LGqwZ4F3
NuoAoNHQHZydkf7lDX9hmMaxr61fXcpv
=Zx4f
-----END PGP SIGNATURE-----

 Meaningless Indicator of Processor Speed :-))
In effetti è sempre stata un'unità di misura molto discussa. E` pur vero che
in tutti i documenti di fattorizzazione dell'rsa si parla sempre di
MIPS-year.
Credo che per i nostri scopi farebbe più comodo dire "sono necessari x anni
di P4 3 GHz", sarebbe ancora approssimativa, ma forse renderebbe meglio
l'idea.
Cristiano

 Sì, esatto... è un'unità di misura parecchio "farlocca" ^_^
Probabilmente le differenze tra i nostri tempi stimati sono dovute proprio
al fatto che tu utilizzi l'u.m. farlocca e io un pc reale.
Cristiano

 Credo che l'unica sia il nome stesso "milioni di istruzioni per secondo".
Si.
Scusate se mi intrometto.
MIPS venne utilizzato, AFAIK, dal Marketing department della Digital per
affermare che il loro nuovo "mostro" del 1976, il VAX 11-780, eseguiva 1
milione di istruzioni al secondo. Nella realtà, la cosa era perlomeno
approssimativa.
Nel corso degli anni '80 venne sviluppato un benchmark sintetico per la
misurazione della velocità della CPU (numeri interi solamente), dhrystone,
facilmente portabile su qualsiasi piattaforma. Venne verificato che il
suddetto VAX 11-780 sviluppava 1757 dhrystones. Vedi
http://www.netlib.org/performance/html/dhrystone.intro.html
.
In seguito il benchmark venne applicato su un'infinità di sistemi,
convertendo i dhrystones in MIPS mediante il rapporto appena indicato.
Ottenne un notevole successo perchè fu molto facile, per i vari "marketing
departments" delle varie aziende (Intel in testa), pubblicizzare la velocità
dei nuovi processori in termini di "Miliooooni di istruzioni al secondo" -
un concetto buono anche per il TG4.
In realtà questo benchmark ha ben poco credito, e viene facilmente
"ingannato" dai processori moderni. Inoltre, non rende assolutamente credito
ai grossi supersistemi "massively parallel" (array computers oppure - più
spesso - vector computers, tipo Cray per intenderci).
Un'ultima cosa, sembra che nella realtà il numero "reale" di istruzioni
eseguite dal VAX 11-780 fosse di circa 0,93 milioni/sec.
Vedi la lunga lista in
http://performance.netlib.org/performance/html/dhrystone.data.col0.html
 con
comparazioni ormai "storiche" tra i vari sistemi (non viene aggiornata da
diversi anni).
Ciao.
MArco-

 Credo che l'unica sia il nome stesso "milioni di istruzioni per secondo".
Si.
Scusate se mi intrometto nella vostra discussione, che sto leggendo con
interesse.
Non esiste una definizione ufficiale, così come non esiste un MIPS vero e
proprio. Dipende dal benchmark che si usa per misurare questi "milioni di
istruzioni".
MIPS venne utilizzato, AFAIK, dal Marketing department della Digital per
affermare che il loro nuovo "mostro" del 1976, il VAX 11-780, eseguiva 1
milione di istruzioni al secondo. Nella realtà, la cosa era perlomeno
approssimativa.
Nel corso degli anni '80 venne sviluppato un benchmark sintetico per la
misurazione della velocità della CPU (numeri interi solamente), dhrystone,
facilmente portabile su qualsiasi piattaforma. Venne verificato che il
suddetto VAX 11-780 raggiungeva 1757 dhrystones. Vedi
http://www.netlib.org/performance/html/dhrystone.intro.html
.
In seguito il benchmark venne applicato su un'infinità di sistemi,
convertendo i dhrystones in MIPS mediante il rapporto appena indicato.
Ottenne un notevole successo perchè fu molto facile, per i vari "marketing
departments" delle varie aziende (Intel in testa), pubblicizzare la velocità
dei nuovi processori in termini di "Miliooooni di istruzioni al secondo" -
un concetto buono anche per il TG4.
In realtà questo benchmark ha ben poco credito, e viene facilmente
"ingannato" sia dai compilatori che dai processori moderni.
Inoltre, non rende assolutamente credito ai grossi supersistemi
"massively parallel" oppure ai array vector computers (o array computers,
tipo Cray per intenderci).
Tuttavia si usa quasi sempre ritenere che il dhrystone sia il "vero"
indicatore dei MIPS.
Un'ultima cosa, sembra che nella realtà il numero "reale" di istruzioni
eseguite dal VAX 11-780 fosse di circa 0,93 milioni/sec.
Vedi la lunga lista in
http://performance.netlib.org/performance/html/dhrystone.data.col0.html
 con
comparazioni ormai "storiche" tra i vari sistemi (non viene aggiornata dal
'97).
Ciao.
MArco-

 rispetto al "mio" mpqs.
La mia stima ottimistica si è rivelata pessimistica; 27 volte no, ma una
decina di volte sì (non il (G)NFS, però).
Con l'aiuto dei simpaticoni di sci.crypt ho trovato un programma che
implementa il PPSIQS (double large Primes Procedure Self-Intializing
Quadratic Sieve; il nome è tutto un programma :-) ).
http://user.ecc.u-tokyo.ac.jp/~g340685/
Dopo alcuni giorni di lavoro e di prove, ho estrapolato i tempi richiesti
per fattorizzare 169 moduli RSA da 159 a 240 bit.
Il risultato è che per fattorizzare un modulo da 384 bit, *io* (con il mio
pc)impiegherei *mediamente* appena 332 giorni. Un attuale pc dell'ultimo
grido potrebbe impiegare *mediamente* circa 4 mesi (forse 3).
A questo punto, credo veramente che siamo vicinissimi al massimo che
possiamo chiedere ad un programma di fattorizzazione (il PPSIQS che ho usato
è scritto quasi interamente in assembler ed è ottimizzato fino
all'inverosimile).
Cristiano

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cristiano wrote:
| Probabilmente le differenze tra i nostri tempi stimati sono dovute proprio
| al fatto che tu utilizzi l'u.m. farlocca e io un pc reale.
In realtà ci sono fin troppi dubbi per poter pensare di "comparare" i
due valori...
1. i MIPS trovati non si sa "quanto valgono" per la farlocchezza
intrinseca dell'u.m.
2. l'algoritmo usato in quell'esempio è diverso dal tuo
3. perfino usando lo setsso algoritmo è difficile stimare il tempo
previsto per numeri molto più grandi
Insomma, diciamo semplicemente che una RSA 384 si rompe "in tempi
ragionevoli, sopratutto se si può usare una 'decina' di computer" e
tagliamo la testa al toro 0=)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj9hJfYACgkQaJiCLMjyUvvMlgCg2/JIvPGLbxsT87biRgeri/D8
l0MAn0xeWU95w96dBXor1FkbbErWKMo6
=vLYs
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cristiano wrote:
| Il risultato è che per fattorizzare un modulo da 384 bit, *io* (con il mio
| pc)impiegherei *mediamente* appena 332 giorni. Un attuale pc dell'ultimo
| grido potrebbe impiegare *mediamente* circa 4 mesi (forse 3).
Certo che sono estrapolazioni ben fuori dalla loro zona originaria,
l'imprecisione è elevata.
Tu setsso nell'altro thread, supopgno doop un numero maggiore di prove,
hai valutato 60 giorni per lo stesso task ^^
Mi chiedo comunque quanto possa effettivamente contare la differenza di
"esponente" che passa tra i vari QS più o meno ottimizzati e i vari NFS
più o meno ottimizzati =)
Oltre un certo "N" non eccessivo dovrebbe essere più veloce anche di
metodi "specialistici" come il Pollard Rho, perfino se applicato su
numeri "a lui congeniali" (ovvero di cui (p-1)/2 ha un fattore primo
piccolo).
BTW: queste non sono domande, sono più "prima o poi faccio qualche prova
di persona, ma per ora che non ho tempo sono solo speculazioni"
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj9hJYAACgkQaJiCLMjyUvvaPQCdEMZQfKD3yt/uCMBBpvg36IrN
33EAoL3ngC01Y6BqDWxJRfFUX8n8tvS6
=kozF
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Cristiano wrote:
| Con l'aiuto dei simpaticoni di sci.crypt ho trovato un programma che
| implementa il PPSIQS (double large Primes Procedure Self-Intializing
| Quadratic Sieve; il nome è tutto un programma :-) ).
| 
http://user.ecc.u-tokyo.ac.jp/~g340685/
Ho visto che su quel sito c'è perfino un programma chiamato "NFSX",
l'hai per caso già provato (e scartato) o quando sei stato su quel sito
non c'era?
Personalmente ho qualche problema a leggere il giapponese... per ora ^_^
(e nell'immediato non ho il tempo per scaricare i sorgenti e vedere se
per caso sono commentati in inglese)
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
http://www.megatokyo.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Cygwin)
Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.org
iEYEARECAAYFAj9hJtcACgkQaJiCLMjyUvszTwCfbUfoNKv3b3Ys2WaSbPVgepLZ
AK4AoObCv+nuUiesp+DQRfVPXGIHbB8Z
=yVkA
-----END PGP SIGNATURE-----

 tagliamo la testa al toro 0=)
Sě, considerando anche le ultime prove fatte direi che il succo del discorso
č questo.
Cristiano

 prova di persona, ma per ora che non ho tempo sono solo speculazioni"
Attendo con impazienza. :-)
Sarebbe interessante confrontare i miei risultati con quelli ottenuti da
altri.
Tieni presente, comunque, che nonostante il grande numero di ore che ho
dedicato a tutte le prove effettuate, anche le mie sono solo speculazioni,
magari supportate da qualche numero in piů. :-)
Quello che mi lascia ancora molto perplesso (non essendo un matematico) č
quel maledetto o(1) che non riesco a togliermi di torno. Perň, giŕ che siamo
in discorso, vorrei sottolineare una cosa abbastanza interessante (che ho
anche postato su sci.crypt) anche se č un po' lunghetta e lagnosetta. :-)
Ho interpolato 105 numeri da 46 a 69 cifre e ho calcolato la relativa
formula d'interpolazione sub-esponenziale.
Poi ho fattorizzato 4 numeri (da circa 80 cifre) che richiedono ognuno circa
15 volte il tempo richiesto dal piů grande numero fattorizzato in
precedenza.
Il tempo previsto dalla formula ottenuta per interpolazione č risultato in
ottimo accordo con quello medio realmente richiesto per fattorizzare i
numeri da 80 cifre.
Questi sono i fatti; adesso vengono le ipotesi.
Il tempo medio per fattorizzare i 4 numeri da 80 cifre č stato 10100 s che
moltiplicati per 15 (di cui sopra) fanno 151500 s. La formula
d'interpolazione ci dice (presumibilmente con buona precisione) che con
tutti questi secondi ci si dovrebbe fattorizzare un numero il cui ln =
222,402 cioč un numero da 321 bit. E io sono ragionevolemte convinto che
anche per 384 bit l'errore non sia molto alto. Sfortunatamente, perň, siamo
ancora molto lontani dai 5 milioni di secondi teoricamente richiesti per 384
bit.
Per farla breve, l'idea č di arrivare alla meta facendo un passo per volta
in modo da controllare l'errore commesso rispetto al tempo previsto. Ma chi
č disposto ad impegnare per molti giorni consecutivi (ininterrottamente) il
pc? E se ci fosse un black-out dopo una settimana di funzionamento continuo
chi mi aiuterebbe ad imprecare? :-)
Cristiano

 sito non c'era?
L'ho scaricato ma non li ho provati (sono molti file).
Cristiano