Newsgroup: it.comp.sicurezza.pgp
Titolo: Generare numeri Random - possibile sorgente di entropia?

Ho trovato questa chiamata API e mi chiedevo se secondo voi sarebbe una
buona sorgente una funzione che crei numeri random.
Vi allego il listato VB
Private Type LARGE_INTEGER
    LowPart As Long
    HighPart As Long
End Type
Private Declare Function QueryPerformanceCounter Lib "kernel32"
(lpPerformanceCount As LARGE_INTEGER) As Long
Private Declare Function QueryPerformanceFrequency Lib "kernel32"
(lpFrequency As LARGE_INTEGER) As Long
Private Declare Sub CopyMemory Lib "kernel32.dll" Alias "RtlMoveMemory"
(Destination As Any, Source As Any, ByVal Length As Long)
Private Sub Form_Load()
    Dim T As Long, liFrequency As LARGE_INTEGER, liStart As LARGE_INTEGER,
liStop As LARGE_INTEGER
    Dim cuFrequency As Currency, cuStart As Currency, cuStop As Currency
    For i = 1 To 100
    'Retrieve the frequency of the performance counter
    If QueryPerformanceFrequency(liFrequency) = 0 Then
        MsgBox "Your hardware doesn't support a high-resolution performance
counter!", vbInformation
    Else
        'convert the large integer to currency
        cuFrequency = LargeIntToCurrency(liFrequency)
        'retrieve tick count
        QueryPerformanceCounter liStart
        'do something
        For T = 0 To 100000
            DoEvents
        Next T
        'retrieve tick count
        QueryPerformanceCounter liStop
        'convert large integers to currency's
        cuStart = LargeIntToCurrency(liStart)
        cuStop = LargeIntToCurrency(liStop)
        'calculate how many seconds passed, and show the result
        Debug.Print "Time: " + CStr((cuStop - cuStart) / cuFrequency) + "
seconds"
    End If
    Next
End Sub
Private Function LargeIntToCurrency(liInput As LARGE_INTEGER) As Currency
    'copy 8 bytes from the large integer to an ampty currency
    CopyMemory LargeIntToCurrency, liInput, LenB(liInput)
    'adjust it
    LargeIntToCurrency = LargeIntToCurrency * 10000
End Function
Cosa ne dite?
Fabio

> Cosa ne dite?
A occhio mi pare che tutto quello che fa è leggere il RDTSC presente in 
tutte le CPU a partire dal P2 (mi pare.. o era il P1?).
Questo è ovviamente melgio delle "solite chiamate" che danno solo l'ora 
in millisecondi e *può* essere una sorgente di entropia accettabile, 
sotto alcune condizioni.
Non certo per processi automatizzati o che comunque richiedano molta 
entropia (come la generazione di una chiave crittografica ad esempio).
In definitiva, per mio giudizio, può essere una valida componente di un 
sistema di raccolta di entropia, ma non può certo essere la sola se si 
vuole qualcosa di valido per crittografia (cosa che credo, dato il 
newsgroup in cui stiamo scrivendo).
Una buona referenza sull'argomento (in inglese):
http://www.cryptoapps.com/~peter/06_random.pdf
Una ottima sorgente "casereccia" può essere l'ADC della scheda audio 
quando il microfono non è inserito.
--
Lapo

 Cosa ne dite?
