Wie funktioniert der 'tinyurl' Mechanismus?

Computer: Software & Programmierung PHP
#1

Hallo zusammen,

ich wollte für eines meiner Scripts kleine Zufalls-Zeichenketten erstellen und will dabei aber vermeiden, dass es identische Zeichenketten gibt…
Nun ist die Frage, wie das funktioniert? Also wie machen die von Tinyurl das, dass es keine doubletten gibt und jeder „Hash“ einzigartig bleibt?

Bei immer mehr Datensätzen kann man da ja keine Funktion bauen im Stil von
erzeugezufallszahl()
{
if indatabase($hash = rand(„aaaaaa“;„zzzzzz“)) erzeugezufallszahl();
else return $hash;
}
da könnte u.U. ja auch passieren, dass die Funktion erst tausende von gleichen Werten ausspuckt, bis mal ein freier mit dabei ist…?

also wie kann man sowas realisieren?

Vielen Dank schon mal

Grüße
Munich

#2

Hallo zusammen,

ich wollte für eines meiner Scripts kleine
Zufalls-Zeichenketten erstellen und will dabei aber vermeiden,
dass es identische Zeichenketten gibt…
Nun ist die Frage, wie das funktioniert? Also wie machen die
von Tinyurl das, dass es keine doubletten gibt und jeder
„Hash“ einzigartig bleibt?

ist es denn bei tinyurl ein hash oder ein „zufaelliger“ schluessel?
deine frage gehoert zu informatik, hier sind nur programmierer :smile:

dann musst du aber auch noch sagen, inwiefern deine schluessel vorhersagbar und/oder erratbar sein duerfen.

Bei immer mehr Datensätzen kann man da ja keine Funktion bauen
im Stil von
erzeugezufallszahl()
{
if indatabase($hash = rand(„aaaaaa“;„zzzzzz“))
erzeugezufallszahl();
else return $hash;
}
da könnte u.U. ja auch passieren, dass die Funktion erst
tausende von gleichen Werten ausspuckt, bis mal ein freier mit
dabei ist…?

naja, fuer die ersten 100 mill. eintraege ist das trotzdem ein gangbarer weg, schliesslich kannst du aus einem raum von 7 stllg [a-z0-9] also 36^7=78.364.164.096 schoepfen. siehst du eine theoretische moeglichkeit bei deiner anwendung annaehernd in diese groessenordnung zu kommen?
und mt_rand ist eigentlich auch ganz gut, so dass du eigentlich von anfang an den verfuegbaren raum gut ausnutzen kannst.

wobei sich bei tinyurl der raum reduziert: ich habe vorhin getestet und immer schluessel gefunden, die mit y beginnen.

der triviale ansatz waere natuerlich die schluessel vorgenerieren. und aus der menge der verfuegbaren elementen zufaellig einen auszuwaehlen.

#3

ist es denn bei tinyurl ein hash oder ein „zufaelliger“
schluessel?

ziemlich sicher zufällig - denn es wird sicher nicht aus dem Schlüssel zurückgerechnet werden können, wie dieser in lang aussehen würde… dazu erscheint mir die „Kompressionsrate“ zu hoch :wink:

deine frage gehoert zu informatik, hier sind nur programmierer

-)

*grübel*
Und Programmierer sind keine Informatiker? :wink:

dann musst du aber auch noch sagen, inwiefern deine schluessel
vorhersagbar und/oder erratbar sein duerfen.

am besten garnicht :wink:
wirre Zeichenfolgen von Zahlen und Buchstaben wären ideal…
Hab da mal versucht einfach einen Teil eines md5 hash’s zu nehmen, aber der scheint nur die Buchstaben a-f zu verwenden und das ist mir zu gering unterschiedlich :smile:

da könnte u.U. ja auch passieren, dass die Funktion erst
tausende von gleichen Werten ausspuckt, bis mal ein freier mit
dabei ist…?

