Newsgroup: it.comp.os.linux.sys
Titolo: Algoritmo hashing

Ciao,
ho la necessità di generare una codice intero (massimo 13 cifre) a partire da una stringa di testo.
 
Pensavo di fare l'sha1 della stringa, tagliarlo a 10 caratteri esadecimali e convertire il tutto in intero.
 
Ovviamente non ci devono essere collisioni (o almeno in numero decisamente limitato)
 
Domanda: a parità di lunghezza, ovvero le prime 10 cifre esadecimali dell'hash, un MD5, SHA1, SHA256 etc etc avranno lo stesso numero di possibili collisioni?
 
Se scendo a 8 cifre, avrò lo stesso numero di collisioni di un CRC32 ?

 Se scendo a 8 cifre, avrò lo stesso numero di collisioni di un CRC32 ?
 
Difficile da dirsi.  Le funzioni di hash impiegate negli algoritmi di
ricerca ed ordinamento sono molte, dissimili e a volte sono studiate 
per una particolare tipologia di dati, L'unico mezzo per derimere la
questione è sperimentare.
 
 


Quante stringhe hai?
Che uso ne fai?
Ti fa differenza usare un semplice contatore?
 
bye,
 
-- 
 
piergiorgio

 Ti fa differenza usare un semplice contatore?
 