E` buona l'idea di usare l'high resolution performance counter insieme ad un
altro temporizzatore. Ma il codice che hai postato non mi sembra che generi
numeri casuali.
In ogni caso, prima di utilizzare i bit in uscita da un qualunque
generatore, è buona norma passarli in una funzione crittografica (di solito
un hash) in modo da rendere l'uscita statisticamente ottima.
Il modo più semplice per usare questo tipo di generatore è il seguente:
1) attendi x secondi usando il timer a bassa risoluzione;
2) leggi il bit meno significativo del contatore ad alta risoluzione;
3) accumula almeno il doppio di bit di quelli in uscita dell'hash (cioè 320
con l'sha1);
4) se hai 320 bit, hashali e usali;
5) ritorna al passo 1;
Meglio ancora è utilizzare il TimeStampCounter disponibile nei Pentium
"miscelato" utilizzando algoritmi molto più complessi.
Cristiano

 
http://www.cryptoapps.com/~peter/06_random.pdf
Una referenza più specifica icnentrata sulla "generazione" che 
sull'analisi della bontà di algoritmi esistenti:
http://www-106.ibm.com/developerworks/security/library/randomsoft/?dwzone=security
--
Lapo

 buona sorgente una funzione che crei numeri random.
Non conosco in dettaglio quella chiamata, quindi non posso sbilanciarmi
troppo. Comunque usare una chiamata di quel genere (non necessariamente
quella che dici) e' di sicuro una buona strada per generare numeri
casuali. 
In genere si preferisce usare piu' funzioni (del tipo che diano
informazioni sull'attivita' dei dischi, sui processi attivi, sui files
temporanei creati, ecc.) e combinarle insieme, magari in maniera a sua
volta casuale, piuttosto che usarne una sola e basta. 
Ti consiglio di scaricarti i sorgenti di GnuPG e di guardare come funziona
il generatore di numeri casuali per Win32. E' nel file "rndw32.c" nella
sottocartella "cipher". Attinge informazioni da praticamente tutte le
chiamate di sistema utilizzabili per lo scopo. Tra queste c'e' anche
"QueryPerformanceCounter", quindi troppo male non deve essere... ;-)
Qui mi fermo, visto che conosco poco di VB e meno ancora di C,
purtroppo... :-/ 
-- 
Carlo Luciano
GPG ElG/DSA 4096/1024 Key: 
http://web.tiscali.it/clbianco/clbianco.asc
ID: 0x5324A0DA - Fingerprint: 8B00C61034120506111B143DEDBF71B45324A0DA

 Cristiano
ciao
Fabio

 mi interessa moltissimo.
In pratica ha senso usare tutto l'output SOLO se sei già certo che 
contenga 160 bit di entropia.
Da notarela differenza tra "bit" come unità di misura della 'mera 
informazione' e di misura dell' 'entropia'... è facile capire che un 
libro pieno di lettere 'a' contiene meno 'interesse' di un libro 
contenete una copia della Divina Commedia.
Però ogni dato che "dai in uscita" lo devi considerare "usato" e mai più 
usabile, quindi se si vuole fare un generatore che continui a 
"mischiare" i suoi dati generalmente si dà in uscita solo una parte dei 
160bit ottenuti (che so, magari 32 alla volta) e gli altri si possono 
rimettere nella tua pozza di entropia raccolta, assieme a nuovi dati 
raccolti da RDTSC e altre sorgenti.
E' importante aggiungere sempre nuova entropia alla pozza in modo che 
anche nel malaugurato caso che l'hash usato venga "rotto" la tua 
implementazione non venga automaticamente rotta "a cascata".
BTW: ho scoperto che c'è anche una RFC su questo argomento, la 1750
ftp://ftp.isi.edu/in-notes/rfc1750.txt
--
Lapo

 Lapo
Fabio

 Cosa intendi per hash rotto?
Metti che un domani trovano un modo matematico per "invertire" lo SHA1.
Non sarebbe più monodirezionale, quindi nno sarebbe più neanche un 
"hash" a ben vedere... sarebbe un "hash rotto".
--
Lapo

 Come?
Leggendo il valore con l'istruzione assembler RDTSC (che ritorna un intero a
64 bit).
In pratica, l'high resolution performance counter lo usi per attendere
alcune decine di microsecondi (per esempio 200-300 us), dopo che hai atteso,
leggi il TSC e xori i 32 bit bassi ottenendone 1 che *dovrebbe* avere
un'entropia decente, si spera... :-)
A disposizione per ulteriori chiarimenti
Cristiano

 implementazione non venga automaticamente rotta "a cascata".
Parole sante! :-)
Cristiano

 QueryPerformanceCounter ritorna.
E` bene precisare che QueryPerformanceCounter legge il valore di un
contatore incrementato dal quarzo dell'orologio (la cui frequenza viene
ritornata da QueryPerformanceFrequency, ed in genere è circa 1 MHz).
RDTSC (nei pentium) legge il valore del TSC che viene incrementato ad ogni
ciclo di clock e quindi la sua frequenza, nei computer attuali, è circa
1000-2000 volte quella dell'altro contatore.
Il fatto molto interessante, dal punto di vista crittografico, è che i due
oscillatori sono *quasi totalmente* scorrelati (hanno una lieve correlazione
solo in funzione della temperatura) e questo li rende molto validi se
utilizzati come dicevo nell'altro post.
Cristiano

 Cristiano
Grazie
Fabio

 utilizzati come dicevo nell'altro post.
Resta il fatto che la "bontà" dell'entropia raccolta dai contatori è 
abbastanza dubbia, bisognerebbe considerare ogni lettura come valere 
massimo qualche bit...
In letteratura si dice "1 bit" ma questo è per le chiamate "alla unix" 
che ritornano il tempo di microsecondi. Il QueryPerformanceCounter sulla 
tua macchina sembra ritornare precisioni simili, nel mio caso potrei 
certamente assegnargil qualche bit di entropia in più, usando il RDTSC 
ma secondo me non si può prescindere da altri conteggi, a meno che la 
raccolta non vada avanti, in background, per tempo relativamente lungo.
Tutto dipende dagil scopi ovviamente: se si vuole fare una simulaizone 
Monte Carlo si può anche non avere entropia e usare un buon generatore 
pseudo-casuale ^_^
Ad esempio questo generatore è ottimo (per scopi non crittografici) ed è 
spesso più veloce dei generatori rand() dei compilatori:
http://www.math.keio.ac.jp/~matumoto/emt.html
--
Lapo

 voltaggi di alimentazione,purtroppo non so come monitorarle.... :)
