Discussion:
Hashwert berechnen
(zu alt für eine Antwort)
Erich Schnoor
2003-12-10 11:22:12 UTC
Permalink
Zur Diskussion:

Es soll ein Hashwert H(k) auf neue Art berechnet werden.
Gegeben sind:

A (string) = a(1), a(2), a(3), ... a(i), ... a(n)
a = ASCII-Wert von a
n = Länge von A (in Bytes)

Formel zur Berechnung des Hashwerts:

n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1

Konstante C(k) = n * (n - 2) + 1

Beispiel:
Für den String "3 Nordlichter wandern über den großen Belt"
ergeben sich :
n = 42
Konstante C(k) = 1681
Hashwert (dezimal) H(k) = 6972281
(hexadezimal) H(k) = 6a6379

Behauptung:

Die Berechnung des Hashwertes ist eine Einweg-Funktion
und der Hashwert ist kollisionsfrei. C(k) hat die
Eigenschaft eines Grenzwertes zwischen
kollisionsbelasteten und kollisionsfreien Hashwerten.

Die Begründung wird dargelegt in:

http://www.telecypher.net/telecode.htm

Gruß
Erich Schnoor
Lutz Donnerhacke
2003-12-10 11:43:48 UTC
Permalink
Post by Erich Schnoor
Es soll ein Hashwert H(k) auf neue Art berechnet werden.
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Hashwerte sind in der Ergebnismenge beschränkt. Diese Beschränkung fehlt.
Ein einfacherer kollisionsfreier Wert in Schnoorscher Definition: H(k) = k.
Erich Schnoor
2003-12-10 14:58:59 UTC
Permalink
Post by Lutz Donnerhacke
Post by Erich Schnoor
Es soll ein Hashwert H(k) auf neue Art berechnet werden.
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Hashwerte sind in der Ergebnismenge beschränkt. Diese Beschränkung fehlt.
Ein einfacherer kollisionsfreier Wert in Schnoorscher Definition: H(k) = k.
Vielleicht sind die _Hinweise_ beschränkt, die Menge
der Hashwerte ist es jedenfalls nicht !
Oder hat der Poster seine eigenen Hashwerte?

Gruß
Erich Schnoor
Urs [Ayahuasca] Traenkner
2003-12-10 15:05:09 UTC
Permalink
Post by Erich Schnoor
Post by Lutz Donnerhacke
Hashwerte sind in der Ergebnismenge beschränkt. Diese Beschränkung fehlt.
Ein einfacherer kollisionsfreier Wert in Schnoorscher Definition: H(k) = k.
Vielleicht sind die _Hinweise_ beschränkt, die Menge
der Hashwerte ist es jedenfalls nicht !
Eben.

Sie sollten es aber sein. Die Laenge n bei einer Hashfunktion ist
fest. Sprich: es gibt eine Obergrenze fuer H(k) in Sachen Laenge.

Bei Dir gilt das nicht. Nebst anderem.

Gruss Urs...
--
Staendiges Versagen ist auch eine Form von Verlaesslichkeit.

(Verfasser unbekannt)
Erich Schnoor
2003-12-10 15:48:22 UTC
Permalink
Post by Lutz Donnerhacke
Post by Erich Schnoor
Es soll ein Hashwert H(k) auf neue Art berechnet werden.
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Hashwerte sind in der Ergebnismenge beschränkt. Diese Beschränkung fehlt.
Ein einfacherer kollisionsfreier Wert in Schnoorscher Definition: H(k) = k.
Mit einigem zeitlichen Abstand habe ich noch einmal in
Ruhe über die Stellungnahme von Lutz nachgedacht:

Die Meinung scheint mir in der typischen Donnerhack'schen
Eil-Manier zustande gekommen zu sein. Schnell etwas sagen
aber noch nicht darüber nachdenken. Denn wenn er die Formel
richtig gelesen, verstanden und nachgerechnet hätte, müsste
er für das gezeigte Beispiel auch auf

H(k) = 6972281
kommen.

Gruss
Erich Schnoor
Lutz Donnerhacke
2003-12-10 20:59:45 UTC
Permalink
Post by Erich Schnoor
Post by Lutz Donnerhacke
Hashwerte sind in der Ergebnismenge beschränkt. Diese Beschränkung fehlt.
Ein einfacherer kollisionsfreier Wert in Schnoorscher Definition: H(k) = k.
Mit einigem zeitlichen Abstand habe ich noch einmal in
Schön.
Post by Erich Schnoor
Die Meinung scheint mir in der typischen Donnerhack'schen
Eil-Manier zustande gekommen zu sein. Schnell etwas sagen
aber noch nicht darüber nachdenken. Denn wenn er die Formel
richtig gelesen, verstanden und nachgerechnet hätte, müsste
er für das gezeigte Beispiel auch auf
H(k) = 6972281
kommen.
Das Einzelergebnis ist irrelevant. Relevant ist die Unbeschränktheit des
Ergebnisraums. Relevant ist auch, daß dieser Typ Prüfsummen keine
Kollisionsresistenz aufweisen. Beispiel, was man zur Übung an Studenten
verteilt: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf
Die Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Erich Schnoor
2003-12-11 07:46:41 UTC
Permalink
Post by Lutz Donnerhacke
Das Einzelergebnis ist irrelevant. Relevant ist die Unbeschränktheit des
Ergebnisraums. Relevant ist auch, daß dieser Typ Prüfsummen keine
Kollisionsresistenz aufweisen. Beispiel, was man zur Übung an Studenten
verteilt: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf
Die Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Achtung:

Meine Formel gibt es bereits seit 1998 und seit wann gibt es Adler?

Gruss
Erich Schnoor
Michael H. Fischer
2003-12-11 09:15:12 UTC
Permalink
Post by Erich Schnoor
Meine Formel gibt es bereits seit 1998 und seit wann gibt es Adler?
Weitaus länger. Informier dich selber über die Arbeit von Ilan Adler.

MfG
Michael H. Fischer
Erich Schnoor
2003-12-11 15:30:57 UTC
Permalink
Post by Michael H. Fischer
Post by Erich Schnoor
Meine Formel gibt es bereits seit 1998 und seit wann gibt es Adler?
Weitaus länger. Informier dich selber über die Arbeit von Ilan Adler.
MfG
Michael H. Fischer
Danke

Gruss
Erich Schnoor
Lutz Donnerhacke
2003-12-11 09:20:23 UTC
Permalink
Post by Erich Schnoor
Post by Lutz Donnerhacke
Das Einzelergebnis ist irrelevant. Relevant ist die Unbeschränktheit
des Ergebnisraums. Relevant ist auch, daß dieser Typ Prüfsummen keine
Kollisionsresistenz aufweisen. Beispiel, was man zur Übung an Studenten
verteilt: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf Die
Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Meine Formel gibt es bereits seit 1998 und seit wann gibt es Adler?
Mark Adler hat diesen Algorithmus entwickelt. Dieser Algorithmus ist u.a. in
PGP eingebaut. Die PGP Historie sagt: 1991. Ich würde sicherheitshalber
aber die Verwendung von Adler32 erst an die Version 2.1 koppeln, weil da das
Mensagespräch und die völlige Zerstörung von PGP 1 dazwischen lagen. 1992
ist also eine gute Schätzung für einen nachgewiesenen Einsatz von Adler.

Das Erstveröffentlichungspaper von Mark Adler finde ich auf die Schnelle
nicht.
Michael H. Fischer
2003-12-11 09:54:23 UTC
Permalink
Post by Lutz Donnerhacke
Mark Adler hat diesen Algorithmus entwickelt.
Mark Adler? Sicher? Ich ging ehrlich davon aus, dass es sich um eine
Entwicklung von Ilian Adler handelt.

<verwirrt>

Michael
Lutz Donnerhacke
2003-12-11 10:03:02 UTC
Permalink
Post by Michael H. Fischer
Post by Lutz Donnerhacke
Mark Adler hat diesen Algorithmus entwickelt.
Mark Adler? Sicher?
Nein.
Post by Michael H. Fischer
Ich ging ehrlich davon aus, dass es sich um eine
Entwicklung von Ilian Adler handelt.
Danke für die Aufklärung.
Erich Schnoor
2003-12-11 15:33:38 UTC
Permalink
Post by Lutz Donnerhacke
Post by Erich Schnoor
Post by Lutz Donnerhacke
Das Einzelergebnis ist irrelevant. Relevant ist die Unbeschränktheit
des Ergebnisraums. Relevant ist auch, daß dieser Typ Prüfsummen keine
Kollisionsresistenz aufweisen. Beispiel, was man zur Übung an Studenten
verteilt: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf Die
Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Meine Formel gibt es bereits seit 1998 und seit wann gibt es Adler?
Mark Adler hat diesen Algorithmus entwickelt. Dieser Algorithmus ist u.a. in
PGP eingebaut. Die PGP Historie sagt: 1991. Ich würde sicherheitshalber
aber die Verwendung von Adler32 erst an die Version 2.1 koppeln, weil da das
Mensagespräch und die völlige Zerstörung von PGP 1 dazwischen lagen. 1992
ist also eine gute Schätzung für einen nachgewiesenen Einsatz von Adler.
Das Erstveröffentlichungspaper von Mark Adler finde ich auf die Schnelle
nicht.
Danke

für diesen sachlichen und informativen Beitrag.
Ich werde das Papier schon finden.

Gruss
Erich Schnoor
Erich Schnoor
2003-12-11 08:43:25 UTC
Permalink
.........: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf
Die Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Offensichtlich nur, weil in beiden Formeln das Summenzeichen steht.
Dass in meiner Formel eine positionsgewichtung der einzelnen Zeichen
und kein _modulo_ 256 stattfindet, zählt wohl nicht?