...non può essere un semplice contatore (altrimenti userei l'id incrementale del db) in quando tale codice deve essere 'prevedibile' e generabile partendo dal nome stesso del prodotto.
 
Questo perchè l'inserimento dei prodotti avviene da più parti tra
loro scollegate e non sotto la mia diretta gestione.
L'utente1 potrebbe creare un prodotto 'Penna' che avrà come codice 1234.
L'utente2 poi crea un prodotto di nome "penna" (notare il minuscolo) che
dovrà avere sempre 1234 in quanto stesso prodotto.
 
Insomma, devo generare, in maniera prevedibile e ripetibile, un numero univoco partendo da una stringa di testo.
 
Il CRC32 fa il suo sporco lavoro, così come un SHA1 troncato, ma non ho idea di come poter valutare eventuali collisioni e la loro frequenza, per questo ho chiesto qui.

 Insomma, devo generare, in maniera prevedibile e ripetibile, un numero univoco partendo da una stringa di testo.
 
Ma non funziona con "Penna" e "penna".
 
bye,
 
-- 
 
piergiorgio


 
Se ho capito bene tu vuoi che Penna e penna generano un unico id ?
La differenza deve stare solo per maiuscole minuscoli o anche per nomi 
simili ?
 

 Il che e` prevedibile e ripetibile.
 
Non posso, il codice deve essere generato prima dell'inserimento
su DB. I DB in questione sono diversi, per questo mi serve poter
generare un codice unico tra tutti i db e poi, alla fine della fiera,
importare il tutto su un 'unificato'

 simili ?
 
I nomi dei prodotti li possiamo considerare come scritti sempre allo stesso modo in quanto vengono normalizzati per il calcolo degli ID.
 
Sempre nel limite del possibile si intende. 
"Penna" e "Pennetta" sono diversi.
"Penna" e " PeNNa  " sono uguali.

Insomma, devo generare, in maniera prevedibile e ripetibile, un numero univoco partendo da una stringa di testo.
 
E' un problema che nessuno ha risolto dai tempi della Torre di Babele. Io non
credo che riuscirei a risolvere il problema, in modo deterministico, la' dove
miliardi di esseri umani prima di me hanno invariabilmente fallito.
 
Anche l'hash, che SEMBREREBBE una buona idea, in realta' non funziona: ti sei
gia' corretto dicendo che "Penna" e "penna" devono dare lo stesso codice. Con
un po' di riflessione (o amara esperienza, secondo cosa uno preferisce) prima
o poi scoprirai che anche "Pen" deve dare lo stesso codice... e magari, anche
"chiavetta usb" deve dare lo stesso codice di "penna usb", "usb fob", etc..
 
Il requirement vero purtroppo e' una corrispondenza biunivoca fra un codice e
una IMMAGINE MENTALE. Ma per avere quella, bisognerebbe che il computer possa
collegarsi alla mente dell'utente.
 
E, di regola, quando tenti di farlo ottieni solo un errore 404 [1].
 
Leonardo
 
[1] in ambienti Windows, ERR-10061 WSAECONNREFUSED
 
-- 
 
Then felt I like some watcher of the skies, when a new planet swims into his ken;
Or like stout Cortez when with eagle eyes, he star'd at the Pacific; and all his men
Look'd at each other with a wild surmise - silent, upon a peak in Darien.

 "chiavetta usb" deve dare lo stesso codice di "penna usb", "usb fob", etc..
 
No questo non può capitare. Conosco la merce trattata ed il codice è fatto
sul *nome* del prodotto (che già di suo è univoco). Non ci sarà *MAI* un
secondo prodotto che corrisponde al primo e che quindi dovrà avere due
codici uguali. 2 righe nel file di Excel (perchè da questo devo importare)
corrispondono sempre e solo a 2 prodotti diversi.
 
il mio problema è "sperare" che l'hash di tutti i prodotti non generi
collisioni, ma trattandosi di massimo-massimo 6000 prodotti dubito ci
possa essere un qualunque algoritmo che generi 1 collisione ogni 6 mila
 
Ripeto, il mio probleama è poter stimare (e prevedere) le collisioni, non evitare che si presentino. Non sono ferrato in hashing ed algoritmi vari, non
ho idea di come fare a valutare se un CRC32 (o un MD5, o un SHA1) siano in
grado di gestire 6000 stringhe senza collidere e sopratutto in che condizioni
si verifichi una collisione.
 
Esempio: il CRC32 è un intero a 32bit, quindi 2^32 possibili combinazioni.
Questo significa che avrò 1 collisione ogni 2^32 combinazioni di caratteri ?
 
Idem per MD5 ed SHA1, quest'ultimo è più grosso e collide meno. Ma se li tronco a 10 caratteri, avrò la stessa probabilità di collisione su entrambi, essendo di pari lunghezza ?


 
secondo me l'md5 è perfetto per il suo caso (preferibilmente utilizzando 
tutti i caratteri, ma se non è possibile pazienza). Premesso che, 
cambiando anche una virgola cambia TUTTO l'md5, il risultato sarà una 
stringa onestamente abbastanza irripetibile.
 

 partire da una stringa di testo.
 
Se ne era parlato abbondantemente in passato.
 
Usa pure sha1 ma non tagliare nulla. Altrimenti non hai rischio di 
collisioni ma certezze!

 [...]
 
 
Ciao  Manlio

messaggi)
 
Eh... troppo velocemente, mi sa. Un UUID va bene, ma come lo generi? Un tipo
3/5 e' un modo figo ma per rappresentare un hash. Un tipo 4 non e' univoco.
 
Leonardo



OK, è abbastanza semplice
Normalizzi la stringa (Es: converti tutto in  minuscolo e togli tutto 
ciò che non sono lettere e numeri) e usi la stringa normalizzata come 
chiave univoca per il database
 
Non serve trasformare la stringa in un id numerico
 

 10 caratteri, avrò la stessa probabilità di collisione su entrambi, essendo di pari lunghezza?
 
Assolutamente si'. Pero', se hai un limite di 10 caratteri alfanumerici, puoi
usare maiuscole, minuscole, numeri e due segni di interpunzione per un totale
di 64 simboli. Ogni carattere conta 6 bit (base64, appunto).
 
Quindi per es. in PHP scriveresti
 
	substr(base64_encode(hex2bin(md5("PUPPAAAAA"))), 0, 10)  (PHP 5.4+)
o
	print substr(base64_encode(pack('H*', md5(".."))), 0, 10) (PHP 5.3)
 
Unica cosa, il set base64 comprende anche il simbolo "/"... puo' essere utile
convertirlo magari in ^ o $, se va usato in un URL.
 
D'altra parte, con DIECI caratteri esadecimali, hai gia' 40 bit. Q(40) vale a
un dipresso 5*2^18 = 1.3 milioni, magari ci si puo' stare.
 
Leonardo


 questo ho chiesto qui.
 
Attento SHA1, MD5 e  algoritmi di hash crittografici non devono essere
troncai altrimenti la collisione è certa, come già detto altrove. 
 
Invece i vari CRC devono essere troncati perché sono alquanto prevedibili
e quindi crittograficamente insicuri. Paradossalmente troncando a 16 bit
un CRC32 si ottiene una distribuzione di probabilità più vicina alla 
distribuzione uniforme
 
Quanto valgono queste probabilità è presto detto:
 
Dati due soli articoli ed una funzione hash crittografica a 32 bit la
probabilità di collisione è 1/2^32 , con una a 128 bit è 1/2^128.
 
ATTENZIONE la probabilità di collisione va come il quadrato 
degli articoli nel database (confronta il paradosso dei compleanni) .
 
 
 

>> UUID('309c2d4d-01c4-5829-b70f-3929f2f4ff8e')
 
 
Che mi sembra sia quello che voleva fare l'OP, con la differenza che con 
un UUID hai più garanzie che sia unico, specialmente in un ambiente 
distribuito.
 
Tra l'altro UUIDV5 tronca l'hash prodotto da SHA1.
Mi fido di più ad un troncamento fatto da chi ne capisce (si spera), che 
uno fatto da me e che rischia di rompere tutto.
 
 
Purtroppo per l'OP, l'hash è troppo lungo.
 
 
Ciao  Manlio

 un dipresso 5*2^18 = 1.3 milioni, magari ci si puo' stare.
 
Fermi tutti (e lo dico anche a tutti gli altri che hanno risposto):
 
Io devo ottenere un numero *INTERO* quindi al massimo 0-9 di range.
Niente esadecimali o stringhe o caratteri non numeri, per questo converto il 
CRC32 in intero.
 
Quindi, niente SHA1 per intero (troppo lungo), niente MD5 per intero (troppo lungo), niente UUID, ma un semplice, semplicissimo numero intero di massimo 15 cifre.

 sono punto e basta. Stai sbagliando tutto.
 
Ma anche no.
Io non voglio nessuna chiave, ma un *codice prodotto*, l'EAN13, UPC, Quelchetipare, purchè sia un *INTERO*


OK,
quindi:
 
MAX_N=10**15 - 1
ns=normalizzazione_stringa(s)
n=hash(ns)
while(collisione(n,ns)) { if (n == MAX_N) n=0 else n++ }
 
// n è l' indice voluto
 
Ora devi solo sviluppare le 3 funzioni
 
 
 
 
 


con l'MD5 sei sicuro di avere collisioni:
http://it.wikipedia.org/wiki/Secure_Hash_Algorithm
 
 
Stessa cosa con i CRC.
 
Ciao Jack -- Yoda of Borg am I! Assimilated shall you be! Futile
resistance is, hmm?

CRC32 in intero.
 
Ma va bene. Il numero di bit coinvolto e' *all'incirca* 3.3 per cifra. Quindi,
con 15 cifre, hai circa 50 bit.
 
Volendo, puoi troncare un hash e convertire da base 16 a base 10, per ottenere
un numero intero.
 
50 bit a quattro bit per carattere fanno 12.5; quindi fai
 
	base_convert(substr(md5("..."), 0, 12), 16, 10);
 
e ti viene un numero di massimo 15 cifre (la prima cifra sara' <= 2), per es.,
2230241019696.
 
E per avere una probabilita' del 50% di collisioni, ti servono una trentina di
milioni di prodotti.


uno fatto da me e che rischia di rompere tutto.
 
In molte applicazioni (e in generale per "reimplementare") e' Vangelo. In
questo caso specifico, non fa differenza.
 
(Comunque, per essere proprio pignoli pignoli, la mia implementazione che
deriva un numero intero da una stringa hex e' fallata, in quanto c'e' una
probabilita' di collisione leggermente maggiore dovuta al fatto che sulla
prima cifra non ci si estende sul range 0-9, ma solo 0-2. Si tratta cioe'
di soli 49 bit di entropia. In alcune applicazioni questo sarebbe, se non
altro, da tenere in considerazione).


 importare il tutto su un 'unificato'
 
Perche` mi dai le informazioni una goccia
alla volta? :-)
 