Dalle API di windows c'è una buona sorgente di entropia: quella generata 
dalle Crypto API.
Benché per ragioni più o meno paranoiche (ma ricordiamoci che un po' di 
'sana' paranoia è necessaria in queste questioni) si possa considerare 
questa libreria come "controllata da microsoft" non credo che possa 
generare dei numeri casuali troppo spudoratamente falsi e -quando 
presente in hardware nel chipset- è probabile che usi anche il chip 
intel "generatore di entropia".
In buona sostanza non fidarti dei numeri generati dala Crypto API di 
Windows ma usali come aggiunta al tuo generatore che male non possono fare.
--
Lapo

 
http://www.math.keio.ac.jp/~matumoto/emt.html
Siamo perfettamente d'accordo; per usi non crittografici il generatore che
hai proposto è il migliore che conosco, l'ho testato a lungo e non è mai
emerso un comportamento anomalo (come era logico aspettarsi).
Cristiano

 monitorarle.... :)
Nemmeno io :-)
Ma i timer opportunamente letti e post-processati danno ottimi risultati
anche per applicazioni di una certa importanza.
Cristiano

 fare.
La m$ non si è mai dimostrata sensibile alla crittografia. Perfino con il
costoso XP Professional continua ad elargire bachi sulla sicurezza; io
lascerei stare tutto ciò che riguarda la crittografia della m$.
Miscelare i bit contaminati :-) dalla m$ a quelli tutto sommato validi per
molti scopi, potrebbe essere dannoso...
Cristiano

 molti scopi, potrebbe essere dannoso...
Eheh hai ragione, mai toccare i lebbrosi bit microsoft eheehh ;)
Lapo
PS esclicativo per non trarre in inganno: battute a parte quando si 
aggiungono dei bit a una pozza con metodi buoni come con un hash non si 
può perdere nulla, al limite si guadagna 0.

 QueryPerformanceCounter legga il tsc. Usi windows NT?
Esattamente.. a meno che i o mi ricordi particolarmente male.
Ora ri-cerco quella patch che avevo preparato per cygwin1.dll che lo 
testava per usarlo come GetTimeOfDay...
UFF non lo trovo, ci metto meno a riscriverlo!
#include <windows.h>
#include <stdio.h>
main() {
   LARGE_INTEGER performanceFrequency;
   if(QueryPerformanceFrequency(&performanceFrequency)==0)
     printf("No timer present.");
   printf("%ld %ld", performanceFrequency.HighPart, 
performanceFrequency.LowPart);
}
$ gcc -mno-cygwin -o rdtsc.exe rdtsc.c
$ ./rdtsc.exe
0 3579545
Ehm. Giurerei che l'altra volta mi aveva ritornato qualcosa nell'intorno 
del 450 milioni.
Però l'altra volta usavo un intel P3-450 mentre ora ho un amd 1900XP+... 
che *ha* il RDTSC che io sappia, ma forse "microsoft" non lo sa.
Qualcuno che ha un intel può provare a vedere che gli ritorna?
Questo articolo IBM (non è quello su cui mi ero basato temop fa, ma è 
simile) dice:
http://www-106.ibm.com/developerworks/library/i-seconds/
Luckily, Win32 provides the multimedia timer routines 
QueryPerformanceCounter and QueryPerformanceFrequency. They provide much 
better resolution than timeGetTime, approaching or exceeding 
microseconds accuracy. But, these APIs aren't without problems. They are 
not supported on all platforms, as they are based on hardware timers 
with special register support in the CPU.
Sembrerebbe avvalorare il fatto che non sono pazzo ^_^
--
Lapo

 lo sa. Qualcuno che ha un intel puņ provare a vedere che gli ritorna?
Detto fatto:
$ gcc -o rdtsc.exe rdtsc.c
$ ./rdtsc.exe
0 3579545
  ^^^^^^^
Poi, tanto per essere sicuri:
$ gcc -o rdtsc.exe -mcpu=pentium3 -march=pentium3 -O3 \
    	    	    	-mfpmath=sse -mmmx -msse rdtsc.c
$ ./rdtsc.exe
0 3579545
  ^^^^^^^