naja, fuer die ersten 100 mill. eintraege ist das trotzdem ein
gangbarer weg, schliesslich kannst du aus einem raum von 7
stllg [a-z0-9] also 36^7=78.364.164.096 schoepfen. siehst du
eine theoretische moeglichkeit bei deiner anwendung annaehernd
in diese groessenordnung zu kommen?
und mt_rand ist eigentlich auch ganz gut, so dass du
eigentlich von anfang an den verfuegbaren raum gut ausnutzen
kannst.

hmmm okay… das scheint natürlich weit auszureichen…
Ich werde in meinem Script in diese Mengenordnung sicher nicht kommen - zumindest solange nicht, wie ich das Script nur selbst nutze :wink:
Bleibt nur die Frage, wie ich das am geschicktesten erzeugen soll…

wobei sich bei tinyurl der raum reduziert: ich habe vorhin
getestet und immer schluessel gefunden, die mit y beginnen.

vielleicht ist das auch eine Art „timestamp“ y sind alle im Februar 2010 angelegten, dann kommen die z-werte für März und irgendwann gehts wieder mit den a-werten los :wink:

der triviale ansatz waere natuerlich die schluessel
vorgenerieren. und aus der menge der verfuegbaren elementen
zufaellig einen auszuwaehlen.

hmmm… ja, das wäre auch ne Idee - aber mal eben 78 Mrd Schlüssel generieren… das macht doch keiner, oder doch? :wink:

Grüße und Danke schon mal
Munich

#4

ist es denn bei tinyurl ein hash oder ein „zufaelliger“
schluessel?

ziemlich sicher zufällig - denn es wird sicher nicht aus dem
Schlüssel zurückgerechnet werden können, wie dieser in lang
aussehen würde… dazu erscheint mir die „Kompressionsrate“ zu
hoch :wink:

deine frage gehoert zu informatik, hier sind nur programmierer

-)

*grübel*
Und Programmierer sind keine Informatiker? :wink:

*das muss ironie sein*

wiki sacht zur informatik:
Informatik ist die Wissenschaft von der systematischen Verarbeitung von Informationen, insbesondere der automatischen Verarbeitung mit Hilfe von Rechenanlagen.
Dennoch stellen Computer nur ein Werkzeug und Medium der Informatik dar, um die theoretischen Konzepte praktisch umzusetzen.

wiki sacht über programmierer
Ein Programmierer ist jemand, der Computerprogramme entwirft, weiterentwickelt und Fehler darin korrigiert. Diese Tätigkeit wird als Programmieren bezeichnet. Der Programmierer bedient sich hierzu einer geeigneten Programmiersprache. Der erste Programmierer der Geschichte war eine Frau: die britische Mathematikerin Ada Lovelace.

also Programmierer(in) = Werkzeug und Medium der Informatik

dann musst du aber auch noch sagen, inwiefern deine schluessel
vorhersagbar und/oder erratbar sein duerfen.

am besten garnicht :wink:
wirre Zeichenfolgen von Zahlen und Buchstaben wären ideal…
Hab da mal versucht einfach einen Teil eines md5 hash’s zu
nehmen, aber der scheint nur die Buchstaben a-f zu verwenden
und das ist mir zu gering unterschiedlich :smile:

da könnte u.U. ja auch passieren, dass die Funktion erst
tausende von gleichen Werten ausspuckt, bis mal ein freier mit
dabei ist…?

naja, fuer die ersten 100 mill. eintraege ist das trotzdem ein
gangbarer weg, schliesslich kannst du aus einem raum von 7
stllg [a-z0-9] also 36^7=78.364.164.096 schoepfen. siehst du
eine theoretische moeglichkeit bei deiner anwendung annaehernd
in diese groessenordnung zu kommen?
und mt_rand ist eigentlich auch ganz gut, so dass du
eigentlich von anfang an den verfuegbaren raum gut ausnutzen
kannst.