E non conviene usare un unico DB in remoto,
immagino?
 
bye,
 
-- 
 
piergiorgio


http://it.wikipedia.org/wiki/Secure_Hash_Algorithm
 
 
Anche con SHA1. Basta che tu abbia 2^160+1 codici prodotto, e c'e' la
certezza matematica che almeno una collisione ha da esserci.
 
Quella che viene chiamata "certezza di collisione" con MD5 (e CRC-32)
e' semplicemente la vulnerabilita' ad un attacco deliberato.
 
Nel caso di CRC-32 il discorso e' "un po'" meno preciso perche', come
ricordava mallin.shetland, le caratteristiche *statistiche* di CRC-32
non sono granche' buone, e quindi la "probabilita' di collisione" non
e' minima per qualunque input.
 
Leonardo


gandalf.co...@gmail.com
 ha pensato forte :

Quindi se penna viene inserito da 2 db distinti deve essere inserito 
con lo stesso codice. Giusto?
Ed immagino che la query sul db unificato non sia proponibile. Giusto?
 
-- 
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 Ed immagino che la query sul db unificato non sia proponibile. Giusto?
 
Non è proponibile

 alla volta? :-)
 
Perchè la mia domanda è "ho la necessità di generare una codice intero (massimo 13 cifre) a partire da una stringa di testo.", il cosa ci deve fare è ininfluente. Potrei anche volerlo generare perchè ho una settimana di ferie e non so come passare il tempo.
 