Gruss
Erich Schnoor
Lutz Donnerhacke
2003-12-11 09:04:28 UTC
Permalink
Post by Erich Schnoor
.........: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf
Die Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Offensichtlich nur, weil in beiden Formeln das Summenzeichen steht.
Nein. Den Unterschied zwischen Reihenschritt und Reihensumme erkläre ich
jetzt wirklich nicht.
Post by Erich Schnoor
Dass in meiner Formel eine positionsgewichtung der einzelnen Zeichen
und kein _modulo_ 256 stattfindet, zählt wohl nicht?
Die Positionsgewichtung erfolgt bei Adler genauso in der Summenformel.
Rechnungen in einem Ideal oder einem unendlichen Körper sind für Addition und
Multiplikation identisch.
Erich Schnoor
2003-12-11 17:06:07 UTC
Permalink
Post by Lutz Donnerhacke
Post by Erich Schnoor
.........: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf
Die Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Offensichtlich nur, weil in beiden Formeln das Summenzeichen steht.
Nein. Den Unterschied zwischen Reihenschritt und Reihensumme erkläre ich
jetzt wirklich nicht.
Post by Erich Schnoor
Dass in meiner Formel eine positionsgewichtung der einzelnen Zeichen
und kein _modulo_ 256 stattfindet, zählt wohl nicht?
Die Positionsgewichtung erfolgt bei Adler genauso in der Summenformel.
Rechnungen in einem Ideal oder einem unendlichen Körper sind für Addition und
Multiplikation identisch.
Hi Lutz,

wenn ich Ihre Anweisungen in .../fh/uebung5.pdf richtig verstanden
habe, ist die Prüfsummenrechnung doch wohl sehr einfach:

ADLER16:

INPUT Bytefolge = Folge$

low# = 0
high# = 0

FOR I = 1 TO LEN(Folge$)
byte# = ASC(MID$(Folge$,I,1))
low# = low# + byte#
high# = high# + low#
NEXT I

PruefSumme# = high# * low#

OUTPUT PruefSumme#

Für die Bytefolge: "Dieses Hashverfahren ist grober Unfug"
Zitat: Hendrik Weimer

ergibt der obige Ablauf die Prüfsumme: 242080896

Mit dem hier angegriffenen Hashverfahren erhalten wir:

H(k) = 4751343
Basis 16 = 487fef
Basis 64 = I7#k

Eines möchte ich allerdings noch gerne wissen: Wird in der
ADLER16 Rechnung die Positionsgewichtung durch die Multiplication
am Ende erreicht oder wie sonst?

Gruss
Erich Schnoor
Lutz Donnerhacke
2003-12-11 17:13:56 UTC
Permalink
Post by Erich Schnoor
wenn ich Ihre Anweisungen in .../fh/uebung5.pdf richtig verstanden
INPUT Bytefolge = Folge$
low# = 0
high# = 0
FOR I = 1 TO LEN(Folge$)
byte# = ASC(MID$(Folge$,I,1))
low# = low# + byte#
high# = high# + low#
NEXT I
PruefSumme# = high# * low#
OUTPUT PruefSumme#
Richtig.
Post by Erich Schnoor
Für die Bytefolge: "Dieses Hashverfahren ist grober Unfug"
Zitat: Hendrik Weimer
ergibt der obige Ablauf die Prüfsumme: 242080896
Nein. Der Überschlag bei 256 fehlt.
Post by Erich Schnoor
H(k) = 4751343
Basis 16 = 487fef
Basis 64 = I7#k
Dann ist dieses Verfahren falsch beschrieben. Die Integer, die im Programm
benutzt werden haben einen Überschlag bei 65536. Nach Beschreibung dürfen
sie gar keinen Überschlag haben.
Post by Erich Schnoor
Eines möchte ich allerdings noch gerne wissen: Wird in der
ADLER16 Rechnung die Positionsgewichtung durch die Multiplication
am Ende erreicht oder wie sonst?
Ja, die Positionsgewichtung ist im Output drin.
Erich Schnoor
2003-12-12 08:44:06 UTC
Permalink
Post by Lutz Donnerhacke
Post by Erich Schnoor
wenn ich Ihre Anweisungen in .../fh/uebung5.pdf richtig verstanden
INPUT Bytefolge = Folge$
low# = 0
high# = 0
FOR I = 1 TO LEN(Folge$)
byte# = ASC(MID$(Folge$,I,1))
low# = low# + byte#
high# = high# + low#
NEXT I
PruefSumme# = high# * low#
OUTPUT PruefSumme#
Richtig.
Post by Erich Schnoor
Für die Bytefolge: "Dieses Hashverfahren ist grober Unfug"
Zitat: Hendrik Weimer
ergibt der obige Ablauf die Prüfsumme: 242080896
Nein. Der Überschlag bei 256 fehlt.
Das stimmt, aber modulo 256 kann ohne weiteres in die Funktion
eingestellt werden
Post by Lutz Donnerhacke
Post by Erich Schnoor
H(k) = 4751343
Basis 16 = 487fef
Basis 64 = I7#k
Dann ist dieses Verfahren falsch beschrieben. Die Integer, die im Programm
benutzt werden haben einen Überschlag bei 65536. Nach Beschreibung dürfen
sie gar keinen Überschlag haben.
In der praktischen Ausführung des Programms werden Quad-Integer (64 Bit)
benutzt. Bei 2^16 ist also keine Grenze.
Post by Lutz Donnerhacke
Post by Erich Schnoor
Eines möchte ich allerdings noch gerne wissen: Wird in der
ADLER16 Rechnung die Positionsgewichtung durch die Multiplication
am Ende erreicht oder wie sonst?
Ja, die Positionsgewichtung ist im Output drin.
Das verstehe ich nicht. Unter Positionsgewichtung verstehe ich, dass die
Position (i) - numerisch - in die Wertberechnung eingeht. In der obigen
Funktion ist das aber nicht der Fall.

Gruss
Erich Schnoor
Urs [Ayahuasca] Traenkner
2003-12-12 09:36:44 UTC
Permalink
Post by Erich Schnoor
In der praktischen Ausführung des Programms werden Quad-Integer (64 Bit)
benutzt.
Leuchten blau und machen vierfachen Schaden?

Sieh Dich bei der Implementation von rocketlauncher.c bitte vor.

Gruss Urs...
--
_______
(-) o---|_______|---o (+)
| |
+---------------+ Widerstand ist zwecklos!
Lutz Donnerhacke
2003-12-12 09:31:04 UTC
Permalink
Post by Erich Schnoor
In der praktischen Ausführung des Programms werden Quad-Integer (64 Bit)
benutzt. Bei 2^16 ist also keine Grenze.
Dann ist sie bei 2^64 und die ist in Ihrer Formel schneller erreicht als Sie
glauben. Ihre Implemenation Ihres eigenen Algorithmus ist fehlerhaft.

(Übrigens ist der Überschlag bei 2^64 ausreichend für die Beschränktheit.
Es muß nur dokumentiert werden.)
Post by Erich Schnoor
Post by Lutz Donnerhacke
Eines möchte ich allerdings noch gerne wissen: Wird in der ADLER16
Rechnung die Positionsgewichtung durch die Multiplication am Ende
erreicht oder wie sonst?
Ja, die Positionsgewichtung ist im Output drin.
Das verstehe ich nicht. Unter Positionsgewichtung verstehe ich, dass die
Position (i) - numerisch - in die Wertberechnung eingeht. In der obigen
Funktion ist das aber nicht der Fall.
Doch. Die Summenformel für high enthält die Position.
Erich Schnoor
2003-12-11 09:36:54 UTC
Permalink
.................... Beispiel, was man zur Übung an Studenten
verteilt: ftp://ftp.iks-jena.de/pub/mitarb/lutz/fh/uebung5.pdf
Die Summenformel von Adler sieht genauso aus wie Ihre, Herr Schnoor.
Aber die Ergebnisse sind völlig verschieden:

Wenn der Lutz mich denn schon zum Fachschüler degradiert,
dann will ich auch wenigsten seine Aufgaben rechnen:

Aus der zitierten .../fh/uebung5.pdf:

a) leere Eingabe
(hier String ASCC-(00) mit 14 Bytes)

n = 14, C(k) = 0, H(k) = 105
Basis 16 = 69
Basis 64 = 1e

b) String = "0123456789"

n = 10, C(k) = 81, H(k) = 46369
Basis 16 = b521
Basis 64 = BHX

c) String = "Fachhochschule"

n = 14, C(k) = 169, H(k) = 255558
Basis 16 = 3e646
Basis 64 = zP7

d) String = "FachHochSchule"

n = 14, C(k) = 169, H(k) = 244294
Basis 16 = 3ba46
Basis 64 = we6

Der Hashwert kann auch in allen anderen Zahlensystemen
von zur Basis 2 bis zur Basis 128 ausgedrückt werden.
Wer Lust hat kann ja Kollisionen suchenoder einen anderen
String, der den selben Hashwert H(k) ergibt.

Gruss
Erich Schnoor
Lutz Donnerhacke
2003-12-11 09:44:23 UTC
Permalink
Post by Erich Schnoor
Wer Lust hat kann ja Kollisionen suchenoder einen anderen
String, der den selben Hashwert H(k) ergibt.
Die Postings, die das getan haben, liegen seit gestern hier vor.
Sie haben sogar darauf geantwortet. *Kopfschüttel*
Urs [Ayahuasca] Traenkner
2003-12-10 12:05:01 UTC
Permalink
Post by Erich Schnoor
Es soll ein Hashwert H(k) auf neue Art berechnet werden.
Was ist denn an den alten (MD5, SHA1) kaputt?
Post by Erich Schnoor
A (string) = a(1), a(2), a(3), ... a(i), ... a(n)
a = ASCII-Wert von a
n = Länge von A (in Bytes)
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Die Berechnung des Hashwertes ist eine Einweg-Funktion
und der Hashwert ist kollisionsfrei. C(k) hat die
Eigenschaft eines Grenzwertes zwischen
kollisionsbelasteten und kollisionsfreien Hashwerten.
Genau da liegt m.E. das Problem. Vom Draufgucken wuerde ich
sagen, es gibt fuer einen Hashwert H(k) zuviele k, die denselben
Hashwerk ergeben. Beziehungsweise sind die zu trivial zu finden.