Il tutto e' stato eseguito su un P3-866 con Win2K-SP2 e GCC 3.2 sotto 
MinGW/MSYS (gli stessi pacchetti della compilazione di GnuPG di qualche 
post fa).


 Poi, tanto per essere sicuri:
Mazza allora ricordo davvero male, oppure usavo una versione 
specialissima di windows ^_^
A questo punto il mi consiglio a chi vuole per forza usare VB è "usa 
l'ASM" ihihih ;)
--
Lapo

 specialissima di windows ^_^
Beh, ma non puo' essere invece che la colpa sia del compilatore? Magari sa
che quella chiamata puo' dare problemi su certe macchine e allora non la
esegue comunque, emulandola in qualche modo... 
C'e' qualche volontario con MS Visual C che vuole provare a vedere che
numero gli esce? ;-) 


 esegue comunque, emulandola in qualche modo... 
No, perché io ho usato cygwin in -mno-cygwin e tu hai usato mingw che 
non ha nessun layer di emulazione... la chiamata fatta è quella non ce 
n'è...
Comunque ho letto in giro per internet e non sono l'unico a credere che 
quella chiamata usi l'RDTSC, ma molti altri dicono "non la uso perché 
non si sa mai cosa fa, cambia molto da OS a OS, preferisco usare RDTSC 
con assembly in linea".
--
Lapo

 n'è...
Pero' si tratta sempre di GCC in entrambi i casi. Il porting su CygWin e
quello nativo MinGW potrebbero semplicemente comportarsi allo stesso
modo... 


 modo... 
No dai, mi rifiuto di credere che se linki con solo librerie standard e 
se includi windows.h invece di usare la chiamata API di windows la emula...
$ strings /cygdrive/f/CPP/rdtsc/rdtsc.exe
[omissis]
strtoul
AddAtomA
CreateMutexA
ExitProcess
FindAtomA
GetAtomNameA
InterlockedIncrement
QueryPerformanceFrequency
ReleaseMutex
SetUnhandledExceptionFilter
Sleep
WaitForSingleObject
msvcrt.dll
KERNEL32.dll
Direi che è cofnermato ^_^
--
Lapo

 Direi che è cofnermato ^_^
Torna anche a me.



Compilato con Visual C++ 6.0 sp 5
0 3579545
Ciao
Fabio

Ho trovato una chiamata WMI molto interessante e posto il codice con la
quale stò facendo alcuni test
Private Sub wmiPerfdisk()
   Dim wmiObjSet As SWbemObjectSet
   Dim obj As SWbemObject   'CurrentProbe
   Dim itmx As ListItem
   Set wmiObjSet = GetObject("winmgmts:{impersonationLevel=impersonate}"). _
   InstancesOf("Win32_PerfRawData_PerfDisk_PhysicalDisk")
   DoEvents
   For Each obj In wmiObjSet
      Set itmx = ListView1.ListItems.Add(, , "Valore")
      itmx.SubItems(2) = CStr(obj.AvgDisksecPerWrite_Base)  *
      DoEvents
   Next
End Sub
La chiamata ritorna un sacco di parametri sul disco ,in particolare
AvgDiskBytesPerRead
AvgDiskBytesPerTransfer
AvgDiskBytesPerWrite
AvgDiskQueueLength
AvgDisksecPerRead
AvgDisksecPerTransfer
AvgDisksecPerWrite
DiskBytesPersec
DiskReadBytesPersec
DiskWriteBytesPersec
nonchè il famoso parametro frequency_perfTime che ritorna ovviamente 3579545
Potrebbe essere una valida sorgente anche questa che dite?
Ciao
Fabio

 Potrebbe essere una valida sorgente anche questa che dite?
Per scopi crittografici assolutamente no.
Tutti quei parametri sono noti a tutti e sono uguali in molti pc, in altre
parole hanno un'entropia insignificante.
Molto meglio usare i timer che dicevamo. Hai piů fatto qualche prova?
Ciao
Cristiano

 0 3579545
OK. E' quindi accertato che quel numero non dipende dal compilatore...


 altre parole hanno un'entropia insignificante.
Infatti non mi sembra che siano usati nel generatore di GnuPG...


 Molto meglio usare i timer che dicevamo. Hai piů fatto qualche prova?
Si ho fatto e sto continuando a farne.
Mi sono fissato sul trovare altre fonti di entropia ma non sono ancora
riuscito a reperire info sull'adc della scheda audio (ad "alto livello" si
riesce a fare tutto ma quando devi lavorarci un po' piů vicino all'osso pare
che nessuno sappia nulla).
Il fatto č questo, vorrei trovare una buona routine che poi possa essere
portabile in tutti i miei progetti.
Siccome cerco di fare le cose "per bene" , vorrei provare tutte le strade
possibili.
Siete tutti molto gentili e disponibili .
Grazie
Fabio

 che nessuno sappia nulla).