Il database è solo il posto in cui salvarlo, ma il mio problema permane.
Ho una stringa X, devo generare un numero Y intero a partire da essa.
Il CRC32 sembra perfetto, salvo collisioni che sto valutando.

 milioni di prodotti.
 
Ok, ragioniamo su questo.
1. perchè la prima cifra sarà minore di 2 ? (non mi è proprio chiaro)
2. La *prima* collisione dopo quanto si verifica? Come lo calcolo ? 
Ma sopratutto, con quali modalità si verifica una collisione? Provo a spiegarmi:
 
Supponiamo di avere un algoritmo con probabilità di collisione 1:20000
Significa che ogni "20000" avrò una collisione.
Supponiamo un codice di sole 3 lettere: aaa, bbb, ccc
Le combinazioni possibili, usando solo lettere, sono 26^3, ovvero: 17576
In questo caso, è tecnicamente impossibile avere una collisione anche 
cambiando tutte le lettere in ogni sorta di combinazione possibile perchè
avrò al massimo 17576 combinazioni ed una collisione ogni 20000.
 
Eppure, non ne sono troppo convinto.

 avr� al massimo 17576 combinazioni ed una collisione ogni 20000.
 
nope. Se hai sfiga l'algoritmo va in collisione con aaa e aab (cioe'
crea lo stesso hash), poi per i 19998 termini successivi crea hash
diversi.
 
IMHO ti conviene andare su un qualche newsgroup di crittografia e
chiedere li.


 significa che se tiri 19999 sei sicuro che non esca.
 
Ottimo. Ora è chiaro: va a culo. Era proprio la parte che non mi era chiara.

 Quelchetipare, purchè sia un *INTERO*
 
Parliamo chiaro, Tu vuoi un numero univoco o no?
 
Se deve univoco tanto vale consideralo un valore chiave e buonanotte,
 
Se invece sono tollerate collisioni Leonardo Seni già ti ha indicato 
l'ordine di grandezza della loro probabilità. E non si discute.
 
Puoi anche usare EAN13, o meglio replicarlo, ma tieni presente
che è diviso in tre parti e c'è una autorità che garantisce l'univocità
del numero. E proprio questo tu non puoi fare.
 
 


semplice programmino di generazione
Non usare per crittografia e non tiene conto delle eventuali collisioni:
 
 
#!/usr/bin/perl
use strict;
use warnings;
 