Abgesehen davon glaube ich mich daran erinnern zu koennen, dass
aehnliche Eingaben zu voellig unterschiedlichen Hashwerten
fuehren sollten. Bei Dir ist das zu linear.

Gruss Urs...
--
Staendiges Versagen ist auch eine Form von Verlaesslichkeit.

(Verfasser unbekannt)
Andreas Beck
2003-12-10 12:21:46 UTC
Permalink
Post by Erich Schnoor
Es soll ein Hashwert H(k) auf neue Art berechnet werden.
A (string) = a(1), a(2), a(3), ... a(i), ... a(n)
a = ASCII-Wert von a
n = Länge von A (in Bytes)
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Die Berechnung des Hashwertes ist eine Einweg-Funktion
und der Hashwert ist kollisionsfrei.
Nein. Proof by example:

n=2, Strings \x05\x03 und \x08\x01.

Denn aus n=2 folgt C(k) = 2*0+1 = 1

Damit ist H(\x05\x03) = (5+1)*2+(3+1)*3 = 12+12 = 24 und
H(\x08\x01) = (8+1)*2+(1+1)*3 = 18+ 6 = 24 qed

Kollision in 30 Sekunden mit Papier und Bleistift konstruiert. Davon 25
Sekunden, um durch die Logik mit dem C(k) zu steigen.


Desweiteren liefert die Funktion für n=1 permanent 0.

Von der fehlenden oberen Begrenzung gar nicht zu reden ...

Wie wäre es, wenn Du Dich mit etwas beschäftigst, wovon Du etwas
verstehst?

Wenn ich mich Null Ahnung von Cryptoanalyse sofort sehen kann, daß die
Funktion Müll ist, sollte das Bände sprechen.


CU, Andy
Andreas Beck
2003-12-11 17:14:53 UTC
Permalink
Post by Andreas Beck
Post by Erich Schnoor
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Die Berechnung des Hashwertes ist eine Einweg-Funktion
und der Hashwert ist kollisionsfrei.
n=2, Strings \x05\x03 und \x08\x01.
Da Du so auf ASCII rumreitest und Beispiele mit Sonderzeichen nicht
gelten lassen willst, hier ein banales Beispiel mit pure ASCII:

n=2, Strings "AC" und "DA"

Proof:

Aus n=2 folgt C(k) = 2*0+1 = 1
Damit ist H("AC") = (65+1)*2+(67+1)*3 = 66*2+68*3 = 336 und
H("DA") = (68+1)*2+(65+1)*3 = 69*2+66*3 = 336 qed

Kollision ebenfalls in wenigen Sekunden herbeigeführt.


Das sieht man trivial, wenn man sich anguckt, daß bei n=2 die Formel
einschrumpft auf:

(a1+1)*2+(a2+1)*3

Es lassen sich beliebig viele Pärchen a1,a2 finden, die einen bestimmten
Wert ergeben. Durch den eingeschränkten Wertebereich geht es dann nicht
mehr mit in allen Fällen, aber eine Kollision ist trivial
herbeizuführen.

Aufgrund der inhärenten Linearität kann man sogar sofort sagen, daß für
_jeden_ String der Form a2=a1+2 auch der String a'1=a1+3,
a'2=a1 den gleichen Hash hat. Proof:

Wegen a2=a1+2 wird H(k) zu (a1+1)*2+(a1+2+1)*3=2*a1+2+3*a1+9=5*a1+11;