Guarda che stare ad alto livello non è che rovini le cose... puoi 
campionare anceh attraverso DirectSound per qanto importa 0=)
L'improtante è che tu non "associ" a questi bit troppa informazione, 
tieni solo l'ultimo e passa lo stream di bit in qualche forma di 
"compressione" (anche l'algoritmo stesso di hashing).
Se la scheda audio è spluggata e sente del rumore questo bit può essere 
molto buono, ma dato che in ogni caso avresti 44100 di questi bit al 
secondo non ti costa nulla considerarne validi molti meno e "andare sul 
sicuro" (a meno che la tua applicazione abbia bisogno di TANTA entropia, 
ma in quel caso conviene comunque assicursarsi di raccoglierla in altro 
modo).
Tieni conto che se la scheda audio è buona e c'è qualcosa di pluggato 
può darsi che neanche l'ultimo bit oscilli.
--
Lapo

 strade possibili.
Il visual basic non è il linguaggio più adatto per armeggiare con l'hardware
a basso livello. Se vuoi, posso mandarti il codice in c delle funzioni che
uso io per leggere la scheda audio e poi tu provi ad adattarlo per il VB.
In ogni caso, la scheda audio la puoi usare come generatore d'entropia se
usi sempre lo stesso computer e hai appurato che l'adc genera rumore
termico, ma se prevedi di usare i tuoi programmi anche in altri computer è
rischioso fare affidamento sulla scheda audio.
Per esempio, con la AWE 64 Gold il rumore termico è talmente basso che l'adc
genera tutti zeri in mancanza di segnale (il rumore non è rilevabile).
Con un'altra scheda potresti averne molto, con un'altra poco; è sempre un
aspetto dubbio.
Se proprio la vuoi usare, ti conviene xorare la sua uscita con i bit in
uscita dal timer (o meglio dal tsc).
Cristiano

 può darsi che neanche l'ultimo bit oscilli.
Ma se invece si campionasse da microfono, come sarebbe come sorgente di
entropia? I rumori di fondo della stanza dovrebbero essere abbastanza
casuali, no? Come sorgente non dovrebbe essere peggio del premere a caso
un po' di tasti sulla tastiera o del muovere a caso il mouse sullo
schermo. Quindi nella "pozza" ci potrebbe stare bene anche lei. O, almeno,
credo... 


 entropia?
Un microfono ACCESO sarebbe anche anche ok... ma se è spento allora hai 
uno 0 fisso.
Meglio il rumore termico del microfono NON pluggato...
--
Lapo

 Meglio il rumore termico del microfono NON pluggato...
Meglio anche del rumore di sottofondo della stanza catturato dal microfono
acceso? Questa e' una sorgente di entropia... come dire... "assicurata",
mentre il rumore termico dipende dalla "bonta'" della scheda audio
installata e quindi potrebbe essere una sorgente piu' o meno buona a
seconda del computer su cui gira il programma. O sbaglio? 


 meno buona a seconda del computer su cui gira il programma. O sbaglio?
Il rumore termico se c'è, c'è sempre. Il rumore ambiente può esserci in un
certo momento e non esserci un momento dopo. Per stare sicuro dovresti
infilare il microfono dentro al computer in modo da fargli sentire molto
bene il rumore delle ventole e dell'hard disk.
Comunque, un altro "difetto" che ho riscontrato (nella scheda audio di
questo pc) è che il rumore termico è molto correlato con ciò che la cpu sta
facendo; in altre parole, la scheda audio (con microfono spento) sembra
"sentire" la cpu e questo rende l'entropia veramente bassa (o nulla).
Come dicevo, io lascerei perdere la scheda audio per accumulare entropia.
Miscelare bit "buoni" con bit "cattivi" potrebbe peggiorare le cose...
Cristiano

 Miscelare bit "buoni" con bit "cattivi" potrebbe peggiorare le cose...
Questo mai, 0+x fa x anche se si parla di entropia... una sorgente per 
quanto "cattiva" non può certo avere entropia negativa...
--
Lapo


Questo ovviamente finché usi una funzione che di per sé non butti via 
nulla... ad esempio lo XOR non va bene per dati TRA LORO correlati 
benché vada benissimo per dati tra loro scorrelati, benché uno dei due 
possa essere "buono" e l'altro orrendo".
Comunque usando un hash "serio" si evitano tutti questi problemi...
è per questo che sostengo che "una sorgente di entropia in più" va 
sempre bene, per quanto "dubbia", danno non ne può fare.
--
Lapo

 nulla).
E' una cosa che ho notato anche io. Potrebbe avere a che fare con la
"pulizia" dei segnali elettrici del bus? 


 "pulizia" dei segnali elettrici del bus? 