use constant {
	MAXN		=> 10**13-1  # numero di max 13 cifre
	,ASCII_MIN	=> ord('0')  # ascii del carattere piu basso accettato
	,ASCII_MAX	=> ord('Z')  # ascii del carattere piu alto accettato
};
 
use constant {
	EXP => int(MAXN  / (ASCII_MAX - ASCII_MIN))   # coefficiente di espansione
};
 
 
sub c {
	my $s=shift;
	my $n=0;
	for my $i(0..length($s) - 1) {
		my $c=(ord(substr($s,$i,1)) - ASCII_MIN) * EXP;
		$n += $c;
		$n %= MAXN if $n > MAXN;
	}
	$n;
}
 
print c("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"),"\n";
print c("penna"),"\n";
print c("libro"),"\n";
print c("0"),"\n";
print c("1"),"\n";
print c("2"),"\n";
 
 
 

 avrò al massimo 17576 combinazioni ed una collisione ogni 20000.
 
 
No perché le collisioni vanno col quadrato del numero delle istanze.
Mi spiego:
 
Con N istanze tu hai N·(N-1)/2 possibili coppie che possono provocare 
collisione e quindi la probabilità aumenta di un fattore (N^2-N)/2 (per N
piccolo, il calcolo vero  ha mostrato Jack come si fa).
 
Ora con 17576 codici hai 154449100 coppie e 154449100 possibili
collisioni, molto più delle tue 20000 probabilità.
 
 
 

 il calcolo vero  ha mostrato Jack come si fa).
 
Mi scuso, ho sbagliato, rendiamo onore a chi ha il merito,
il colpevole della spiegazione corretta è Leonardo Seni.

avrò al massimo 17576 combinazioni ed una collisione ogni 20000.
 
Eh, no, lo hash non funziona in questo modo.
 
Ma forse c'e' una scappatoia. Quanto e' lungo il campo di testo da cui prendi
i codici prodotto?


 Il CRC32 sembra perfetto, salvo collisioni che sto valutando.
 