hmmm okay… das scheint natürlich weit auszureichen…
Ich werde in meinem Script in diese Mengenordnung sicher nicht
kommen - zumindest solange nicht, wie ich das Script nur
selbst nutze :wink:
Bleibt nur die Frage, wie ich das am geschicktesten erzeugen
soll…

wobei sich bei tinyurl der raum reduziert: ich habe vorhin
getestet und immer schluessel gefunden, die mit y beginnen.

vielleicht ist das auch eine Art „timestamp“ y sind alle im
Februar 2010 angelegten, dann kommen die z-werte für März und
irgendwann gehts wieder mit den a-werten los :wink:

der triviale ansatz waere natuerlich die schluessel
vorgenerieren. und aus der menge der verfuegbaren elementen
zufaellig einen auszuwaehlen.

hmmm… ja, das wäre auch ne Idee - aber mal eben 78 Mrd
Schlüssel generieren… das macht doch keiner, oder doch? :wink:

naja damit impizierst du das du gleich mal 78mrd leute als besucher hast ?
ich würd pro tag vielleicht den algorythmus für 100000 neue zahlen erstellen lassen, und die abarbeiten und dann wieder 100000 neue oder mehr oder weniger wie du brauchst. Wichtig wäre nur das genutzte makiert werden müssen , neue und noch nicht markierte kann man dann random mässig verteilen. Damit bleiben immernoch die 78mrd möglichkeiten und sie werden auch vorproduziert, halt nur nicht alle auf einmal sondern im kontingent.

Grüße und Danke schon mal
Munich

1 Like
#5

ist es denn bei tinyurl ein hash oder ein „zufaelliger“
schluessel?

ziemlich sicher zufällig - denn es wird sicher nicht aus dem
Schlüssel zurückgerechnet werden können, wie dieser in lang
aussehen würde…

kannst du aus nem md5 oder sha auch nicht. und der ist auch nicht zufaellig. sondern sehr eindeutig und das wollen die ja bei tinyurl.

deine frage gehoert zu informatik, hier sind nur programmierer

-)

*grübel*
Und Programmierer sind keine Informatiker? :wink:

nö, ein informatiker kann dir dein problem berechnen, wir anderen koennen nur if/else schreiben und bei echten problem auf die nase stuerzen.

Bleibt nur die Frage, wie ich das am geschicktesten erzeugen
soll…

na am einfachsten: fuer jede stelle eine zufallszahl aus deinem alphabet ermitteln und stelle fuer stelle concatenieren.