Ogni case è una piccola tempesta elettromagnetica ^_^
Ma quello non è rumore termico, quello è altro rumore.
Comunque secondo me un buon generatore NON deve fare assunzioni sulla 
situazione del PC.. certo ogni cosa in più va bene ma se dobbiamo 
iniziare a dare per scontato che possiamo sapere ni che stato è l'audio 
etc. etc. a quel punto ci vuole meno a costruirsi un piccolo generatore 
di rumore bianco ^_^
--
Lapo

 uscita dal timer (o meglio dal tsc).
Facciamo questa supposizione:
Una polla di entropia è costituita appunto da entropia. L'entropia deriva da
svariate sorgenti, come abbiamo detto fino ad ora.
Il PC ha svariate sorgenti di entropia ma, per fortuna o per sfortuna , solo
poche sono sfruttabili per applicazioni diciamo "di alto livello" .
Ora,se noi fossimo in grado di monitorare temperatura della CPU,velocità
della Ventola, ADC della scheda AUDIO in OGNI computer (oltre ovviamente ai
timer) avremmo un'ottima sorgente di entropia. Mi spiego, considerando anche
che un PC abbia una scheda audio dove l'ADC non pluggato non oscilla, avrà
sicuramente una ventola che ha RPM irregolari (è meccanica e la polvere
pure), oppure avrà una variazione di temperatura della CPU, quindi di
conseguenza qualche bel bit da XORARE con i Timer .
Ora il problema è come reperire queste informazioni ,ma bisogna comunque
tenere presente che tutte queste sorgenti sono presenti in TUTTI i pc e che
potrebbero diventare uno standard nella creazione di numeri random.
Mi è ancora leggermente oscuro un punto, una volta che ho prelevato un paio
di bit da una parte e un altro paio dall'altra ,prima di passarli nella mia
bella e buona funzione di hash che operazione devo fare? XOR tra loro o
semplice somma?
Fabio


E` vero, ma sei *sempre* costretto ad hashare l'uscita combinata delle
sorgenti d'entropia per non rischiare di ottenere una sequenza con scarse
proprietà statistiche (e quindi più facilmente craccabile).
Usando una buona sorgente (come i timer) *puoi* evitare di usare l'hash,
anche se bisogna dire che non è consigliabile.
Cristiano

 "pulizia" dei segnali elettrici del bus?
Non saprei, ma più che di "pulizia" io penso che alcune schede audio (di
basso costo) semplicemente captano i segnali che la cpu sparpaglia da tutte
le parti e lo scarso filtraggio della scheda audio te li fa ritrovare in
uscita.
Cristiano

 fare? XOR tra loro o semplice somma?
Ritenendo che le varie sorgenti siano scorrelate, la cosa più comoda è
xorarli (che è una somma modulo 2). Con la "semplice somma" hai un riporto
di troppo :-)
Dopo aver hashato *tutti* i bit ottenuti dalle varie sorgenti (cioè senza
alcun processamento prima dell'hash), conviene processarli in modo
d'aumentare la complessità del generatore (per esempio usando M-M o altro)
per complicare la vita ai cattivoni.
Cristiano

 anche se bisogna dire che non è consigliabile.
Veramente i timer sono tra le sorgenti peggiori (si consiglia di 
considerare 1 bit per sorgenti al millisecondo, e la sorgente di windows 
non dà mai oltre i 10ms)... purtroppo sono quasi le uniche utilizzabili 
su tutti i computer senza assunti iniziali =)
Io comunque consiglierei di usare sempre e comunque un hash (MD5 o 
SHA1), per non rischiare... altrimenti per essere sicuri che le cose 
fatte vadano bene servirebbeuna laurea in teoria dei numeri, lasciamo 
fare il lavoro a chi l'ha già fatto 0=)
--
Lapo

 fare il lavoro a chi l'ha già fatto 0=)
E se io che non ho la laurea avessi bisogno di un generatore per i miei
programmi di crittografia? Mi fai laureare? :-)
Cristiano

 programmi di crittografia? Mi fai laureare? :-)
Non hai colto il senso, intednevo "usiamo SHA1 che gente larueata in 
matematica e crittografi esperti analizzano da anni, non usiamo 
soluzioni casereccie".
--
Lapo

 una soluzione non ideale.
Ho dato la maglia nera a quel sistema perchè purtroppo non funge quasi mai.
Dalle numerose prove che ho fatto (anche con l'aiuto di Don Davis a cui
accennavo l'altra volta), con i "moderni" hd i settori letti vengono
memorizzati nella cache del drive e l'algoritmo di predizione usato dalla
logica di controllo del drive rende vano ogni tentativo di obbligare l'hd a
leggere il settore voluto. Così, dopo qualche lettura, il nuovo settore da
leggere è già disponibile nella ram del drive e i vari fenomeni fisici
dell'hd non sono sfruttabili per i nostri loschi scopi.
A completamento del discorso, non so se siete a conoscenza di havege:
http://www.irisa.fr/caps/projects/hipsor/HAVEGE.html
L'autore (un ingegnere che lavora nella progettazione dell'architettura
delle cpu) lo definisce imprevedibile. In realtà è un generatore
deterministico ad elevatissima complessità, in quanto sfrutta lo stato
interno della cpu.
Aggiungo che lo scorso marzo io e l'autore abbiamo scambiato molti messaggi
in merito al funzionamento e alla teoria dietro a questo generatore.
Ma ad un certo punto, lui non mi saputo dare valide spiegazioni in merito ad
un parametro usato dal generatore e ho pensato bene di continuare ad usare
il buon vecchio tsc.
Per quello che vale avervelo raccontato... :-)
Cristiano

 generatore di rumore bianco ^_^
Il che non sarebbe una cattiva idea... Lo colleghi alla porta parallela
(faccio un esempio) e poi leggi da li' tutta l'entropia che ti serve... 
Qualcuno ha voglia di postare uno schemino elettrico del circuito? ;-)


 ritrovare in uscita.
Una cosa del genere mi era capitata con una SB16, quindi una scheda di
qualita' (almeno per l'epoca a cui mi riferisco). Su un PC (486DX/33)
funzionava perfettamente, mentre su un altro (Pentium 100) l'audio a 16
bit "frusciava" in una maniera assurda mentre quello a 8 bit era
perfetto. Temo quindi che il problema fosse nella scheda madre del 
secondo... 


 Temo quindi che il problema fosse nella scheda madre del secondo...
Credo che tu abbia ragione.
Cristiano

 Qualcuno ha voglia di postare uno schemino elettrico del circuito? ;-)
Puoi provare quello che abbiamo costruito insieme a un ricercatore americano
(a dire il vero lui lo ha costruito e io l'ho testato :-) ).
La documentazione si chiama: 
detecting_random.ps
. E` un generatore basato
sul decadimento radioattivo delle particelle alfa (ottenute all'interno di
un rivelatore di fumo).
Per chi fosse interessato, la sezione "Tests for randomness" è rimasta
quella relativa alla prima versione del generatore, ma poco più di un anno
fa ho ritestato il generatore usando nuovi test e nuovi metodi.
Quasi superfluo dire che il generatore è ri-risultato ottimo! :-)
Cristiano

 Qualcuno ha voglia di postare uno schemino elettrico del circuito? ;-)