Analog ist wegen a'1=a1+3 und a'2=a1 der H(k'):
(a1+3+1)*2+(a1+1)*3 = 2*a1+8 + 3*a1 + 3 = 5*a1+11


Das ist eine völlig banale Attacke. Und sie geht nicht nur für die
beschriebenen Pärchen. Für den Leser zur Übung: Zeige, daß die Attacke
für beliebige gerade delta_a (also a2=a1+delta_a) funktioniert.

Für den immer noch interessierten Leser: Zeige, daß die Attacke auch für
größere n anwendbar bleibt.


Wer jetzt immer noch nicht gelangweilt ist:

Außerdem leakt der "Hash" Plaintext. z.B. für n=2 das unterste Bit von
a2 sofort. Ebenso für n=3. Wie bekommt man dieses Bit?



CU, Andy
Bastian Blank
2003-12-11 18:31:03 UTC
Permalink
Post by Andreas Beck
Außerdem leakt der "Hash" Plaintext. z.B. für n=2 das unterste Bit von
a2 sofort. Ebenso für n=3. Wie bekommt man dieses Bit?
| (a1+1)*2+(a2+1)*3

b=(a1+1)*2: I(b,0)=0 (also das unterste bit)
c=(a2+1)*3: I(c,0)=1+I(a2,0)

bastian
Erich Schnoor
2003-12-12 09:53:10 UTC
Permalink
Post by Bastian Blank
Post by Andreas Beck
Außerdem leakt der "Hash" Plaintext. z.B. für n=2 das unterste Bit von
a2 sofort. Ebenso für n=3. Wie bekommt man dieses Bit?
| (a1+1)*2+(a2+1)*3
b=(a1+1)*2: I(b,0)=0 (also das unterste bit)
c=(a2+1)*3: I(c,0)=1+I(a2,0)
bastian
Hi Bastian,

dass die Wahrscheinlichkeit von Kollisionen im bereich kurzer Längen
und dementsprechend niedriger Konstanten hyperbolisch zunimmt, geht
auch schon aus der Kurve (graphische Darstellung) hervor in Abschnitt
B 1 des Arikels:
http://www.telecypher.net/telecode.htm

Gruss
Erich Schnoor
Andreas Beck
2003-12-12 13:12:10 UTC
Permalink
Einleitungsroman kürzen. MIDs stehen schon im References:-Header.
Post by Erich Schnoor
Post by Bastian Blank
Post by Andreas Beck
Außerdem leakt der "Hash" Plaintext. z.B. für n=2 das unterste Bit von
a2 sofort. Ebenso für n=3. Wie bekommt man dieses Bit?
| (a1+1)*2+(a2+1)*3
b=(a1+1)*2: I(b,0)=0 (also das unterste bit)
c=(a2+1)*3: I(c,0)=1+I(a2,0)
dass die Wahrscheinlichkeit von Kollisionen im bereich kurzer Längen
und dementsprechend niedriger Konstanten hyperbolisch zunimmt, geht
auch schon aus der Kurve (graphische Darstellung) hervor
Du weißt nichtmal, wovon er spricht - right?

Er hat meine Übungsaufgabe angenommen und - soweit ich die Notation
raffe - richtig gelöst.

Und bei der ging es nicht um Kollisionen, sondern um Plaintext-Leaking.


Kurzfassung der bisherigen Kurzanalysen hier:

Tu das Ding in die Tonne und verwende entweder was bekanntes, oder fang
neu an. Aber lies vorher den Schneier nochmal. Vielleicht zur
Abwechslung sogar sinnentnehmend.


CU, ANdy
Philipp Neuhaus
2003-12-10 15:14:00 UTC
Permalink
Wenn ich das richtig verstanden habe, wächst der Hash mit der Länge
des Textes.

Das ist ein Angriffspunkt.
So kann ich schon einmal die Länge des Textes abschätzen, wenn ich den
Hash habe.
Gar nicht gut.

Philipp
Hendrik Weimer
2003-12-10 16:03:45 UTC
Permalink
Post by Erich Schnoor
Für den String "3 Nordlichter wandern über den großen Belt"
n = 42
Konstante C(k) = 1681
Hashwert (dezimal) H(k) = 6972281
(hexadezimal) H(k) = 6a6379
Anderes Beispiel:

"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"

n = 44, C(k) = 1849, H(k) = 6972281

Hendrik
Erich Schnoor
2003-12-11 07:02:42 UTC
Permalink
Post by Hendrik Weimer
Post by Erich Schnoor
Für den String "3 Nordlichter wandern über den großen Belt"
n = 42
Konstante C(k) = 1681
Hashwert (dezimal) H(k) = 6972281
(hexadezimal) H(k) = 6a6379
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
n = 44, C(k) = 1849, H(k) = 6972281
Hendrik
Hallo Hendrik,

entweder du kannst nicht zählen oder nicht rechnen!

Dein Beispiel - auch wenn es grober Unfug ist - hat
immerhin 59 Bytes !

n = 59, c(k) = 3364, H(k) = 16703308
Basis 16 = ffdf4c
Basis 64 = #iyC

Gruss
Erich Schnoor
Patrick Schaaf
2003-12-11 07:25:48 UTC
Permalink
Post by Erich Schnoor
Post by Hendrik Weimer
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
entweder du kannst nicht zählen oder nicht rechnen!
Dein Beispiel - auch wenn es grober Unfug ist - hat
immerhin 59 Bytes !
Das Beispiel hat genau 44 Byte zwischen den Anfuehrungsstrichen.
Fuenf davon haben den Wert 0, die letzten 3, sowie die 2 zwischen
dem Unfug und G(. Du kannst entweder nicht lesen, oder kein C.

Gruss
Patrick
--
wem hatte ich nochmal meine Popcornmaschine verliehen?
Erich Schnoor
2003-12-11 10:45:37 UTC
Permalink
Post by Patrick Schaaf
Post by Erich Schnoor
Post by Hendrik Weimer
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
entweder du kannst nicht zählen oder nicht rechnen!
Dein Beispiel - auch wenn es grober Unfug ist - hat
immerhin 59 Bytes !
Das Beispiel hat genau 44 Byte zwischen den Anfuehrungsstrichen.
Fuenf davon haben den Wert 0, die letzten 3, sowie die 2 zwischen
dem Unfug und G(. Du kannst entweder nicht lesen, oder kein C.
Gruss
Patrick
Hallo Patrick,

Ich lese einen String immer noch wie er geschrieben wird, d.h.
alles was zwischen den Begrenzungszeichen " " steht. Und dazu
hehören nun auch einmal die Werte 0, \, G und (. Das ist ja
gerade der Vorteil für die Hashwertberechnung von Dateien.

In der Formel werden ASCII-Werte verarbeitet! Bitte die Formel
genau lesen und nicht etwas hinein interpretieren, was überhaupt
nicht relevant ist.

Gruss
Erich Schnoor
Patrick Schaaf
2003-12-11 11:12:34 UTC
Permalink
Post by Erich Schnoor
Post by Patrick Schaaf
Post by Erich Schnoor
Post by Hendrik Weimer
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
entweder du kannst nicht zählen oder nicht rechnen!
Dein Beispiel - auch wenn es grober Unfug ist - hat
immerhin 59 Bytes !
Das Beispiel hat genau 44 Byte zwischen den Anfuehrungsstrichen.
Fuenf davon haben den Wert 0, die letzten 3, sowie die 2 zwischen
dem Unfug und G(. Du kannst entweder nicht lesen, oder kein C.
Ich lese einen String immer noch wie er geschrieben wird,
Du willst also vorsaetzlich missverstehen, obwohl man Dich auf
das Missverstehen ausdruecklich hingewiesen hat. Wie trollig.

EOT
Patrick
Erich Schnoor
2003-12-13 10:23:07 UTC
Permalink
Post by Patrick Schaaf
Post by Erich Schnoor
Post by Patrick Schaaf
Post by Erich Schnoor
Post by Hendrik Weimer
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
entweder du kannst nicht zählen oder nicht rechnen!
Dein Beispiel - auch wenn es grober Unfug ist - hat
immerhin 59 Bytes !
Das Beispiel hat genau 44 Byte zwischen den Anfuehrungsstrichen.
Fuenf davon haben den Wert 0, die letzten 3, sowie die 2 zwischen
dem Unfug und G(. Du kannst entweder nicht lesen, oder kein C.
Ich lese einen String immer noch wie er geschrieben wird,
Du willst also vorsaetzlich missverstehen, obwohl man Dich auf
das Missverstehen ausdruecklich hingewiesen hat. Wie trollig.
EOT
Patrick
Noch jemand, der als Tallyman in den Hafen gehen könnte?
(Hinweis auf Antwort zum Beitrag 30)

Gruss
Erich Schnoor
Bodo Eggert
2003-12-14 04:17:01 UTC
Permalink
Post by Erich Schnoor
Noch jemand, der als Tallyman in den Hafen gehen könnte?
(Hinweis auf Antwort zum Beitrag 30)
Habt ihr dort gerade einen Personalengpaß? Wie wäre es, wenn Du, statt den
Papageien zu spielen, ein paar Überstunden schieben würdest? Von dem Geld
kannst Du Dir ein Buch über Logik für Anfänger kaufen. Falls Du dann immer
noch zu viel Zeit hast, dann solltest Du Dir ein Programm schreiben, mit
dem man die Türme von Hanoi spielen kann, und einen 32-stufigen Turm
durchspielen (oder einfach ausrechnen, wie lange Du bei 1 Zug/Sekunde
bräuchtest. Du würdest Deine Zeit sinnvoll verbringen.
--
Top 100 things you don't want the sysadmin to say:
4. This won't affect what you're doing.

Friß, Spammer: ***@coolbuyszone.com ***@cari.net.my
Philipp Neuhaus
2003-12-11 11:18:00 UTC
Permalink
Post by Erich Schnoor
In der Formel werden ASCII-Werte verarbeitet! Bitte die Formel
genau lesen und nicht etwas hinein interpretieren, was überhaupt
nicht relevant ist.
Dann ist die Funktion uninteressant.
Wenn ich damit eh nur ASCII-Dateien erfassen kann, brauch ich diese
Hashfunktion nicht.

Philipp
Erich Schnoor
2003-12-11 15:48:20 UTC
Permalink
Post by Philipp Neuhaus
Post by Erich Schnoor
In der Formel werden ASCII-Werte verarbeitet! Bitte die Formel
genau lesen und nicht etwas hinein interpretieren, was überhaupt
nicht relevant ist.
Dann ist die Funktion uninteressant.
Wenn ich damit eh nur ASCII-Dateien erfassen kann, brauch ich diese
Hashfunktion nicht.
Philipp
Hallo Philipp,
man kann damit nicht nur ASCII-Dateien erfassen sondern _alle_ digitalen
Dateien (Text-, Binaer-, Programmdateien u.a.). Probiere es doch selbst
einmal aus: DOWNLOAD CyphHash.exe (167 KB) oder HashTest.exe von

http://www.telecypher.net/telecode.htm

Gruss
Erich Schnoor
Erich Schnoor
2003-12-11 16:10:34 UTC
Permalink
Post by Philipp Neuhaus
Post by Erich Schnoor
In der Formel werden ASCII-Werte verarbeitet! Bitte die Formel
genau lesen und nicht etwas hinein interpretieren, was überhaupt
nicht relevant ist.
Dann ist die Funktion uninteressant.
Wenn ich damit eh nur ASCII-Dateien erfassen kann, brauch ich diese
Hashfunktion nicht.
Philipp
Hi, Philipp,
noch eine zusätzliche Antwort:

Die in der selbstentpackenden DOWNLOAD Datei _CyphHash_ enthaltene
Programm-Datei: Hashwert.exe beispielsweise hat folgenden Hashwert:

Hashwert Basis 10: 63145534334
Basis 16: eb3c4637e
Basis 64: vom6Dz

Ich verwende diese Hashfunktion um die Integrität von verschlüsselten
Dateien zu prüfen. Der Hashwert wird bei der Verschlüsselung am Ende
angehängt (verschlüssslet)und bei der Entschlüsselung anhand des erhaltenen
Klartextes abgestimmt. Nur bei Übereinstimmung erfolgt die Freigabe.

Gruss
Erich Schnoor
Lutz Donnerhacke
2003-12-11 16:47:02 UTC
Permalink
Post by Erich Schnoor
Ich verwende diese Hashfunktion um die Integrität von verschlüsselten
Dateien zu prüfen.
Dazu ist diese Prüfsumme geeignet, wenn sie auch über alle Schranken steigt.
Post by Erich Schnoor
Der Hashwert wird bei der Verschlüsselung am Ende angehängt
(verschlüssslet)und bei der Entschlüsselung anhand des erhaltenen
Klartextes abgestimmt. Nur bei Übereinstimmung erfolgt die Freigabe.
Dazu ist diese Prüfsumme nicht geeignet. Sie schützt nur vor zufälligen
Änderungen, nicht vor Absichtlichen.
Eike Sauer
2003-12-11 13:35:50 UTC
Permalink
Post by Erich Schnoor
Ich lese einen String immer noch wie er geschrieben wird, d.h.
alles was zwischen den Begrenzungszeichen " " steht. Und dazu
hehören nun auch einmal die Werte 0, \, G und (. Das ist ja
gerade der Vorteil für die Hashwertberechnung von Dateien.
Dann hier in ASCII-Dezimalzahlen:

68 105 101 115 101 115 32 72 97 115
104 118 101 114 102 97 104 114 101 110
32 105 115 116 32 103 114 111 98 101
114 32 85 110 102 117 103 0 0 71
40 0 0 0

War das so schwer?

Ciao,
Eike
Erich Schnoor
2003-12-12 08:10:55 UTC
Permalink
Post by Eike Sauer
Post by Erich Schnoor
Ich lese einen String immer noch wie er geschrieben wird, d.h.
alles was zwischen den Begrenzungszeichen " " steht. Und dazu
hehören nun auch einmal die Werte 0, \, G und (. Das ist ja
gerade der Vorteil für die Hashwertberechnung von Dateien.
68 105 101 115 101 115 32 72 97 115
104 118 101 114 102 97 104 114 101 110
32 105 115 116 32 103 114 111 98 101
114 32 85 110 102 117 103 0 0 71
40 0 0 0
War das so schwer?
Ciao,
Eike
Hi Eike,

wenn man in "C" liest, sicherlich nicht. Aber bei mir lauten die
ASCII-Dezimalzahlen wie folgt:

U n f u g \ 0 0 0 \ 0 ........
......... 85 110 102 117 103 92 48 48 48 92 48

Die Formel für H(k) ist doch reine Mathematik, von "C" weit und breit
keine Spur. Und zum Rechnen werden die Werte für digitale Daten
nun mal von ihrer Darstellung - zum Beispiel auch im ASCII-Wertesystem -
abgeleitet. Sie können aber auch von der binären Darstellung genommen
werden:

.... g \ 0 0 ....
.... 01100111 01011100 00110000 00110000 ....
.... 103 92 48 48 ....

Im Ergebnis bleibt es gleich

Also, nichts ist mit n = 44, sondern n = 59, zumindest beim Rechnen mit
der Formel.

Gruss
Erich Schnoor








Aber wer redet denn von "C" ?

Die hier strittige Formel ist reine Mathematik, wobei
Bodo Eggert
2003-12-12 11:29:07 UTC
Permalink
Post by Erich Schnoor
.... g \ 0 0 ....
.... 01100111 01011100 00110000 00110000 ....
.... 103 92 48 48 ....
Im Ergebnis bleibt es gleich
Also, nichts ist mit n = 44, sondern n = 59, zumindest beim Rechnen mit
der Formel.
Durch bewußtes Falscghinterpretieren von Gegenbeispielen wird kein
Algorhithmus sicher.
--
Top 100 things you don't want the sysadmin to say:
92. What software license?

Friß, Spammer: ***@info.cnri.reston.va.us
Eike Sauer
2003-12-12 11:49:37 UTC
Permalink
Post by Erich Schnoor
Also, nichts ist mit n = 44, sondern n = 59, zumindest beim Rechnen mit
der Formel.
Ich hab dir alle 44 aufgezählt.
Nimm die.

Ciao,
Eike
Erich Schnoor
2003-12-12 17:56:16 UTC
Permalink
Post by Eike Sauer
Post by Erich Schnoor
Also, nichts ist mit n = 44, sondern n = 59, zumindest beim Rechnen mit
der Formel.
Ich hab dir alle 44 aufgezählt.
Nimm die.
Ciao,
Eike
Hi Eike,

dann arbeit mein Programm nicht !
Probier es doch einmal selbst aus

Gruss
Erich Schnoor
Sebastian Biallas
2003-12-12 19:44:30 UTC
Permalink
Post by Erich Schnoor
Post by Eike Sauer
Post by Erich Schnoor
Also, nichts ist mit n = 44, sondern n = 59, zumindest beim Rechnen mit
der Formel.
Ich hab dir alle 44 aufgezählt.
Nimm die.
Hi Eike,
dann arbeit mein Programm nicht !
Probier es doch einmal selbst aus
Entweder Du willst es absichtlich nicht verstehen, oder Du störst Dich
irgendwie an der C-Darstellung des Strings.

Hier nochmal der Originalstring:

"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"

in Pascal würde man dies so schreiben:

"Dieses Hashverfahren ist grober Unfug" + chr(0) + chr(0) + "G(" +
chr(0) + chr(0) + chr(0)

in BASIC:

"Dieses Hashverfahren ist grober Unfug" + chr$(0) + chr$(0) + "G(" +
chr$(0) + chr$(0) + chr$(0)

Das ganze interpretierst Du dann als Octet-Stream mit den ASCII-Werten
der Zeichen, dann ist n=44 und es ergibt die angebenen Hashwerte.
Post by Erich Schnoor
Gruss
Erich Schnoor
Gruß,
Sebastian
Erich Schnoor
2003-12-13 10:51:02 UTC
Permalink
Post by Sebastian Biallas
Post by Erich Schnoor
Post by Eike Sauer
Post by Erich Schnoor
Also, nichts ist mit n = 44, sondern n = 59, zumindest beim Rechnen mit
der Formel.
Ich hab dir alle 44 aufgezählt.
Nimm die.
Hi Eike,
dann arbeit mein Programm nicht !
Probier es doch einmal selbst aus
Entweder Du willst es absichtlich nicht verstehen, oder Du störst Dich
irgendwie an der C-Darstellung des Strings.
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
"Dieses Hashverfahren ist grober Unfug" + chr(0) + chr(0) + "G(" +
chr(0) + chr(0) + chr(0)
"Dieses Hashverfahren ist grober Unfug" + chr$(0) + chr$(0) + "G(" +
chr$(0) + chr$(0) + chr$(0)
Das ganze interpretierst Du dann als Octet-Stream mit den ASCII-Werten
der Zeichen, dann ist n=44 und es ergibt die angebenen Hashwerte.
Post by Erich Schnoor
Gruss
Erich Schnoor
Gruß,
Sebastian
Zum Beispiel mit dem "Unfug" von Hendrik Weimer (Beitrag 30 oben):

Es werden von Sebastian wieder in den zitierten Programmiersprachen
digitale Daten

..... g \ 0 ....
..... 01100111 01011100 00110000 ....

mit ungeeigneten _Programmierelementen_ verwechselt. Die gezeigten Daten
haben nicht den Wert 0 !!!

Es scheint immer noch nicht der Unterschied zwischen einem "Werkzeug" -
sprich Programmierspreche "C", Pascal oder BASIC - und der realen
Berechnung des Wertes einer digitalen Datenfolge klar zu sein.

Die Programmiersprache ist nur ein Mittel zur Berechnung des Wertes und
nicht Gegenstand der Berechnung. Und wenn in einer digitalen Datenfolge
die Zeichen "\000\000G(\000\000\000" stehen sind sie _Gegenstand_
der Berechnung mit ihren digitalen Werten (01100111, 01011100, 00110000)
und nicht _Programmierelement_.

Will den tatsächlich noch jemand als Tallyman in den Hafen gehen und
Container zählen? Dann wird er merken, dass er auch die leeren Container
mit zählen muss.

Gruss
Erich Schnoor
Hendrik Weimer
2003-12-13 11:33:29 UTC
Permalink
Post by Erich Schnoor
Es scheint immer noch nicht der Unterschied zwischen einem "Werkzeug" -
sprich Programmierspreche "C", Pascal oder BASIC - und der realen
Berechnung des Wertes einer digitalen Datenfolge klar zu sein.
Wie stellst Du denn in der realen Berechnung dar?

Hendrik
Eike Sauer
2003-12-13 11:31:51 UTC
Permalink
Post by Erich Schnoor
Will den tatsächlich noch jemand als Tallyman in den Hafen gehen und
Container zählen? Dann wird er merken, dass er auch die leeren Container
mit zählen muss.
Du weichst aus.

Wenn ich dich richtig verstehe, gibt es Einschränkungen für
den Wertebereich, den du für deine Formel zulassen willst.
Also: Für welche der ASCII-Werte zwischen 0 und 255 darf/soll
deine Formel verwendet werden?
Für welche Form von Daten könnte er dennoch deiner Meinung
nach noch nützlich sein?

Ciao,
Eike
Markus Schaaf
2003-12-13 17:14:39 UTC
Permalink
Post by Eike Sauer
Also: Für welche der ASCII-Werte zwischen 0 und 255 darf/soll
deine Formel verwendet werden?
Der ASCII hat genau 128 Zeichen. Ich würde diesen Begriff übrigens
nicht weiter benutzen. Erich Schnoor verwendet ihn nur, weil er den
Unterschied zwischen Zahlen und Zeichen nicht versteht. Sonst würde
er seine Rechenergebnisse auch nicht in verschiedenen Zahlensystemen
angeben. Er ist offensichtlich der Ansicht, daß würde irgendeinen
Unterschied machen.
Sebastian Biallas
2003-12-13 16:22:16 UTC
Permalink
Post by Erich Schnoor
Es werden von Sebastian wieder in den zitierten Programmiersprachen
digitale Daten
..... g \ 0 ....
..... 01100111 01011100 00110000 ....
Ok, Du willst mit aller Gewalt nicht verstehen, wie dieser String zu
interpretieren ist. Meinetwegen.
Post by Erich Schnoor
mit ungeeigneten _Programmierelementen_ verwechselt.
Die C-Darstellung ist sehr geeignet, um das Zeichen mit dem Wert 0 in
einem String darzustellen.
Post by Erich Schnoor
Die gezeigten Daten
haben nicht den Wert 0 !!!
Doch.
Post by Erich Schnoor
Es scheint immer noch nicht der Unterschied zwischen einem "Werkzeug" -
sprich Programmierspreche "C", Pascal oder BASIC - und der realen
Berechnung des Wertes einer digitalen Datenfolge klar zu sein.
Ja, und zwar Dir.
Post by Erich Schnoor
Die Programmiersprache ist nur ein Mittel zur Berechnung des Wertes und
nicht Gegenstand der Berechnung. Und wenn in einer digitalen Datenfolge
die Zeichen "\000\000G(\000\000\000" stehen sind sie _Gegenstand_
der Berechnung mit ihren digitalen Werten (01100111, 01011100, 00110000)
und nicht _Programmierelement_.
Wenn man aber den Wert 0 in einem String darstellen will, muss man eine
geeignete Darstellung finden. Eine davon ist die C-Darstellung (die wird
übrigens in so einigen anderes Sprachen auch verwendet, darunter min.
C++, Java, Perl, und PHP). Wenn Dir diese Darstellung nicht geläufig
ist, ist das ja ersteinmal kein Problem, Dir wurden jetzt zig Hilfen
genannt, wie die Werte gemeint sind.

Wenn Dir das Ergebnis nicht genehm ist, und Du weiter diesen String
anders interpretieren willst, bitte.
Post by Erich Schnoor
Will den tatsächlich noch jemand als Tallyman in den Hafen gehen und
Container zählen? Dann wird er merken, dass er auch die leeren Container
mit zählen muss.
Wenn man nur die vollen Container zählen soll nicht.
Post by Erich Schnoor
Gruss
Erich Schnoor
Gruß,
Sebastian
Ansgar -59cobalt- Wiechers
2003-12-14 00:50:39 UTC
Permalink
Post by Erich Schnoor
Post by Hendrik Weimer
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
"Dieses Hashverfahren ist grober Unfug" + chr(0) + chr(0) + "G(" +
chr(0) + chr(0) + chr(0)
"Dieses Hashverfahren ist grober Unfug" + chr$(0) + chr$(0) + "G(" +
chr$(0) + chr$(0) + chr$(0)
Das ganze interpretierst Du dann als Octet-Stream mit den
ASCII-Werten der Zeichen, dann ist n=44 und es ergibt die angebenen
Hashwerte.
Es werden von Sebastian wieder in den zitierten Programmiersprachen
digitale Daten
..... g \ 0 ....
..... 01100111 01011100 00110000 ....
mit ungeeigneten _Programmierelementen_ verwechselt. Die gezeigten
Daten haben nicht den Wert 0 !!!
Es scheint immer noch nicht der Unterschied zwischen einem "Werkzeug"
- sprich Programmierspreche "C", Pascal oder BASIC - und der realen
Berechnung des Wertes einer digitalen Datenfolge klar zu sein.
Würdest Du Dich *bitte* mit der ASCII-Tabelle und dem Umstand, dass sie
nicht-druckbare Steuerzeichen enthält vertraut machen? Würdest Du
*bitte* darüber hinaus dem Unterschied zwischen dem Zeichen 0 (ascii[0])
und der Ziffer '0' (ascii[48]) sowie den gebräuchlichen Schreibweisen
für das *Zeichen* 0 Deine besondere Aufmerksamkeit widmen? Danke.

cu
59cobalt
--
"Wir nehmen ständig an Glaubwürdigkeit zu."
--Darl McBride (SCO)
Eike Sauer
2003-12-13 01:36:59 UTC
Permalink
Hallo!
Post by Erich Schnoor
dann arbeit mein Programm nicht !
Probier es doch einmal selbst aus
Die Formel funktioniert damit.

Von einem Programm weiss ich nichts.
Aber wenn es damit nicht funktioniert - ist das gut so...?

Ciao,
Eike
Erich Schnoor
2003-12-13 10:52:43 UTC
Permalink
Post by Eike Sauer
Hallo!
Post by Erich Schnoor
dann arbeit mein Programm nicht !
Probier es doch einmal selbst aus
Die Formel funktioniert damit.
Von einem Programm weiss ich nichts.
Aber wenn es damit nicht funktioniert - ist das gut so...?
Ciao,
Eike
Vielleicht für Dich, für mich nicht

Gruss
Erich Schnoor
Erich Schnoor
2003-12-13 10:20:04 UTC
Permalink
Post by Patrick Schaaf
Post by Erich Schnoor
Post by Hendrik Weimer
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
entweder du kannst nicht zählen oder nicht rechnen!
Dein Beispiel - auch wenn es grober Unfug ist - hat
immerhin 59 Bytes !
Das Beispiel hat genau 44 Byte zwischen den Anfuehrungsstrichen.
Fuenf davon haben den Wert 0, die letzten 3, sowie die 2 zwischen
dem Unfug und G(. Du kannst entweder nicht lesen, oder kein C.
Gruss
Patrick
Anmerkung:

Die Programmiersprache "C" ist doch nur ein Instrument zur Berechnung
des Wertes und nicht _Gegenstand_ der Berechnung selbst. Wer den
Unterschied nicht sieht, sollte als "tallyman" in den Hafen gehen
und Container zählen. Da müssen auch leere Container gezählt werden,
auch wenn Nichts drinn ist (also den Wert 0 haben).

Gruss
Erich Schnoor
Eike Sauer
2003-12-13 11:34:56 UTC
Permalink
Post by Erich Schnoor
Die Programmiersprache "C" ist doch nur ein Instrument zur Berechnung
des Wertes und nicht _Gegenstand_ der Berechnung selbst. Wer den
Unterschied nicht sieht, sollte als "tallyman" in den Hafen gehen
und Container zählen. Da müssen auch leere Container gezählt werden,
auch wenn Nichts drinn ist (also den Wert 0 haben).
Du kannst oder willst das nicht verstehen.
Da man im Usenet kein ASCII-Zeichen mit dem Wert 0 übertragen
kann, wurde die Programmiersprache nur zur _Darstellung_ von
44 ASCII-Werten benutzt. Wenn dir diese Darstellung nicht
gefällt, nimm meine Aufzählung von Dezimalzahlen. Wenn deine
Formel Einschränkungen im Wertebereich aufweist, dokumentier
und begründe sie.

Ciao,
Eike
Thomas Skora
2003-12-15 14:48:43 UTC
Permalink
Post by Erich Schnoor
Die Programmiersprache "C" ist doch nur ein Instrument zur Berechnung
des Wertes und nicht _Gegenstand_ der Berechnung selbst.
Die \xxx-Notation ist auch nur eine Darstellung und hat in diesem Kontext
eigentlich keine weitere Bedeutung bzgl. einer Programmiersprache.
Post by Erich Schnoor
Wer den Unterschied nicht sieht, sollte als "tallyman" in den Hafen gehen
Wie oft willst du das hier noch erzählen?

Troll dich.

Thomas

Erich Schnoor
2003-12-11 07:09:29 UTC
Permalink
Post by Hendrik Weimer
"Dieses Hashverfahren ist grober Unfug\000\000G(\000\000\000"
n = 44, C(k) = 1849, H(k) = 6972281
Hendrik
Entschuldigung, in der Antwort auf Hendrik's Beispiel
muss es richtig lauten:

....................
Basis 16 = fedf4c

Gruss
Erich Schnoor
Thomas Hertel
2003-12-11 20:59:33 UTC
Permalink
Ich misch mich jetzt mal ein, auch wenn ich von Hashes keine Ahnung
hab. Bitte schon vorab um Verzeihung, falls das Unsinn ist.
Post by Erich Schnoor
Es soll ein Hashwert H(k) auf neue Art berechnet werden.
A (string) = a(1), a(2), a(3), ... a(i), ... a(n)
a = ASCII-Wert von a
n = Länge von A (in Bytes)
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Wenn ich von n=42 ausgeh und mir die Formel betrachte, dann ist der
grösstmögliche Hashwert H(k) gegeben bei konstantem a(i)=255 für
i=1...n, also irgendwo bei 18.000.000 +x mit x < 1.000.000. Habs heut
mal ausgerechnet, aber das exakte Ergebnis grad nicht verfügbar.

Bei n=42 habe ich aber 256^42 = 2^336 mögliche Strings, also um
etliche 10er Potenzen mehr Strings als Hashwerte (die ja alle
ganzzahlig sind). Wie könnte ich da Kollisionsfreiheit haben - mal von
den konkreten Beispielen abgesehen, die ja schon genannt wurden?

Gilt übrigens auch für andere Werte von n.

Oder hab ich da irgendwas fürchterlich missverstanden (oder mich
verrechnet)?

Gruß
Thomas
--
"The opinions expressed herein are subject to change without notice"
Aus dem Copyright-Vermerk einer Studie der Gartner Group
Email für Non-Spam: Meine_Initialen_bei_arcendo_punkt_com
Erich Schnoor
2003-12-12 09:19:47 UTC
Permalink
Post by Thomas Hertel
Ich misch mich jetzt mal ein, auch wenn ich von Hashes keine Ahnung
hab. Bitte schon vorab um Verzeihung, falls das Unsinn ist.
Post by Erich Schnoor
Es soll ein Hashwert H(k) auf neue Art berechnet werden.
A (string) = a(1), a(2), a(3), ... a(i), ... a(n)
a = ASCII-Wert von a
n = Länge von A (in Bytes)
n
Hashwert H(k) = SUMME (a(i) + 1) * (C(k) + i)
i = 1
Konstante C(k) = n * (n - 2) + 1
Wenn ich von n=42 ausgeh und mir die Formel betrachte, dann ist der
grösstmögliche Hashwert H(k) gegeben bei konstantem a(i)=255 für
i=1...n, also irgendwo bei 18.000.000 +x mit x < 1.000.000. Habs heut
mal ausgerechnet, aber das exakte Ergebnis grad nicht verfügbar.
Bei n=42 habe ich aber 256^42 = 2^336 mögliche Strings, also um
etliche 10er Potenzen mehr Strings als Hashwerte (die ja alle
ganzzahlig sind). Wie könnte ich da Kollisionsfreiheit haben - mal von
den konkreten Beispielen abgesehen, die ja schon genannt wurden?
Gilt übrigens auch für andere Werte von n.
Oder hab ich da irgendwas fürchterlich missverstanden (oder mich
verrechnet)?
Gruß
Thomas
Guten Morgen,

hier kommen endlich ernst zu nehmende Bedenken - allerdings offenbar
aus dem Bereich der Mathematik - und das ist gut so. Denn die Formel
betrifft streng genommen keine Krypto-Zusammenhänge, sondern sie kann
allenfalls zu Lösungen in der Kryptographie angewendet werden.

Das zitierte Beispiel:

n = 42
a(i) = constant 255

ergibt nach der Formel folgendes Ergebnis:

H(k) = 18 305 280 (dicht an 18.000.000)
Basis 16 = 1175100
Basis 64 = 15q40

Wenn auch die Zahl der möglichen Strings (2^336) größer ist als die
mögliche Zahl der Hashwerte, kommt es für die praktische Anwendung
sicherlich auch noch auf die Verteilung der Zeichen im String
(Positionsgewichtung) und eine zielgerichtete Vertauschung von Strings
an.
Die Kollisionsfreiheit ist bisher nur für den Austausch von 2 Bytes im
Eingabestring untersucht worden (siehe Abschnitt B 1 im Artikel:

http://www.telecypher.net/telecode.htm

Für den Austausch von mehr als 2 Zeichen ist der Nachweis noch nicht
erbracht (Artikel Abschnitt B 1 [am Ende]). Ich hoffe, dass diese
Diskussion Klarheit in diesen Bereich bringt.

Gruss
Erich Schnoor
Stefan Werner
2003-12-12 11:01:47 UTC
Permalink
Post by Erich Schnoor
Die Kollisionsfreiheit ist bisher nur für den Austausch von 2 Bytes im
http://www.telecypher.net/telecode.htm
Für den Austausch von mehr als 2 Zeichen ist der Nachweis noch nicht
erbracht (Artikel Abschnitt B 1 [am Ende]). Ich hoffe, dass diese
Diskussion Klarheit in diesen Bereich bringt.
Entschuldige die späte Einmischung, aber was ich beim Durchlesen des
Threads nicht ganz verstanden habe und in obiger Website auch nicht
finde (habe ich Tomaten auf den Augen? ;-) ):

Wo liegt der Vorteil gegenüber den ja gut untersuchten, abgehangenen und
in vielen Programmiersprachen bereits als library/modul implementierten
existierenden Algorithmen wie SHA1 oder MD5 (oder von mir aus auch
gegenüber CRC32)?


-stef
Andreas Beck
2003-12-12 13:05:10 UTC
Permalink
Post by Stefan Werner
Wo liegt der Vorteil gegenüber den ja gut untersuchten, abgehangenen und
in vielen Programmiersprachen bereits als library/modul implementierten
existierenden Algorithmen wie SHA1 oder MD5 (oder von mir aus auch
gegenüber CRC32)?
- Das Ergebnis ist unbeschränkt.
- Die Berechnung ist durch die Multiplikation teuer
- Das ganze ist massiv linear
- Man kann trivial Kollisionen finden.
- Der Hash leakt Plaintext.

Kurz: Es ist ein super Beispiel, wie man es _nicht_ macht.


CU, Andy
Stefan Werner
2003-12-12 16:37:42 UTC
Permalink
Post by Andreas Beck
Post by Stefan Werner
Wo liegt der Vorteil gegenüber den ja gut untersuchten, abgehangenen und
[...]
Post by Andreas Beck
Kurz: Es ist ein super Beispiel, wie man es _nicht_ macht.
Also Du meinst, ich darf im Moment ruhig noch bei SHA1 oder MD5 bleiben,
wenn ich Dich recht verstehe ;-)
Post by Andreas Beck
CU, Andy
-stef
Erich Schnoor
2003-12-12 18:02:54 UTC
Permalink
Post by Stefan Werner
Post by Erich Schnoor
Die Kollisionsfreiheit ist bisher nur für den Austausch von 2 Bytes im
http://www.telecypher.net/telecode.htm
Für den Austausch von mehr als 2 Zeichen ist der Nachweis noch nicht
erbracht (Artikel Abschnitt B 1 [am Ende]). Ich hoffe, dass diese
Diskussion Klarheit in diesen Bereich bringt.
Entschuldige die späte Einmischung, aber was ich beim Durchlesen des
Threads nicht ganz verstanden habe und in obiger Website auch nicht
Wo liegt der Vorteil gegenüber den ja gut untersuchten, abgehangenen und
in vielen Programmiersprachen bereits als library/modul implementierten
existierenden Algorithmen wie SHA1 oder MD5 (oder von mir aus auch
gegenüber CRC32)?
-stef
Um die _bekannten_ Dinge geht es nicht, es gibt ja auch noch bisher nicht
untersuchte Zusammenhänge.
Das Rad ist zwar auch schon lange entwickelt, aber trotzdem werden immer
wieder neue Räder in den Verkehr gebracht. Fahren tun sie alle.

Gruss
Erich Schnoor
Sebastian Biallas
2003-12-12 19:35:17 UTC
Permalink
Post by Erich Schnoor
Post by Stefan Werner
Wo liegt der Vorteil gegenüber den ja gut untersuchten, abgehangenen und
in vielen Programmiersprachen bereits als library/modul implementierten
existierenden Algorithmen wie SHA1 oder MD5 (oder von mir aus auch
gegenüber CRC32)?
Um die _bekannten_ Dinge geht es nicht, es gibt ja auch noch bisher nicht
untersuchte Zusammenhänge.
Natürlich geht es immer auch um die bekannten Verfahren..
Post by Erich Schnoor
Das Rad ist zwar auch schon lange entwickelt, aber trotzdem werden immer
wieder neue Räder in den Verkehr gebracht. Fahren tun sie alle.
.. denn auch ein Ingenieur, der das Rad neu erfindet, muss sich Fragen
gefallen lassen, was denn die Vorteile seines Rades sind. Und bis jetzt
haben sich irgendwie nur Nachteile Deines Verfahrens gegenüber den
klassischen gezeigt.
Post by Erich Schnoor
Gruss
Erich Schnoor
Gruß,
Sebastian
Stefan Werner
2003-12-13 06:43:44 UTC
Permalink
Post by Erich Schnoor
Post by Stefan Werner
Wo liegt der Vorteil gegenüber den ja gut untersuchten, abgehangenen und
in vielen Programmiersprachen bereits als library/modul implementierten
existierenden Algorithmen wie SHA1 oder MD5 (oder von mir aus auch
Um die _bekannten_ Dinge geht es nicht, es gibt ja auch noch bisher nicht
untersuchte Zusammenhänge.
Das Rad ist zwar auch schon lange entwickelt, aber trotzdem werden immer
wieder neue Räder in den Verkehr gebracht. Fahren tun sie alle.
Ich weiss nicht.. Man verwendet einen Hash-Algorithmus ja nicht einfach
l'art pour l'art, sondern um eine bestimmte Aufgabe zu erfüllen. Wenn
ein neuer Algorithmus verwendet werden soll, dann muss er diese Aufgabe
_besser_ erfüllen, als die bisherigen.

(Um bei Deinem Beispiel zu bleiben: Wenn ein Ingenieur für die
Autoreifen ein neues Material verwenden will, dann muss dieses neue
Material in irgendeiner Hinsicht besser sein, als das bewährte, und es
darf in keinem wesentlichen Bereich schlechter sein. Kein Autohersteller
wird einfach Holzreifen verwenden, bloss weil es eine originelle und
neue Idee ist, die von ihrem Enwtickler vehement verteidigt wird.)

-stef
Sebastian Posner
2003-12-13 13:00:26 UTC
Permalink
Post by Stefan Werner
(Um bei Deinem Beispiel zu bleiben: Wenn ein Ingenieur für die
Autoreifen ein neues Material verwenden will, dann muss dieses neue
Material in irgendeiner Hinsicht besser sein, als das bewährte, und es
darf in keinem wesentlichen Bereich schlechter sein. Kein Autohersteller
wird einfach Holzreifen verwenden, bloss weil es eine originelle und
neue Idee ist, die von ihrem Enwtickler vehement verteidigt wird.)
Hey, aber er ist *viiiiel* besser biologisch abbaubar!

Sebastian
--
"Ja der weiße Mann aus Texas / Dreht den Teufel heut am Spieß,
Und alle, die ein anderes Lied singen / grillt der Mann im Fegefeuer mit"
Fink feat. Peter Lohmeyer / Bagdad Blues ( Der weiße Mann aus Texas)
Bodo Eggert
2003-12-12 11:27:05 UTC
Permalink
Post by Erich Schnoor
Für den Austausch von mehr als 2 Zeichen ist der Nachweis noch nicht
erbracht (Artikel Abschnitt B 1 [am Ende]). Ich hoffe, dass diese
Diskussion Klarheit in diesen Bereich bringt.
Ein Austausch von mehr als 2 Byte läßt sich auf den Trivialfall zurückführen.
Der Beweis ist den Lesern zur Übung empfohlen.
--
Top 100 things you don't want the sysadmin to say:
90. Wow....that seemed _fast_.....

Friß, Spammer: ***@centennialrd.com ***@posting.7eggert.dyndns.org
Andreas Beck
2003-12-12 13:30:45 UTC
Permalink
Post by Erich Schnoor
hier kommen endlich ernst zu nehmende Bedenken
Du hast eine wahnsinnig selektive Wahrnehmung. Die werde ich jetzt
glaube ich auch aktivieren. Das ist ja nicht zum aushalten ...
Post by Erich Schnoor
- allerdings offenbar aus dem Bereich der Mathematik - und das ist
gut so. Denn die Formel betrifft streng genommen keine Krypto-
Zusammenhänge, sondern sie kann allenfalls zu Lösungen in der
Kryptographie angewendet werden.
Parse error. Kryptographie _ist_ Mathematik. In der Regel sogar nicht
ganz triviale.
Post by Erich Schnoor
H(k) = 18 305 280 (dicht an 18.000.000)
Wenn auch die Zahl der möglichen Strings (2^336) größer ist als die
mögliche Zahl der Hashwerte, kommt es für die praktische Anwendung
sicherlich auch noch auf die Verteilung der Zeichen im String
(Positionsgewichtung) und eine zielgerichtete Vertauschung von Strings
an.
Nein. Die Kollisionswahrscheinlichkeit ist im Kontext _Crypto_ nicht mit
solchem Killefitz in Zusammenhang zu bringen. Es dürfte da eher die
Ausnahme sein, daß man nur einzelne Zeichen grad _vertauschen_ kann.

Und der H-max ist eh schon indiskutabel. Das ergibt gerade mal ca. 24
Bit ... das ist ein Lacher zu bruteforcen. Von Birthday-Angriffen reden
wir mal gar nicht ...

Außerdem kann man direkt aus der Zahlengröße die Größe des Klartextes
abschätzen usw. usw.

Irgendwelche Kollisionsabschätzungen für bestimmte Operationen
(Vertauschen, kippende Bits etc.) machen Sinn für
Fehlererkennungsanwendungen. Das ist ne andere Baustelle.

Und auch da gibt es fundierte Theorien zu. Guck Dir mal was zu CRCs an.
Post by Erich Schnoor
http://www.telecypher.net/telecode.htm
Für den Austausch von mehr als 2 Zeichen
Wer will schon austauschen, wenn er manipulieren kann.

So, jetzt EOD für mich, ich halt das nimmer aus.

Won't CU, Andy
Erich Schnoor
2003-12-13 12:27:17 UTC
Permalink
Post by Andreas Beck
Post by Erich Schnoor
hier kommen endlich ernst zu nehmende Bedenken
Du hast eine wahnsinnig selektive Wahrnehmung. Die werde ich jetzt
glaube ich auch aktivieren. Das ist ja nicht zum aushalten ...
Post by Erich Schnoor
- allerdings offenbar aus dem Bereich der Mathematik - und das ist
gut so. Denn die Formel betrifft streng genommen keine Krypto-
Zusammenhänge, sondern sie kann allenfalls zu Lösungen in der
Kryptographie angewendet werden.
Parse error. Kryptographie _ist_ Mathematik. In der Regel sogar nicht
ganz triviale.
Post by Erich Schnoor
H(k) = 18 305 280 (dicht an 18.000.000)
Wenn auch die Zahl der möglichen Strings (2^336) größer ist als die
mögliche Zahl der Hashwerte, kommt es für die praktische Anwendung
sicherlich auch noch auf die Verteilung der Zeichen im String
(Positionsgewichtung) und eine zielgerichtete Vertauschung von Strings
an.
Nein. Die Kollisionswahrscheinlichkeit ist im Kontext _Crypto_ nicht mit
solchem Killefitz in Zusammenhang zu bringen. Es dürfte da eher die
Ausnahme sein, daß man nur einzelne Zeichen grad _vertauschen_ kann.
Und der H-max ist eh schon indiskutabel. Das ergibt gerade mal ca. 24
Bit ... das ist ein Lacher zu bruteforcen. Von Birthday-Angriffen reden
wir mal gar nicht ...
Außerdem kann man direkt aus der Zahlengröße die Größe des Klartextes
abschätzen usw. usw.
Irgendwelche Kollisionsabschätzungen für bestimmte Operationen
(Vertauschen, kippende Bits etc.) machen Sinn für
Fehlererkennungsanwendungen. Das ist ne andere Baustelle.
Und auch da gibt es fundierte Theorien zu. Guck Dir mal was zu CRCs an.
Post by Erich Schnoor
http://www.telecypher.net/telecode.htm
Für den Austausch von mehr als 2 Zeichen
Wer will schon austauschen, wenn er manipulieren kann.
So, jetzt EOD für mich, ich halt das nimmer aus.
Won't CU, Andy
Fortsetzung:

Das ist gut, dass er weg ist. Denn die gesamte Funktion geht ja noch
weiter. Bisher sind ja nur die Konstante C(k) und das Ergebnis H(k)
errechnet worden.

Die Einwendungen von Thomas Hertel (Beitrag 47), dass bei n = 42 die
möglichen Bytefolgen (strings) mit 2^336 die errechenbaren Hashwerte
um etliches übersteigen, sind ja richtig. Das war mir bei der
Entwicklung auch sehr schnell klar geworden.

Das Verfahren ist daher an dieser Stelle erweitert (bisher allerdings
im Sachverhalt hier noch nicht beschrieben, aber im Artikel
http://www.telecypher.net/telecode.htm
ausführlich erläutert. Um zu einem endgültigen Hashwert zu kommen,
wird die hier beispielhaft zugrunde gelegte Bytefolge

3 Nordlichter wandern über den großen Belt

einer zusätzlichen Expansionsfunktion unterworfen, wie folgt:

n = Länge Bytefolge = 42
H(k) = Hash-Konstante = 1681
b = Blockzähler = 1

FOR I = 1 TO n
a = (( a(i)+1) * I * H(k)) + (b+i)
CALL DezNachSystem (63, a, Ziffer$)
HashReihe$ = HashReihe$ + Ziffer$
H(p)= H(p) + a
NEXT I

Die HashReihe ist eine _Zahl_ im Zahlensystem zur Basis 63 wie folgt:

257 Ziffern im Zahlensystem zur Basis 63

A4AjFfbN0xadTDLBR1etUFA39Hyfy42VEc74GDcq45MhPK15xKXVp6KLV6S7Nj4mW92cZ1
c8ajrtdAVgPQ43FUMGuCdfzCpB0zvOODGBskuCldtXADbkxfQG9yvUPGNhKhM56KgzZL0N
np4Ggc6W7HuctcEL0Nnp76GMXwaJrfbv&KmDWv6NOrK&M7BmDJQNNyZD8QefKtSQkQon7s
ZyVq1PnEbgsSql6U88o1ORrIMW&kSSeoEzkVOz4IAYWwOug

Die Sensibilität der Erweiterungsfunktion zeigt sich, wenn in der
Bytefolge das letzte Bit veränder wird:

3 Nordlichter wandern über den großen Belu
-
t = 0111 0100
u = 0111 0101

Alle anderen Bits der Bytefolge beiben unverändert. Das Verfahren
errechnet dann die folgede HashReihe:

257 Ziffern im Zahlensystem zur Basis 63

A4cCfIlN1KAnTDmpU1ev77v39L4AQ42ZCEu4GHnug5MmeYT5xQNcx6KRgnj7NqJbB92lQj
38asJG4AVqhQ83FXXpFCdsObPB1Aj4wDGOsvrClqQk1DbyJzBGAElw&GNxOcM56PhA5L0h
PpCGgsTxpHuuTbhL0hPpF6GSfjjJrz6b8KmXu23NPEHBD7BtGPeNOLUwIQf5UMgQkq3tts
&q0gFPnculASrDPOK8oA1olIMna5vSfGMBWVPTrLlYp4f8g

Diese Zahlen sind nun schon ein wenig größer als die von Thomas Hertel
aufgezeigte Obergrenze mit 2^336 Möglichkeiten. Die Erweiterung schließt
die Vorteile von C(k) und H(k) ein, die eventuellen Nachteile werden
durch die Erweiterung des Ergebnisses auf die HashReihe vermieden. Das
kann auch alles in dem schon wiederholt zitierten Artikel nachgelesen
werden.

Die Umrechnung von a in Ziffern des Zahlensystems zur Basis 63 erfolgt
mit der Funktion "CALL DezNachSystem" aus dem Programm NUMBERXT.EXE.
Mit der Funktion werden Zahlen in Systemen von Basis 2 bis Basis 128
umgerechnet. Interessenten können per e-mail das Programm kostenlos
erhalten.

Man möge mir verzeihen, dass die Erweiterung erst jetzt ins Spiel kommt.
Aber hätte ich gleich alles geschildert, wäre die "Langeweile" mancher
Teilnehmer (Zitat: Andreas Beck im Beitrag 25)wohl noch viel größer gewesen.

Gruss
Erich Schnoor
Eike Sauer
2003-12-13 14:38:19 UTC
Permalink
Post by Erich Schnoor
Man möge mir verzeihen, dass die Erweiterung erst jetzt ins Spiel kommt.
Nein.

Erst volle Information, dann Diskussion.

Bist du irgendwie verwandt oder verschwägert mit Stefan Weinzierl
(Thread "Braucht Jemand ein einfaches Autorisierungssystem mit
verschlüsselter Datenübertragung?")?

Ciao,
Eike
Frank Meyer
2003-12-13 18:11:11 UTC
Permalink
Post by Eike Sauer
Bist du irgendwie verwandt oder verschwägert mit Stefan Weinzierl
(Thread "Braucht Jemand ein einfaches Autorisierungssystem mit
verschlüsselter Datenübertragung?")?
Ich hatte da auch ein déjà vu. Auch Erich fängt nun an, an
seinem Konzept irgendetwas dranzustricken, um offensichtliche
Fehler im Design zu vertuschen.

Gruß,

Frank
Erich Schnoor
2003-12-13 12:32:47 UTC
Permalink
Post by Andreas Beck
Post by Erich Schnoor
hier kommen endlich ernst zu nehmende Bedenken
Du hast eine wahnsinnig selektive Wahrnehmung. Die werde ich jetzt
glaube ich auch aktivieren. Das ist ja nicht zum aushalten ...
So, jetzt EOD für mich, ich halt das nimmer aus.
Won't CU, Andy
Nachsatz:

Ich halte das auch nicht mehr aus.
So etwas ist mit in meinem ganzen Leben noch nicht geboten worden
Damit ist die Diskussion beendet.

Erich Schnoor
Eike Sauer
2003-12-12 12:16:33 UTC
Permalink
Post by Erich Schnoor
http://www.telecypher.net/telecode.htm
Könntest du den Disclaimer
"Achtung: Die unter ...//groups.google.com/... archivierten
Erläuterungen sind technisch überholt und veraltet)"
so umformulieren, dass er sich nicht von der aktuellen
Diskussion gleich mit distanziert?

Ciao,
Eike
Erich Schnoor
2003-12-13 10:11:20 UTC
Permalink
Post by Eike Sauer
Post by Erich Schnoor
http://www.telecypher.net/telecode.htm
Könntest du den Disclaimer
"Achtung: Die unter ...//groups.google.com/... archivierten
Erläuterungen sind technisch überholt und veraltet)"
so umformulieren, dass er sich nicht von der aktuellen
Diskussion gleich mit distanziert?
Ciao,
Eike
Guten Morgen, Eike,

vielen Dank für den Hinweis. Der Hinweis bezieht sich auch
auf "alte Kamellen" aus den Jahren 2000 oder 2001. Aber da
ich immer wieder mit den damaligen Einwänden konfrontiert
werde, war der Vermerk bisher nötig.

Gruss
Erich Schnoor
Erich Schnoor
2003-12-13 14:11:02 UTC
Permalink
Mein Angebot in vorheriger Post, Interessenten aus der Gruppe
mein programm NUMBERXT.EXE auf e-mail Anforderung kostenlos zur
Verfügung zu stellen, ziehe ich zurück.

Erich Schnoor
Marcus Maskos
2003-12-13 18:20:04 UTC
Permalink
Post by Erich Schnoor
Mein Angebot in vorheriger Post, Interessenten aus der Gruppe
mein programm NUMBERXT.EXE auf e-mail Anforderung kostenlos zur
Verfügung zu stellen, ziehe ich zurück.
Sehr gut. Bitte achte auch darauf, dass sich das Ding
nicht anderweitig verbreitet.
Lesen Sie weiter auf narkive:
Loading...