Newsgroup: it.diritto.internet
Titolo: hash e verifica dei dati informatici

Se firmo ed invio una lettera dove dichiaro che i file richiesti e che 
quindi ti passo hanno quella chiave hash, i file dovrebbero essere 
validi già in formato digitale (senza bisogno di firma digitale).
Mettiamo per comodità che consegno a mano ed ottengo una ricevuta con 
tutti i crismi, compresa la coincidenza tra digest di hash dichiarato e 
file consegnato.
Mettiamo anche che ad entrambi questa tecnica va bene.
Un esempio può essere un progetto allegato ad un preventivo o ad domanda 
di contributo; per pura semplicità mettiamo c'è il disegno quotato della 
porta di casa, altezza 200 centimetri.
MA cosa dite che accada in caso di contenzioso ?
Caso A) La porta è 200 cm ma sostengo di averla voluta di 220.
Caso B) La porta finita è di 170 cm e l'artigiano dichiara che coincide 
a quanto chiesto, nonostante le mie rimostranze
Buona serata

 MA cosa dite che accada in caso di contenzioso ?
Fermo restando il fatto che il giudizio è un terno al lotto, certamente
nessun CTU capace di fare il proprio lavoro potrebbe asserire che un
simile documento non sia valido per provare l'autenticità del file.
Ovviamente deve essere fornito il documento di progetto e questo deve
essere in uno dei formati adatti all'uso nella firma digitale, come
p.es
. il formato PDF/A, dato che in caso di formati non approvati
sarebbe possibile inserire contenuti dinamici che ne inficiano la validità.
-- 
Flavio Visentin
2006: l'onestà  2007: la storia  2008: la leggenda  2009: il mito epico
2010: l'apoteosi!! 3 TITULI!!! Scudetto, Coppa Italia, Champions League
   Far rodere un cretino come ponziopilato è godurioso come 4 TITULI!


Si, ho omesso per semplicità che comunque devono esser definiti dei 
criteri nel fornire i dati; sicuramente l'uso esclusivo di file formato 
pdf/a ne è cardine principale.
Per le ragioni che dici tu, per permetterne la consultazione nel tempo, 
e anche per ovviare ai più svariati trucchi.
Grazie del parere, se hai altro..


Ritieni possano andar bene anche i file immagine .ISO  ?




Certamente.
La firma sull'hash testimonia che l'ISO non è stata modificata.
Può sempre darsi che uno a voce abbia sempre detto una cosa e poi sull'ISO
ne abbia consegnata un'altra, sicuro che non sarebbe stata controllata, ma
questo e' un problema diverso e non si risolve con le firme.
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!


Grazie Leonardo.
(anche se un po tardi..)

 a quanto chiesto, nonostante le mie rimostranze
Si prende il progetto, si legge 200 ed il gioco è (quasi) fatto.
-- 
"Molti tra i vivi meritano la morte. E parecchi che sono morti avrebbero
meritato la vita. Sei forse tu in grado di dargliela? E allora non essere
troppo generoso nel distribuire la morte nei tuoi giudizi: sappi che
nemmeno i più saggi possono vedere tutte le conseguenze". (J.R.R. Tolkien)


ottimo, grazie del contributo.
Un ultima..
Chiaro che è meglio l'ultima delle due ma..
dici che basta l'hash sha1 (come da norma per la "digital signature") 
oppure che questa debba essere abbinata all'MD5 (come nell'informatica 
forense) ?

 forense) ?
SHA-1 e MD5 sono funzionalmente la stessa cosa, MD5 è bacato, SHA-1 anche 
lui e vanno considerati insicuri per qualunque uso in cui la sicurezza 
crittografica sia importante.
Ciao,
-- 
  Daniele Orlandi					つづく

 crittografica sia importante.
Non sono d'accordo.
E' vero che ad oggi sono state ottenute collisioni per l'MD5 e l'SHA-1, ma
non mi risulta siano mai state ottenuti risultati "forensi" su questo
fronte (leggi repudiabilità della prova).
Per l'SHA-1 vale più o meno quento detto per l'MD5, ma se utilizzati
congiuntamente sfido chiunque a generare una collisione valida per entrambi
(almeno ad oggi).
Poi ovvio che più si "sale", più aumenta la sicurezza (ma anche il tempo di
calcolo) ed avenbdone la possibilità sarebbe bene utilizzare qualòcosa di
più robusto (SHA 512, Whirpool etc.), ma dire che sono "bacati" IMHo è un
po' eccessivo.
ciao
-- 
Windows mi da' quella sensazione di Indiana Jones che Linux non penso
mi dara' mai, l'oscura impressione di avere una legione di thugs alle
calcagna e di non sapere se riusciro' a portare a casa la pelle.
                               (Leonardo Serni)

 un po' eccessivo.
Mi sa che abbiamo standard un po' diversi su quali siano i difetti 
sufficienti a marcare un algoritmo come bacato :)


 sufficienti a marcare un algoritmo come bacato :)
Un conto è poter generare una collisione MD5 tra due insieme di dati
arbitrari, un altro conto è 
p.es
. riuscire a generare una lettera di
senso compiuto scritta in italiano in cui risulti la misura della porta
con altezza di 220 cm e che l'hash della lettera collida con quella che
riporta la misura di 200 cm.
Forse applicando l'RFC 2795 ci si riesce, ma per una perizia in un caso
come questo ti assicuro che l'MD5 costituisce una prova più che valida. :-)