Se lo attacchi alla scheda audio (che è un ingresso analogico) fai un 
circuito ancora più facile... la parallela non so quanto bene si 
comporti con segnali "non TTL".
La seriale sarebbe meglio da quel punto di vista, basta che non esci dal 
suo range e dovrebbe accettare un po' tutto.. in quel caso basta che 
prendo un amplificatorei qualsiasi (che so, un operazionale uA741) e gli 
fai amplificare sé stesso.
BTW: sono incuriosito abbastanza da provarci, quasi quasi...
--
Lapo

 Credo che tu abbia ragione.
Dubito che la CPU, data la sua dimensione, irradi alcunché se la 
paragoni al bus PCI, ben più lungo ^_^
--
Lapo

 Quasi superfluo dire che il generatore è ri-risultato ottimo! :-)
Beh, l'uso di una sorgente radioattiva era quello a cui pensavo quando ho
parlato di sorgenti "intrinsecamente casuali" nell'altro messaggio. Pero'
costruirselo in casa non e' proprio alla portata di tutti... 
Meglio allora il rumore Johnson ai capi di una resistenza elettrica o
l'amplificatore operazionale di Lapo, se non altro per la reperibilita'
dei componenti... 


 paragoni al bus PCI, ben piů lungo ^_^
Giusto per la cornaca: la SB16 era su ISA, che e' ancora piu' lungo del
PCI... ;-)


 BTW: sono incuriosito abbastanza da provarci, quasi quasi...
Beh, non sarebbe male, in effetti. Un ottimo generatore di entropia a costo 
quasi zero. Poi magari patchiamo anche GnuPG per farglielo supportare... 
;-))
Se butti giu' qualcosa, facci sapere!


 mondo sarà in grado di prevederlo.
Si', per i nostri scopi sono d'accordo con te.


 PCI... ;-)
Ma a frequenza molto minore =)
--
Lapo

 Ma a frequenza molto minore =)
Non hai tutti i torti, in effetti... :-/