Il problema che tu hai, se ho ben capito, e`
che i codici devono essere identici (a parita`
di "descrizione"), ma essere generati in modo
indipendente. Cioe` senza che si condivida un
qualcosa, a parte la funzione hashing.
 
bye,
 
-- 
 
piergiorgio

 qualcosa, a parte la funzione hashing.
 
Esatto.
Ed hanno ulteriori restrizioni:
1. devono essere generati indipendentemente, senza appoggiarsi ad entità esterne come un db
2. deve essere un numero intero, 5, 10, 13, 15 cifre non importa, basta che sia umanamente leggibile (quindi non sopra le 15 cifre direi)
 
Tutto questo assurdo casino perchè lo stronzo d'un cliente non vuole cambiare il gestionale. Gli possa venire la diarrea a squizzi.

2. deve essere un numero intero, 5, 10, 13, 15 cifre non importa, basta che sia umanamente leggibile (quindi non sopra le 15 cifre direi)
 
Se possiamo ignorare gli spazi, le differenze maiuscolo/minuscolo (per cui
PIPPOTRON 1A, PippoTron 1a, PIPPO TRON1 A e PIPPOTRON 1 **A** sono *tutti*
sempre la stessa cosa), allora in 15 caratteri numerici ci sta dentro piu'
o meno 15*LN(10)/LN(36) = 9.6 caratteri di testo.
 
Si possono tentare millanta cose... ma quella che raccomando io e' di dire
al cliente "Non si puo' fare".
 
E' come se fosse affezionato al suo vecchio monitor monocromatico, eppero'
volesse vedere un grafico a colori. Su quel monitor. Non si puo' fare. Uno
puo' inventare i toni di grigio, gli stipple, adesivi trasparenti colorati
sovrapposti al monitor - c'erano kit per colorare le TV, un secolo fa -, e
chissa' cos'altro.
 
Ma rimane vero che una soluzione che funziona sempre nun se po' trova'. E'
come la magia: per acquisire poteri di qua, devi porti dei limiti di la' -
se non accetti limiti, non puoi fare una ceppa. Oh, per avere la saggezza,
perfino Odino dovette cedere un occhio.
 
Cambiando i presupposti, magari, uno puo' fare un sacco di cose.
 
Puoi consegnare ai clienti "N" scatole nere contenenti l'algoritmo segreto
che converte qualunque stringa, di qualunque lunghezza, in un codice di 15
cifre garantito univoco, garantito lo stesso su tutte le scatole.
 
Costo: 20 milioni di euro per realizzarlo, 300 EUR a scatola, ed ogni anno
un centinaio di euro a scatola per il noleggio.
 
Ah - le scatole non funzionano se non entrano in comunione con il Cosmo, e
quindi non possono essere installate in gabbie di Faraday, sotto montagne,
e in genere ovunque un telefonino TIM non prenda l'internètte.


 cifre garantito univoco, garantito lo stesso su tutte le scatole.
 
No, non univoco, ma univoco per 6000 stringhe differenti.
 
Comunque so che gli è stato proposto il cambio di gestionale, la prima risposta è stata un "No", la seconda un "Ci devo pensare"
 
Se tanto mi da tanto, cambia idea, ed in tal caso, posso generare un codice univoco senza problemi passando per il DB.
 
 
P.S: leggevo in questo thread degli UUIDv4. Non sono univoci, vero, ma la loro probabilità di collisione è talmente bassa da poterli considerare tali (noi li usiamo ovunque)

 e in genere ovunque un telefonino TIM non prenda l'internètte.
 
 
HAHAHAHAHAHAHAHAHAHA
 
(Se lo fai dimmelo, che ci metto una quota :-D)
 

 P.S: leggevo in questo thread degli UUIDv4. Non sono univoci, vero, ma la loro probabilità di collisione è talmente bassa da poterli considerare tali (noi li usiamo ovunque)
 
Si', ma la probabilita' non e' dovuta all'algoritmo, ma solo al fatto che (con
la condizione NECESSARIA "l'algoritmo e' buono") nell'UUID ci sono tanti bit.
 
Se invece di 15 numeri tu potessi usarne, vediamo, 3 cifre sono ~10 bit... 40,
avresti la stessa sicurezza di MD5. Con 50 numeri, la stessa di SHA1.


 decisamente limitato)
 
 
hash + salt: con 1500 stringe le possibilità di collisioni sono NULLE.
 
 
#!/usr/bin/env python
import hashlib, uuid, sys
mia_stringa = sys.argv[1]
salt = uuid.uuid4().hex
hashed_password = hashlib.sha512(mia_stringa + salt).hexdigest()
 
print hashed_password
 
però... per ottenere nuovamente lo stesso hash, devi riutilizzare lo 
stesso salt. Pertanto devi memorizzare anche il salt.
 

 
 
STRONZATA MEGAGALATTICA. 
Come se non avessi scritto nulla. 
Con il salt le possiblità di collisione paradossalmente aumentano, poiché 
una combinazione di due diversi "salt + stringa" potrebbero avere come 
regola (e non come eccezione) una corrispondenza con lo stesso hash.
Questo servirebbe solo a proteggerti contro il metodo umbrella. Ma 
aumenterebbe il rischio collisioni...
 
Comunque, IMHO, le possibilità di collisioni con 1500 stringhe, potrebbero 
essere un fattore trascurabile!

essere un fattore trascurabile!
 
Supponendo che l'hash sia perfetto, cioe' distribuisce perfettamente l'output,
allora troncando a dieci caratteri hex (40 bit) la probabilita' e'
 
	1.0 - (2^40)!/((2^40)^1500 * (2^40 - 1500)!)
 
...nel caso che uno non abbia comodita' di calcolare il fattoriale di 2^40 :-)
si puo' andare di iterazione.
 
Viene all'incirca:
 
	P(1500)	= 1 su un milione
 
	P(6000) = 16 su un milione
 
	P(10000) = 45 su un milione
 
	P(47000) = 1 su mille
 
con andamento quadratico, come gia' ricordato da mallin.shetland: se il numero
di stringhe raddoppia, la probabilita' di una collisione quadruplica.



 
 
 
Se poi si sa quali sono (le stringhe) la risoluzione del problema è 
alquanto banale e collisioni 0
 
 
 

 
 
Giusto per tagliare la testa al toPo, ho fatto
una prova con:
 
cat /usr/share/dict/words | tr '[:upper:]' '[:lower:]' | sort | uniq |
parallel --gnu -P 16 -n 1 -r 'echo -n "{}" | md5sum' | cut -c1-10 | tee
/tmp/red/md5cut.txt | sort | uniq -d
 
Assumendo che lo script sia corretto :-), mi da
5 collisioni, tutte con d41d8cd98f, che pare siano:
 
-ee
-een
-en
-ene
-n
 
Il vocabolario e` inglese:
 
