Re: Umgang mit Dubletten

[Philipp Schafft <lion@xxxxxxxxx>]

reflum,

On Fri, 2009-08-21 at 08:49 +0200, Thomas Gross wrote:
> On Fri, 2009-08-21 at 01:23 +0200, Philipp Schafft wrote:
> > reflum,
>        
> > Da Hashes nicht kollisionsfrei sind muss hier fuer eine hohe
> > kollisionsischerheit gesorgt werden. Deswegen wuerde ich dazu raten die
> > kombination zweier hashes zu nehmen die nicht auf basis der selben
> > grundlage arbeiten. Beispielsweise ein hash aus der SHA-2 Familie und
> > ein TIGER order Wirlpool. Beide dann einfach zu einem string zusammen
> > setzen. Solange die Verfahren bekannt sind ist druch die laenge das
> > spaeder wieder auseinander teilbar, oder im zweifel ein '-' oder
> > aehnliches trennzeichen benutzen.
> Das halte ich fuer ueberfluessig. Genau das selbe wurde auf der git
> Mailingliste diskutiert und die Wahrscheinlichkeit, dass eine SHA1
> Kollision wirklich auftritt ist so gering, dass es sich nicht lohnt
> deswegen die Implementierung zu verkomplizieren.

Die warcheinlichkeit von der man heute ausgeht. Vor ein paar jahren hat
man MD5 auch noch 128 bit zu gesprochen. Die bits kullern aber zusehbar
mitlerweile.

Bitte etwas weitsicht: was ist in 10 jahren? jemand der solch ein
dupletten system aufbaut denke ich sollte soweit locker mal schauen.


> Du schiebst die Wahrscheinlichkeit einer Kollision ja auch nur hinaus
> und verhinderst sie nicht. Falls wirklich alle Kollisionen verhindern
> willst musst du dir was anderes ausdenken. Und ein Problem, dass
> wahrscheinlich nie auftritt durch ein anderes Problem, das ein wenig
> weniger wahrscheinlich auftritt zu ersetzen scheint mir ein wenig
> sinnlos.

Eine kollision zu verhindern geht bei fix-laengen verfahren nur dann
wenn du eine kopie des orginals erzeugst.
Die Frage um die es hier geht ist nur wann es kollidiren wird. Und ob
die warcheinlichkeit das das zur laufzeit solch eines systems auftritt
ausreichent klein ist.

-- 
Philipp.
 (Rah of PH2)
--
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: http://wiki.uugrn.org/wiki/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/