Scusate la domanda forse stupida , ma se si utilizzasse un file .zip come
sorgente di entropia?
Sostanzialmente una stringa che non può essere compressa dovrebbe poter
contenere una buona quantità di entropia  e, un file zip non è comprimibile
(se non per pochi byte).
Magari si potrebbe comprimere un numero molto elevato di files e ottenere un
file zip molto grande ,es. 1 Gb e da quello "distillare" alcuni bit di
"entropia" buona da passare poi alla funzione hash.
che dite?
Fabio

 alcuni bit di "entropia" buona da passare poi alla funzione hash.
Una simile sorgente non contiene la benché minima entropia; assolutamente 0.
Sarebbe più conveniente hashare un file a blocchi da 160 bit (nel caso
dell'sha-1) e prendere i 160 bit in uscita; guadagneresti in efficienza e
avrebbe circa lo stesso livello di sicurezza (piuttosto basso).
Ancora meglio sarebbe hashare l'uscita di un prng (generatore di numeri
psudocasuli) di periodo immenso (ce ne sono alcuni).
Ma tali sistemi si prestano solo per ottenere un'ottima sequenza di numeri
*pseudo* casuali avente un'elevata compessità lineare (grazie all'hash). Un
crittografo motivato sarebbe in grado di craccarla con poco impegno.
Cristiano

 sorgente di entropia?
Comprimere un flusso può aiutare a "raccogliere" (nel senso di 
"compattare in meno spazio") l'entropia... ma non puoi usare un file 
esistente, per il solo fatto che esiste ha entropia bassissima... a meno 
che tu non l'abbia appena creato quel file (e a quel punto tanto valeva 
prendere l'iput da tastiera come generazione di entropia).
--
Lapo


http://www.irisa.fr/caps/projects/hipsor/HAVEGE.html
Mi pare che il link non sia piů valido... confermi?
--
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 /

il buon vecchio tsc.
In che senso?
Che tipo di parametro?


 Che tipo di parametro?
La spiegazione è un po' lunghetta.
Inizialmente il codice era scritto per cygwin e compilarlo con  BCB o VC era
un'impresa epica. Allora ho chiesto all'autore se poteva scrivere una dll
per winzozz.
Dopo alcuni messaggi, però, s'è reso conto di non capirci nulla e invece di
scrivere il codice per una dll, mi ha tradotto il codice per i compilatori
sotto winzozz.
Ma mi fece una brutta raccomandazione:
"When performing experiments don't touch HAVEGE.obj !
(Each HAVEGE.obj is different in the three versions)
The parameters  (number of iterations in WalkHAVEGE, initHAVEGE1 and
initHAVEGE2) were tuned for the particular Visual C++ optimizations that
were
performed on my system ..
Since I do  not know which optimizations are performed by the compiler, .."
Ovviamente io chiesi spiegazioni in merito, e lui disse:
"The issue is that I had to calibrate the number of unrolled iterations
in the three files WalkHAVEGE, initHAVEGE1 and  initHAVEGE2 in order
to get the code from the inner loop to fit as exactly as possible in the
I-cache.
If you change compiler or any compiler option then the code generated
may change and so so does its size."
Già iniziava a sembrarmi un po' troppo critico, ma volendo provare ad usare
il generatore nei miei programmi, volevo avere pieno controllo sul codice
generato. Così ho chiesto come potevo stabilire il numero di queste
iterazioni. Lui disse:
"I used the rather simple following way:
maintain a constant number total number iterations
(that is the  number of iterations in the loop times the number of
unrolled iterations).
Time the execution (with hardware clock counter), 10 times to avoid
accident associated with unfortunated other activity.
Vary the number of unrolled iterations:
when there is a knee in the curve, you are exceeding the I-cache size."
Io gli feci presente che c'erano tre cicli principali: initHAVEGE1,
initHAVEGE2 e WalkHAVEGE. Quindi gli chiesi di spiegare meglio cosa avrei
dovuto variare per vedere il ginocchio della curva. Ma dopo alcuni messaggi
inconcludenti, abbiamo lasciato cadere la discussione e sono tornato ad
utilizzare il mio fido generatore basato sul tsc.
Per chi fosse interessato, maggiori informazioni e considerazioni in merito
al generatore si possono trovare nei thread dell'anno scorso su sci.crypt.
Cristiano

al generatore si possono trovare nei thread dell'anno scorso su sci.crypt.
Trovati (e letti).
Vedo che la "comunità" non ha proprio accettato a "braccia aperte" le
idee dell'autore ;)
Comunque io ne traggo un singolo insegnamento: può essere una buona
idea mettere un jump condizionale subito prima di un rdtsc =)


 idee dell'autore ;)
Eh! Eh! Direi di no :-)
Avrai notato che i dubbi erano per lo più imperniati sul fatto che il
funzionamento di havege è deterministico.
Cristiano