$> wc -l /usr/share/dict/words
479828 /usr/share/dict/words
 
A proposito, se qualcuno mi desse una dritta su
come velocizzare il calcolo del md5 gli/le sarei
molto grato (lo script di cui sopra perde piu`
tempo in fork che nel calcolo e non migliora
con altri parametri per "-P").
 
bye,
 
-- 
 
piergiorgio

 con altri parametri per "-P").
 
usando un linguaggio di programmazione invece di tanti programmini messi
insieme con lo sputo penso aiuterebbe.
 
Ciao Jack


 insieme con lo sputo penso aiuterebbe.
 
Certo, per esempio?
Postami il programma, no?
 
So benissimo che se fosse scritto in C
sarebbe piu` veloce, ma voglio vedere
quante persone riescono a scrivere il
programma in C (od altro) in meno tempo
rispetto a quello che serve per farlo in
shell script.
 
bye,
 
-- 
 
piergiorgio

 Postami il programma, no?
 
Grezzo....
$ cat /etc/hosts | perl -e 'use Digest::HMAC_MD5 qw(hmac_md5_hex); while
(<STDIN>) { printf "%s\n",hmac_md5_hex("",$_);}'
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 (<STDIN>) { printf "%s\n",hmac_md5_hex("",$_);}'
 
Ottimo!
Thanks!
 
bye,
 
-- 
 
piergiorgio

 
 
Quasi esatto, non deve fare l'MD5 di '\n".
 
bye,
 
-- 
 
piergiorgio

 Quasi esatto, non deve fare l'MD5 di '\n".
 
$ cat /etc/hosts | perl -e 'use Digest::HMAC_MD5 qw(hmac_md5_hex); while
(<STDIN>) { chop ; printf "%s\n",hmac_md5_hex("",$_);}'


 (<STDIN>) { chop ; printf "%s\n",hmac_md5_hex("",$_);}'
 
Non funziona ancora, questo non mi ritorna
le collisioni che ho trovato con l'altro
(e che ho verificato a mano).
 
echo 1 | tr '[:upper:]' '[:lower:]' | sort | uniq | perl -e 'use
Digest::HMAC_MD5 qw(hmac_md5_hex); while (<STDIN>) { chop;printf
"%s\n",hmac_md5_hex("",$_);}' | cut -c1-10 | tee /tmp/red/md5cut.txt | sort
db9409c5b0
 
echo 1 | tr '[:upper:]' '[:lower:]' | sort | uniq | parallel --gnu -P 16
-n 1 -r 'echo -n "{}" | md5sum' | cut -c1-10 | tee /tmp/red/md5cut.txt |
sort
c4ca4238a0
 
echo -n 1 | md5sum
c4ca4238a0b923820dcc509a6f75849b
 
Non e` lo stesso md5sum? Sbaglio qualcosa?
 
bye,
 
-- 
 
piergiorgio

 Non e` lo stesso md5sum? Sbaglio qualcosa?
 
Quello che ti avevo dato è HMAC... se lo vuoi nella modalità di md5sum
puoi usare questo:
perl -e 'use Digest::MD5 qw(md5_hex);while(<>){printf "%s\n",md5_hex;}'


 perl -e 'use Digest::MD5 qw(md5_hex);while(<>){printf "%s\n",md5_hex;}'
 
Sempre "sbagliato". E` uguale all'altro.
 
echo 1 | tr '[:upper:]' '[:lower:]' | sort | uniq | perl -e 'use
Digest::MD5 qw(md5_hex);while(<>){chop;printf "%s\n",md5_hex;}' | cut
-c1-10 | tee /tmp/red/md5cut.txt | sort
d41d8cd98f
 
echo -n 1 | md5sum
c4ca4238a0b923820dcc509a6f75849b  -
 
bye,
 
-- 
 
piergiorgio

 (<STDIN>) { printf "%s\n",hmac_md5_hex("",$_);}'
 
quel "cat" + " "perl" messi insieme con lo sputo della pipe non si possono 
vedere :) 
perl -e 'use Digest::HMAC_MD5 qw(hmac_md5_hex); while
(<STDIN>) { printf "%s\n",hmac_md5_hex("",$_);}' < /etc/hosts

 d41d8cd98f
 
Noto ora che avevo dimenticato un "$_" come parametro di md5_hex :)


 Noto ora che avevo dimenticato un "$_" come parametro di md5_hex :)
 
Con questo viene meglio :-)
 
Tra l'altro notavo che le collisioni trovate (con
lo script iniziale) sono tutte con "-eXYZ".
Il motivo e` che "echo" non digerisce, senza escape,
qualcosa come "echo -eXYZ"....
 
Quindi, sul dizionario inglese, le collisioni dei
primi 10 _caratteri_ di MD5 sono nulle.
 
bye,
 
-- 
 
piergiorgio

-n
 
Non e' possibile. "-ee" ed "-en" dovrebbero avere un 50% di bit diversi
per costruzione.
 
Non e' che il tuo md5sum legge "-" come un'opzione? (Il mio no... pero'
hai visto mai).


 hai visto mai).
 