$alpa = [a,b,c,d];//um die von dir genannten wirren zeichen erweitern.
$out = "";
while (strlen($out)



> hmmm... ja, das wäre auch ne Idee - aber mal eben 78 Mrd  
> Schlüssel generieren... das macht doch keiner, oder doch? :wink:


kenne ich z.b. von gutscheincodes.

wie wir jetzt wissen reichen dir ja erstmal 100 millionen aus. 

du kannst auch erstmal 100.000 generieren und wenn die zu 50% zu ende gegangen sind, kannnst du eine hypothese aufstellen, wieviele schluessel fuer den naechsten schritt sinnvoll waeren.

aber du hast ja wahrscheinlich kein problem und musst also nicht vorgenerieren. du kannst das aber sehr schoen monitoren, und wenn irgendwann die kollisionen anfangen mehr zu werden, kannst du immer noch reagieren, das soltle nciht schlagartig steigen.
1 Like
#6

also Programmierer(in) = Werkzeug und Medium der Informatik

Also sind Programmierer eine Teilmenge der Informatik? *kicher*
okay… Esc, F1, Esc - Ich blick nimmer wirklich durch *lach*

naja damit impizierst du das du gleich mal 78mrd leute als
besucher hast ?

Nein nein - soviele sind wir ja garnicht :smile:
Aber mal angenommen man hätte 10 Fotos, Links, whatever von jedem Menschen und will diese mit einem eindeutigen string absichern, dann müsste man das ja irgendwie in der Art tun, nicht wahr? Also mal abgesehen davon, dass man das dann anders machen sollte aber mir gehts jetzt rein um die Theorie und ums Verstehen…

ich würd pro tag vielleicht den algorythmus für 100000 neue
zahlen erstellen lassen, und die abarbeiten und dann wieder
100000 neue oder mehr oder weniger wie du brauchst. Wichtig
wäre nur das genutzte makiert werden müssen , neue und noch
nicht markierte kann man dann random mässig verteilen. Damit
bleiben immernoch die 78mrd möglichkeiten und sie werden auch
vorproduziert, halt nur nicht alle auf einmal sondern im
kontingent.

Tja und jetzt sind wir wieder am Anfang angekommen:
Wie generiert man diese 100.000 denn nun? angenommen es wären keine 78 Mrd, sondern „nur“ 10 Mio…
Jetzt generiert man über ein-zwei Jahre derartige Zufälligen Zeichenketten bis man irgendwann 9,9 von den möglichen genutzt hat…
Und jetzt wirds interessant (find ich).
Wenn ich nun nur durch ein „stochern im Teich“ die restlichen Löcher finden kann, dann kann das doch sehr lange dauern, bis ich überhaupt etwas finde oder nicht?
Und im Gegenzug weiss ich nicht, ob es meiner Datenbank so gut gefallen würde, wenn ich sage "hast Du Max unter den 9,9 Mio Datensätzen gefunden? Ja? Mist… dann such mal nach Moritz? auch gefunden… Oha… und was ist mit Anna? oweh… hast Du schon mal Max probiert?
Eigentlich sehe ich da ja nur die Möglichkeit die dann der Reihe nach zu generieren… und das würde dann bedeuten, dass ich erst mal quasi Zeichenketten von AAAAA bis BAAAA erstellen könnte… und die wären dann ja auch nicht gerade schwer zu knacken - falls ich die nur als Argument in einer GET-Anweisung heranziehe…?
Oder übersehe ich da irgendwelche Möglichkeiten?

Vielen dank schon mal euch beiden :smile:
Grüße
Munich

#7

Tja und jetzt sind wir wieder am Anfang angekommen:
Wie generiert man diese 100.000 denn nun? angenommen es wären
keine 78 Mrd, sondern „nur“ 10 Mio…
Jetzt generiert man über ein-zwei Jahre derartige Zufälligen
Zeichenketten bis man irgendwann 9,9 von den möglichen genutzt
hat…
Und jetzt wirds interessant (find ich).
Wenn ich nun nur durch ein „stochern im Teich“ die restlichen
Löcher finden kann, dann kann das doch sehr lange dauern, bis
ich überhaupt etwas finde oder nicht?

ne ich stocher nicht im teich, alle die ich schon benutzt habe will ich nicht, aus den noch verbleibenden nehm ich einen random datensatz, das muss nichtmal in der selben datenbank geschehen. Wichtig ist nur das irgentwann einer die menge der benutzen archiviert oder dank Logarythmus einfach nur benutzte gelöscht werden,da man ja immer eindeutige neue erstellt.

ich erst mal quasi Zeichenketten von AAAAA bis BAAAA erstellen
könnte… und die wären dann ja auch nicht gerade schwer zu

ja genau ein Logarythmus muss herr , von mir aus am ende noch die zeit ranhägen als imer vortlaufender faktor und eindeutigkeit (wenn millisekunden eindeutig sind) , wie der aussieht ist eigentlich egal, denn wenn es sowieso am ende alle kombinationen verteilt werden, ist jede key ein möglicher key , der ja nur zu identifikation erzeugt wird.
Es kann also egal sein, solange du neue lose erstellst, kannst du alte benutze löschen udn immer deine datenmenge auf aktuelle benutzerzahl pro monat oder tag oder woche oder stunde +50% bereithalten.

Nur wenn man seine identifikation geheim halten will , dann muss die menge zig mal grösser sein aus der man die randoms fischt und mann darf wie gesagt nur eine ganz kleine menge der möglichkeiten verteilen.

1 Like
#8

Tja und jetzt sind wir wieder am Anfang angekommen:
Wie generiert man diese 100.000 denn nun? angenommen es wären
keine 78 Mrd, sondern „nur“ 10 Mio…

warum das denn? um ein problem zu konstruieren, dass niemand haben will?
was ein quatsch. die 78mrd waren fuer einen 7stellg. schluessel nimm halt 8 stellen, dann hast du 2.821.109.907.456 moeglichkeiten. oder 9 stellen dann 101.559.956.668.416 - das ist total easy und du wirst keinen betriebszustand erreichen, indem du 20x hintereinander zufaellig einen belegten schluessel findest. weil du dir gar kein system leisten kannst, das auch nur soviel festplattenspeicher hat, um diese anzahl von schluessel-value paaren strukturiert speichern.

und selbst wenn du 100x hintereinadner einen belegten schluessel finden solltest hast du immer noch kein laufzeitproblem.

Jetzt generiert man über ein-zwei Jahre derartige Zufälligen
Zeichenketten bis man irgendwann 9,9 von den möglichen genutzt
hat…
Und jetzt wirds interessant (find ich).

nö, das ist total uninteressant, wenn du deinen raum zu 99% ausgeschoepft hast, ohne was zu tun, bist du sowieso am arsch.

Wenn ich nun nur durch ein „stochern im Teich“ die restlichen
Löcher finden kann, dann kann das doch sehr lange dauern, bis
ich überhaupt etwas finde oder nicht?

richtig, deshalb sollst du diese situation vermeiden, indem du deine schluessel aus einem genuegend grossen bereich nimmst.

1 Like
#9

Und jetzt wirds interessant (find ich).
Wenn ich nun nur durch ein „stochern im Teich“ die restlichen
Löcher finden kann, dann kann das doch sehr lange dauern, bis
ich überhaupt etwas finde oder nicht?

ne ich stocher nicht im teich, alle die ich schon benutzt habe
will ich nicht, aus den noch verbleibenden nehm ich einen
random datensatz,

er hat aber insofern recht: du musst „die noch verbleibenden“ halt schon mal erzeugt haben.

#10

jetzt hast Du mich auf ne Idee gebracht!

warum das denn? um ein problem zu konstruieren, dass niemand
haben will?
was ein quatsch. die 78mrd waren fuer einen 7stellg.
schluessel nimm halt 8 stellen, dann hast du 2.821.109.907.456
moeglichkeiten. oder 9 stellen dann 101.559.956.668.416 - das
ist total easy und du wirst keinen betriebszustand erreichen,
indem du 20x hintereinander zufaellig einen belegten
schluessel findest. weil du dir gar kein system leisten
kannst, das auch nur soviel festplattenspeicher hat, um diese
anzahl von schluessel-value paaren strukturiert speichern.

das Beispiel war gerade echt genial!
Ich weiss nun, wie ich das bauen werde…
Und zwar werde ich eine rekursive Funktion basteln, die ermittelt, ob dieser Schlüssel schon existent ist oder nicht. Falls er das sein sollte, dann sucht er nochmal nach einem freien Schlüssel - aber diesmal mit einer Stelle mehr…
Dadurch kann ich nun quasi mit einem dreistelligen String beginnen und mit der unendlichkeit aufhören - und bin immernoch sicher, dass es nie dazu kommen wird, dass die rekursive Funktion ins leere rennt - und das beste dabei ist, dass selbst nach millionen Datensätzen immernoch welche rauskommen können, die kurz und knackig sind :smile:

und selbst wenn du 100x hintereinadner einen belegten
schluessel finden solltest hast du immer noch kein
laufzeitproblem.

auch dann nicht, wenn ich über 10 Mio Datensätze abfragen müsste?

nö, das ist total uninteressant, wenn du deinen raum zu 99%
ausgeschoepft hast, ohne was zu tun, bist du sowieso am arsch.

*kicher* wenn ich soviele Stellen verwende schon… ja :smile:

Wenn ich nun nur durch ein „stochern im Teich“ die restlichen
Löcher finden kann, dann kann das doch sehr lange dauern, bis
ich überhaupt etwas finde oder nicht?

richtig, deshalb sollst du diese situation vermeiden, indem du
deine schluessel aus einem genuegend grossen bereich nimmst.

*wasser hol* :wink:

Danke für Deinen Hinweis, der mich auf diese wie ich finde elegante Lösung gebracht hat :smile:

Grüße
Munich

#11

so aus dem satz gerissen hast du recht, aber du solltest das nicht so ZEITUNGSMÄSSIG machen.

solange der erzeuger key schon beim erzeugen eindeutig gemacht wird , gehts. mit random erzeugung und etc sind wir ganz woanders. Ich sag ja logarythmus, ich glaub du weisst was das ist. Also entscheidet der logarythmus über die nächsten stellen, wie man das macht ist ne andere sache, ob ich einen nehme wo ich am monatag den vorderen 1 millionen raum abgrasse und am dienstag den hinteren 1millionen bereich erzeuge. Solange alles immer eindeutig bleibt ist es egal. Es geht doch nur darum nicht doppelt zu verteilen, es geht nicht um die erzeugung von sich eh nie wiederholenen identifikationen.
Und jenachdem wieviele man einfach zusätzlich als benutzt angiebt bzw löscht hat man auch die unwarscheinlichkeit, das einer es rausfindet, welcher der keys in der reihe nun aktiviert sind etc, brute force ist eh immer möglich :smile:

Es liegt also an der erzeugung,in welcher reihenfolge man neue erzeugt ist egal solange eindeutig und nicht allzueinfach nachvollziehbar ,
wie man dann auswählt und es zufällig nicht aufsteigend zu organisieren ist damit beschieben.
Dabei muss ich am ende eigentlich nur immer wissen welchen keymenge ich schon erzeugt habe . Am ende brauch ich eigentlich nur die echten herrausgegebenen, alles andere (die lücken etc) brauch ich nicht speichern, da ich ja weiss in dieser menge hab ich schon den bestimmten raum erzeugt. Ich teil also die anzal aller in kleine gruppen, und speicher lediglich die gruppen ab und die genutzen keys, dabei hab ich dann genau eine gruppe aktiver daten wo ich randomisert einige rausgreife.

wenn ich allerdings schon mit zufall starte um zufall keys zu erzeugen dann wird es bei begrenzter menge immer schlimmer umsomehr keys produziert werden, ich denke meine methode wird dann fast immer gleich schnell und nicht zunehmend langsamer …

#12

Hallo

Dazu brauchst du doch keine Rekursion.

function erzeugezufallszahl()
{
while(indatabase($hash = rand("aaaaaa";"zzzzzz")));
return $hash;
}

Wenn es genügend freie Zufallszahlen gibt und deine rand-Funktion nicht einzelne Zahlen stark bevorzugt, dann wirst du schon nach wenigen Versuchen eine noch unbenutzte Zahl finden.

sigterm

#13

Hallo,

Wichtig ist nur das irgentwann einer die menge der
benutzen archiviert oder dank Logarythmus einfach nur
benutzte gelöscht werden

Wo hat sich denn der Algorithmus plötzlich in einen Logarythmus verwandelt?

Cheers, Felix

#14

um das mal mit Münchs beispiel zu sagen
(ich nehm hier zahlen anstatt buchstaben)

mein menge die menge der ganzzahlen

meine gruppen

  1. 5 stelligen zahlen 55555
  2. 6 stellige zahlen > 555555
  3. 6 stelige zahlen
#15

Hallo,

Wichtig ist nur das irgentwann einer die menge der
benutzen archiviert oder dank Logarythmus einfach nur
benutzte gelöscht werden

Wo hat sich denn der Algorithmus plötzlich in einen
Logarythmus verwandelt?

das man ne gute frage, ich glaub ich wollte ein logarythmus nehmen und die Ergenisse dann mit einem Algorithmus verteilen und verabeiten :smile:

ich glaub das meinte ich eigentlich … hihi (*schäm*)

ansonten korriegiere mich bitte , denn ich bring gerne mal wieder gutem wissen sachen einfach mal für ein paar stunden durcheinander :smile: Zum glück nur hier bei schnellantworten :smile:

Cheers, Felix

#16

das Beispiel war gerade echt genial!
Ich weiss nun, wie ich das bauen werde…
Und zwar werde ich eine rekursive Funktion basteln, die
ermittelt, ob dieser Schlüssel schon existent ist oder nicht.
Falls er das sein sollte, dann sucht er nochmal nach einem
freien Schlüssel - aber diesmal mit einer Stelle mehr…
Dadurch kann ich nun quasi mit einem dreistelligen String
beginnen und mit der unendlichkeit aufhören - und bin
immernoch sicher, dass es nie dazu kommen wird, dass die
rekursive Funktion ins leere rennt - und das beste dabei ist,
dass selbst nach millionen Datensätzen immernoch welche
rauskommen können, die kurz und knackig sind :smile:

a aber es kann schnell passieren das der kleine keyraum voll wird, und quasi jeder key ein gültiger ist, das erzeugt zwa einzigartigkeit aber damit eben keine sicherheit. Du musst irgentwann bestimmen wann ein bereich zuejnde genutz wurde und eben keine weiteren schlüsssel rausgegeben werden dürfen, da sonst jemand einafach irgentein klein stelligen schlüssel nimmt und der gültig ist.

wie gesagt, es kommt darauf an was in der theory abgesichert sein muss, braucht es keine sicherung ist dein algorithmus schnell einfach und effektiv :smile:)

