Newsgroup: it.comp.www.php
Titolo: Creare stringa univoca si può ?

Salve NG
sto usando questa riga per creare un id stringa univoco da associare
all'id numerico del record
ma mi è venuto un dubbio.
In sostanza, potrei creare doppioni nel tempo?
$key_stanza = sha1(uniqid(date('dYm').time(),true)));
Grazie
Alex

 Alex
perch� non provi con il timestamp? � un valore che cresce sempre e non 
pu� essere pari o diminuire..
Logan

 $key_stanza = sha1(uniqid(date('dYm').time(),true)));
uniqid() basa la sua univocita' sullo scorrere del tempo, quindi mettere un
"seme" che ha la medesima fonte di entropia non so quato potrebbe essere utile.
Se vuoi essere sicuro, io utilizzerei un'altra fonte di entropia, come per
esempio in numero di byte liberi nel file system corrente diviso (o associato)
magari per un altro valore con diversa fonte di entropia (/dev/urandom, per
esempio).
Non so se l'applicazione di SHA1 potrebbe ridurre le collisioni perche' si
tratta di un algoritmo deterministico, nel senso che lo stesso input provoca
sempre lo steso output, quindi nel tuo caso ci potrebbe essere un rapporto 1:1
tra input e output visto che il dominio dell'input credo (non ho fatto le
verifiche del caso) sia inferiore al dominio dell'output.
Certo che se fai un SHA1 di uniqid() associato a /dev/urandom (o similare)
potresti avere una ragionevole aspettativa dell'univocita' del risultato.
Devi tener presente comunque che SHA1 restituisce un numero finito di valori.
Grandi quanto vuoi, ma finito. Tutto dipende da quanto vuoi che sia univoco il
tuo valore.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
Moneypenny: In the conference room. Something pretty big.
Every double-o man in Europe has been rushed in.
And the home secretary too!
James Bond: His wife probably lost her dog.
    --"007 Thunderball"

 In sostanza, potrei creare doppioni nel tempo?
Perch� non un UUID?
Avresti un doppione solo generando 1 miliardo di UUID per ogni
secondo dei prossimi 100 anni.
E non ti devi preoccupare dell'entropia o cose simili.
Lo generi e basta.

Grazie
Diciamo che il timestamp è facilmente identificabile per l'uso del mio
caso
Fondamentalmente a me serve mascherare l'id con una altro id
randomizzato, che abbia una certa complessità ma che mantenga la sua
univocità rispetto ai suoi simili. Il fattore reversibilità non mi
interessa in questo caso perchè non sto criptando un valore ma cerco
di ottenere una "pseudo replica" dell' id stesso.
Cosa c'è di più univoco e progressivo della data, dell' ora, dei
minuti, dei secondi e di msec, a questo ho pensato.
Leggendo qua e la però mi pare di capire che adottando il mio caso
potrei avere 1 possibilità su 4 miliardi (di chiavi generate) che
avvenga una collisione tra esse.
Stavo pensando in fondo che un controllo di esistenza prima di
inserire la key nel db possa essere accettabile dato il fine del
processo.
Non so, se a voi vengono idee migliori io sono qui....
grazie
Alex

 Non so, se a voi vengono idee migliori io sono qui....
Lascia il controllo al DB: indicizza il campo key come univoco, inserisci la key
e gestisci l'eventuale errore.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
When in doubt, predict that the present trend will continue.


Vero?
Massì, in fondo 1 su 4 miliardi ce posso sta !!!!
@gandalf
grazie proverò
Alex

$key_stanza = sha1(uniqid(date('dYm').time(),true)));
Il rischio c'e', ma e' mooooolto basso.
Comunque, perche' non usi semplicemente
	$key_stanza = sprintf("%08lx%05lx",
		time()-1266666666, substr(microtime(),2,6));
Sono 13 caratteri - sha1 sono cosa, 40? - e ha due sole limitazioni: non
devi avere due transazioni nello stesso microsecondo, e non funziona pi�
dopo il 2068 (2038 se togli il "-1266666666").
Con queste limitazioni, pero', l'assenza di duplicati e' garantita :-)
Leonardo
-- 
The cock doth craw, the day doth daw,
the channerin' worm doth chide:
gin we be mist oot o' oor place,
a sair pain we maun bide.

 
Non mi son mai piaciuti i codici con parti uguali
anche dopo molte esecuzioni. Nel tuo esempio la prima parte
� sempre uguale, non mi hanno mai convinto, sembrano facilmente
prevedibili.

 $key_stanza = sha1(uniqid(date('dYm').time(),true)));
Secondo me ti stai complicando troppo la vita per niente.
Usa solo uniqid, con un prefisso nullo e more_entropy a true.
Usa un prefisso solo se devi condividere uno spazio con altre 
applicazioni (per esempio, se usi uniqid per creare nomi di file 
temporanei in /tmp e anche altre apps lo fanno o potrebbero farlo), ma se 
devi usarlo solo nel tuo DB e solo in una tabella, togliere il prefisso 
genera risultati piu` univochi.
Non usare sha1 o md5, perche` su stringhe corte (come in questo caso) 
hanno un rischio di collisioni piu` alto, e non aggiungono niente alla 
casualita` di uniqid (che e` gia` una funzione di hashing, solo che viene 
applicata direttamente al tempo in microsecondi e non a input arbitrari).
Bye.

Capito...
Per curiosita, cosa daresti in pasto ad sha1 con uniqid per diminuire
la prob di collisione?
Grazie
Alex

 prob di collisione?
Niente. Era quello il succo del discorso. Non usare sha1/md5 assieme a 
uniqid. O usi uno l'altro.
uniqid fa piu` o meno la stessa cosa di
$prefix . md5(microtime())
e di 
$prefix . sha1(microtime())
Tu faresti mai sha1(md5(rand())) ? No, perche` non serve a niente hashare 
un hash...
Bye.

non mi hanno mai convinto, sembrano facilmente prevedibili.
La prima parte d� non-ripetibilit�. La non-prevedibilit� te la d�
microtime().
Niente ti vieta di baroccare il codice aggiungendo
	$key_stanza = md5($secret . $key_stanza);
...ma la probabilita' di collisioni non puo' che *aumentare*.


> Non usare sha1 o md5, perche` su stringhe corte (come in questo caso).....
Mi riferivo a questo passaggio, per stringa corta intendi il prodotto
generato da sha1/md5 ?
se è così non avevo capito
Alex



No, mi riferivo a quello prodotto da uniqid(), che e` di 23 caratteri.
md5 (soprattutto) e sha1 danno il meglio di se` su dati di diversi KB/MB, 
mentre con pochi byte non riescono a lavorare bene.
Bye.

miciomao ha scritto:

non vorrei dire ma se non ricordo male per� lo sha512 � esente (ad oggi) 
da collisioni...non vale direttamente usare quello al posto di sha1 e 
md5 che mi risultano abbiamo dimostrato che potrebbero esserci 
collisioni? certo avendo comunque l'entropia generata da un random + o - 
irripetibile