sufficienti a marcare un algoritmo come bacato :)
Il che e' logico, visto che lavorate in due ambiti molto diversi ;-)
Comunque, se uno deve cominciare adesso, puo' partire da SHA512, cosi'
si cava la voglia.


 sufficienti a marcare un algoritmo come bacato :)
più che probabile visto che lavoriamo in ambiti diversi ;)
Oh qui si ritiene che il report fax è attendibile come data di invio, fai
te ;)
-- 
Contrordine compagni! La frase pubblicata sull'Unità: "I compagni che non
volano sono traditori", contiene un errore di stampa, e pertanto va letta:
"I compagni che non votano sono traditori". (dal Candido, 7 marzo 1948)

 si cava la voglia.
Magari si potesse. Credo che tutti i tool siano fermi all'SHA-256 (nella
migliore delle ipotesi).


 sicuro.
Ho appena scoperto che il TALON (Logicube), supporta l'SHA256.
http://bayit-gmbh.de/TalonMan.pdf
Ed anche l'hard copy 3
http://www.voomtech.com/downloads/HardCopyIII/HC3%20Spec%20Final%20Voom%20nn%2003-18-10.pdf
Resta il fatto che i tool di analisi più diffusi sembrerebbero fermi
all'MD5:
http://www.digitalintelligence.com/software/guidancesoftware/encase/
 
-- 
— Secondariamente tu non hai nessun diritto da accampare perché non sei una
persona fisica. Tant’è vero che non sei nato!
— Però sono morto!
— E come può morire chi non è nato? (G.Guareschi)

 riucorda la discusione sulle PS3 e l'esercito USa?)
Ahem... era l'USAF non US Army
http://nwlinux.com/air-force-playstation-supercomputer-condor-cluster/
http://www.tomsguide.com/us/ps3-air-force-usaf-playstation,news-5297.html
:)

 (nella migliore delle ipotesi).
Puoi sempre ricompilare OpenSSL con il supporto ECC <grin>

 :)
E c'hai ragione, c'hai...
-- 
We few, we happy few, we band of brothers.
For he to-day that sheds his blood with me,
Shall be my brother; (W. shakespeare Enrico V, atto IV, scena II)

Teoricamente una cosa del genere è fattibile?
Si', tranquillamente. E dato il funzionamento di MD5 e altri hash, basta
operare su uno (o comunque pochi) byteblock per generare i vari hash, e'
superfluo utilizzare il file originale. Il che consente di implementare,
teoricamente, un approccio à la rainbow table.


 richiederebbe n-mila anni.
Nella teoria ciò è fattibile, nella pratica però è attualmente
computazionalmente "fuori portata" (nel senso che nessuno di noi ha a
disposizione un supercomputer da un petaflop a disposizione per qualche
mese/anno).
C'è anche da dire che utilizzando due hash di origine matematica diversa
(
p.es
. sha-2 e whirpool) al posto di uno solo, le probabilità di
riuscire a computare una doppia collisione diventano praticamente
infinitesime.
L'abbinamento di due hash differenti, ancorché di algoritmi "weakened"
come md5 e tiger, è tendenzialmente sempre più sicuro del singolo hash


richiederebbe n-mila anni.
Probabilmente un numero considerevole. Anche il solo MD5... 1E+36 prove
nella migliore delle ipotesi, andando grassi, 1E+30 secondi (e sono più
che buono), un anno sono 3E+7 secondi, diciamo un milione di computer a
lavorare, siamo sempre nell'ordine dei mille miliardi di anni.


 creare un file pseudo-buono con lo stesso hash dell'altro.
Occhio però: avresti un file avi con degli header 'strani', si vedrebbe
ad occhio che è stato fatto apposta per far combaciare gli hash.
-- 
ValeRyo
XT600 "Katoki Pajama" - 
http://www.slimmit.com/go.asp?7Y9
GamerTag: 
http://card.mygamercard.net/IT/nxe/ValeRyo76.png
 

ad occhio che è stato fatto apposta per far combaciare gli hash.
No, se aggiungi dei chunk nulli questi sono ignorati in lettura, e dentro
a ciascuno puoi sistemarci quattro byte a piacere... sufficienti per fare
un aggiustamento dello hash.
Oppure puoi aggiungere, in fondo al filmato, un singolo keyframe, che non
sia seguito da niente; a quel punto passa inosservato e ti mette a totale
disposizione un buon migliaio di bit, minimo, che puoi usare.
Infine, soluzione ottima, con la maggior parte dei viewer, se aggiungi in
coda al file dati "garbage" questi sono bellamente ignorati. Ti basta, di
conseguenza, aggiungere 32 byte - o un padding sufficiente perche' i file
abbiano uguale lunghezza, naturalmente li' puoi giocare di compressione a
livello di codec ed e' meglio - e ricalcolarti l'MD5, incrementalmente, a
partire dallo stato inizializzato da tutto il file prima. Questo accelera
molto le operazioni (che rimangono nel range dei millenni, IMHO).


 operazioni (che rimangono nel range dei millenni, IMHO).
E cosa sono in confronto all'eternità?
Tu hai fretta?


Tu hai fretta?
Per nulla :-)


 E c'hai ragione, c'hai...
tra l'altro "credo" che stiano migrando tutto il coso... il cluster
su un'architettura "tesla" (o, da altre voci, "fermi") [1]; I costi
probabilmente non saranno gli stessi però in compenso non
avranno problemi relativamente alla compatibilità <g>
[1] 
http://www.tyan.com/solutions/gpu_certified_tesla_platforms.aspx
 
http://en.wikipedia.org/wiki/Nvidia_Tesla