#17

Leider ist mir nach dem Lesen der Antworten immer noch nicht ganz klar,
wozu der eindeutige Schlüssel nun dienen soll.
Aber warum sich irgendetwas ausdenken, was möglicherweise ernste Sicherheitslücken mit sich bringt, wenn es doch bereits gut etablierte und sichere Verfahren gibt die schon 10 Jahre lang als „bombensicher“ gelten.

Die Verwendung von einfachen Standard-Pseudozufallszahlen (mittels rand o.Ä.) ist weit weniger sicher als man denkt.
http://de.wikipedia.org/wiki/Kryptographisch_sichere…

Als „Möchtegern-Informatiker“, der sich auch nur marginal mit dem Thema auskennt, kann ich dir nur sehr empfehlen ausgereifte Einweg-Hash-Verfahren aus der Kryptographie zu verwenden.
Wie wärs denn mit SSH:
http://de.wikipedia.org/wiki/Sicherer_Hash-Algorithmus

Es gibt auch keinen Grund mit der Schlüssellänge zu geizen.
Denn mit wachsender Stellenanzahl erhöht sich die Anzahl der Möglichkeiten exponentiell.
Des Knacken solcher Verfahren gilt als sogenanntes (wie es Mathematiker/Informatiker sagen) „NP-Hartes Problem“.
Anders gesagt, es gibt keine effizienten Algorithmen für lange Schlüssel.
d.h. wenn z.B. angenommen ein 128Bit Schlüssel von einem Algorithmus in 1 min geknackt werden kann,
dann braucht das bereits 2 Minuten für 129Bit, 4 min für 130Bit und für 256Bit bereits über 6 * (10 hoch 32) Jahre!!!
Auf einen Eine-Milliarden(10 hoch 9) mal schnelleren Supercomputer hätte man auch nicht die geringste Chance und würde immer noch über 6 * (10 hoch 23) Jahre brauchen.
Wenn du überlegst, dass du für diese Sicherheit grade mal die doppelte Datenmenge brauchst ist das ein Witz.
Und die 256Bit sind immernoch winzig im Vergleich zu anderen Benutzerdaten die du so speichern und übertragen musst.
Du solltest den Schlüsselraum ruhig viel Größer wählen,
als dass es jemals Schlüssel für alle Menschen der Welt bräuchte.
Denn der Zusatzaufwand im Vergleich zur gewonnenen Sicherheit ist absolut ninimal und so kann niemand gültige Schlüssel durch „raten“ erhalten.