Non e` "md5sum", e` "echo".
 
Come scritto nell'altro post, "echo -een" da
un problema. Cosi come gli altri "-eXYZ}.
 
bye,
 
-- 
 
piergiorgio

Non e` "md5sum", e` "echo".
 
Colpa mia: avevo visto solo l'inizio del thread e avevo ignorato il resto,
convinto che vi steste inoltrando nei meandri del Perl :-)
 
In realta', ci potevo anche arrivare da me.


 Non è proponibile
 
Ciao dovrei farti ancora mille domande per capire se la mia idea è 
realizzabile o no ma ho poca voglia di farle e probabilmente tu poca 
voglia di leggerle e rispondere. Quindi preferisco raccontarti l'idea e 
lasciare a te il compito di valutare se applicabile alla tua realtà.
 
Se lavori con un codice come descritto nei vari thread hai 
statisticamente, dove più e dove meno, possibilità di collisioni. Hai 
detto che questo non è un problema perché il codice in collisione lo 
scarti. Forse queto non è più vero se la collisione avviene su due db 
remoti distinti e quindi prima di renderti conto dell'esistenza della 
collisione hai già preso delle iniziative sui due codici coincidenti.
 
L'idea è di lavorare su codici univoci garantiti sezionando il percorso 
del dato.
Il codice viene diviso in una parte db remoto ed una parte codice 
prodotto. La dimensione della suddivisione dipende da quanti db remoti 
hai e da quanti prodotti devi gestire.
In questo modo la garanzia di univocità del prodotto su db locale lo 
puoi ottenere con un banalissimo progressivo.
Per fare un esempio potresti avere:
 
Dal db remoto 1
penna  0112345
matita 0134567
 
Dal db remoto 2
penna  0234352
matita 0112345
 
Tutti i codici così prodotti sarebbero univoci dalla nascita remota al 
centro.
Avresti però che penna  è registrato con più codici. Se questo dovesse 
essere un problema dovresti prevedere una tabella di trascodifica che 
inserisca centralmente ad esempio penna sul codice 0012345 e quindi 
nella tua tabela dovranno comparire due colonne: codice di partenza e 
codice d'arrivo.
 
0112345 -> 0012345
0234352 -> 0012345
 
Ottenendo univocità su tutti i database e senza scartare nessun codice.
A te valutare se applicabile al tuo ambiente.
Ciao
 
-- 
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 matita 0112345
matita 0212345