Es ist absolut unwahrscheinlich mit derartigen Verfahren 2 gleiche Schlüssel zu erzeugen und sollte eine Überprüfung darauf stattfinden, kannst du sicher sein dass diese so gut wie nie wiederholt werden muss.
(kein zusätzlicher Laufzeitaufwand)

Gruß
VoidZer0

#18

Hallo

Der Witz bei Tinyurl und ähnlichen Diensten besteht ja gerade darin, sehr kurze Schlüssel zu erzeugen.
http://de.wikipedia.org/wiki/Tinyurl

sigterm

#19

Ja ja genau so ist es und das hatte ich mir auch durchgelesen
aber wenn man sich die weiteren Antworten von MunichFreak
so durchliest, bekommmt man den Eindruck,
dass er eigentlich etwas ganz anderes möchte,
als das was TinyURL macht.

MunichFreak schrieb:
> ziemlich sicher zufällig - denn es wird sicher nicht
> aus dem Schlüssel zurückgerechnet werden können,
> wie dieser in lang aussehen würde…
> dazu erscheint mir die „Kompressionsrate“ zu hoch :wink:

> Aber mal angenommen man hätte 10 Fotos, Links,
> whatever von jedem Menschen und will diese mit
> einem eindeutigen string absichern, dann müsste
> man das ja irgendwie in der Art tun, nicht wahr?

Zusammengefasst:
Er möchte einen eindeutigen aber zufälligen Schlüssel (um z.B. Bilder „abzusuichern“) aus der nicht (z.B. aus Benutzernamen und Dateinamen) zurückgerechnet werden kann.

Nun hat TinyURL aber so kurze Schlüssel das keine Mühe macht,
gültige Schlüssel zu erraten und das ganze hat auch nicht
den Zweck etwas „abzusichern“, da es nur um kürzere URLs geht.

Wenn man nur sowas wie TinyURL will, könnte man auch einfach
Schlüssel nacheinander aufsteigendend vergeben oder
damit die Schlüssel zufällig wirken einfach auf diese Schlüssel ein „perfektes Hashing“ anwenden.
http://de.wikipedia.org/wiki/Perfekte_Hash-Funktion

Aber all das sichert die Daten nicht oder nicht zuverlässig vor Fremdzugriffen.

Das ist abhängig von der Frage was MunichFreak nun wirklich will?

Gruß
VoidZer0

#20

Hallo

Trotzdem halte ich 256 Bit für übertrieben.
Mit einem Bruteforce-Angriff auf ein PHP-Script werde ich nicht mal 1000 Versuche pro Sekunde schaffen. Und selbst dann bräuchte ich für 32 Bit immer noch 50 Tage, um alle Möglichkeiten durchzuprobieren.
Wenn man da noch 20 Bit für die Million Einträge, die man da speichern will, dazurechnet, sollte das doch locker ausreichen.

Und ist das mit den gewöhnlichen Zufallszahlen wirklich so bedenklich? Ich glaube nicht, dass man z.B. aus 10 bekannten 64-Bit-Codes in sinnvoller Zeit einen elften ermitteln kann.

Vielleicht wäre es aber ratsam, in das PHP-Script eine Bruteforce-Erkennung einzubauen.

sigterm