Servus (;
Ich habe ein Verschlüsselungsverfahren programmiert, was auf RandSeed und der damit verbundenen Zahlenreihe basiert. RandSeed wird durch ein Passwort ermittelt, deren Rechnung im Moment wiefolgt aussieht:



Count ist die Laufvariable - das ganze steht in einer for-do-to-Schleife.

Meine Frage lautet jetzt, ob jemand einen Vorschlag hat, die Errechnung des RandSeeds so schwer wie möglich zu machen und somit das Prog sicherer, vielleicht mit Wurzel oder so?
Wichtig ist eigentlich bloß, dass beim gleichen Passwort auch immer die gleiche Zahl für RandSeed ermittelt wird und, dass es eben möglichst schwer ist.

Gruß & thX for help ,
delphin

Solange das Verschlüsselungsverfahren bekannt ist, nützt diese Art der Verschlüsselung gar nichts,
da ich locker per Bruteforce alle Möglichkeiten von Low(RandSeed) bis High(RandSeed) durchprobieren kann.

Ja gut BruteForce kannste immer bringen...

Okay, wie du meinst. Verfeinere die RandSeed-Generation so wie du willst, gib mir den Verschlüsselungsquelltext und ich entschlüssele dir einen deutschen Text, mit einem beliebigen Passwort, innerhalb von 5 Minuten.

der witz ist ja, dass du den quelltext nicht haben wirst Oo Dazu kommt, dass du normalerweise selbst die information mit randseed etc nicht hast....
Aber bitte:



gL, hF

Es geht darum, dass man das Programm zum verschlüsseln hat -> debuggen oder einfach eingie sachen verschlüsseln.

Wie du hier zum Thema Verschlüsselung immer wieder finden kannst: Die Sicherheit eines Verfahrens DARF nicht auf der Geheimhaltung des Algorithmus basieren (da das unmöglich ist), sondern lediglich auf der Sicherheit des eingesetzten Passworts. Da dein Passwort immer genau EINE Zahl zwischen 0 und MaxInt ist, ist dein Verfahren ... naja ... von der Sicherheit her ganz weit unten ...

Das soll heißen? Müsste ich es in irgendeiner Form umschreiben oder ist das nicht möglich? Wie soll ein Passwort aussehen, das 'sicherer' ist?
Achja, gelöst hat es noch keiner

Benutze bitte die suche. Es wird hier keiner Versuchen das was du da gepostet hast zu entschlüsseln, aber für dich mach ich es mal:
Text: Delphi-Forum
Password: test

Und nu beweise mit mal, dass es nicht durch irgendeine Verschlüsselung möglich ist aus den beiden Daten oben genau das zu erzeugen was du unten als verschlüsseltene String stehen hast.

Gib mir das Programm, dann entschlüssel ich dir das...

uall@ogc hat folgendes geschrieben:

Und nu beweise mit mal, dass es nicht durch irgendeine Verschlüsselung möglich ist aus den beiden Daten oben genau das zu erzeugen was du unten als verschlüsseltene String stehen hast.

Das ist nicht der Sinn des Verschlüsselns, dir zu beweisen, dass das, was du geraten hast, falsch ist. Übrigens, wie überflüssigerweise zu erwähnen, es ist falsch.

Im Anhang die .exe und die .sec-Datei.

-delphin- hat folgendes geschrieben:

Das ist nicht der Sinn des Verschlüsselns, dir zu beweisen, dass das, was du geraten hast, falsch ist. Übrigens, wie überflüssigerweise zu erwähnen, es ist falsch.

Streng genommen ist genau das der Sinn der Kryptographie! Denn nur wenn du außschließen kannst, dass diese Lösung nicht die richtige Lösung ist, kannst du behaupten, dass dein Verfahren eindeutig ist! Alles andere wäre eh eine unsichere Verschlüsselung!

Letzlich wirst du mit Zufallszahlen die mit Delphi erzeugt werden wenig erreichen können! Denn du wirklich die Sicherheit steigern willst, dann solltest du einen Pseudozufallszahlengenerator mit diesen Zufallszahlen speisen! Bei einem solchen kannst du, wenn er gut ist (auch wenn ich bezweifel, dass du es schaffen wirst, weil sich daran momentan Genies die Köpfe einrennen), von Sicherheitsprechen!

Die Random()-Funktion von Delphi ist zwar auch ein solcher, doch hat er zu wenige Ausgangsituationen, die du mittels RandSeed festlegen kannst!

Soll heißen, wenn RandSeed bei Kommazahlen oder noch besser bei irrationalen Zahlen starten würde, wäre es sicher?

Wie bitte soll man ausschließen können, dass das nicht die Lösung ist? Gib mir 5 Minuten und man programmiert ein Programm, das genau das bei dem Quelltext zur Lösung hat...

-delphin- hat folgendes geschrieben:

Soll heißen, wenn RandSeed bei Kommazahlen oder noch besser bei irrationalen Zahlen starten würde, wäre es sicher?

Wenn dazu kommt, dass es bei jeder unterschiedlichen Zahl auch unterschiedliche Ergebnisse liefert würde ich sagen: JA, wobei ich eher "ja, es isch sicherer, als ohne" sagen würde.

Wenn Randseed 2^256 (weil es heute Standard ist) unterschidliche Startpositionen hätte und daraus unterschidliche Zufallsreihen liefern würde und diese nicht zurück- oder weiterrechenbar sind, dann wäre es schon sehr sehr gut!

Ich weiß nicht, ob die Idee sinvoll ist, aber:
Man könnte Ja ein Passwort, z.B. "Hallo", nehmen und den ANSI-Code von "H" als RandSeed verwenden, dann die "a"-te Zufallszahl errechnen, als RandSeed einsetzen, dann die "l"-te Zufallszahl und so weiter. Und wenn man das "o" auch hat, die nächste Randseed dann tatsächlich verwenden.

Silas

//EDIT: Das würde aber auch nur dann funktionieren, wenn der Code an sich nicht die Schwachstelle ist, sondern das PW

@Silas: Auch das ist nicht wirklich eine verbesserung der Sicherheit! RandSeed ist ein 32-Bit Integer, also verwendet man so zu sagen einen 32-Bit-Schlüssel. Wenn man den Start um n Stellen verschiebt, dann muss das um 2^32 Stellen sein, damit man einen 2^64-Bit-Schlüssel erhält... diese 2^32 Stellen durch zu laufen würde eine "Ewigkeit" dauern!

Durch das Verschieben um den ASCII-Wert, würde eine Verschiebung um 2^8 Stellen dabei heraus kommen! Das bedeutet man erhält einen 40-Bit-Schlüssel ... das ist immer noch nicht wirklich sinnvoll!

Eine verbessere Random()-Funktion ist hier zu finden! Die Zahl 134775813 kann variiren, sollte aber bestimmte Bedingungen erfüllen.

was soll das bringen, das randseed einfach mit 134775813 zu multiplizieren? oder hab ich das falsch verstanden?

Hallo,

leider habe ich da kaum Ahnung, aber vom reinen Anblick her, werden bei dem Zufallsgenerator nicht mehr Zufallszahlen erzeugt
Input 32 bit output 32 bit die wieder input werden.
Das sind also wieder nut 32-Bit Schlüssellänge.
Erzeuge doch einen MD-5 oder SHA-1 Hash aus deinem Paßwort und nimm immer 32 Bit Abschnitte als Randseed für einen Generator.
Bei MD-5 sind 128 Bit ja 4 x 32 Bit.
Du kannst jetzt 4 normale Generatoren laufen lassen wo bei die erzeugten Werte als XOR Schlüssel dienen. Vielleicht bestimmt Geneartor 1 zusätzlich, welche Permutation der neuen Ranseed's genommen werden soll.
Soll heißen: es gibt 4! Möglichkeiten welcher Generator X mit dem Ergrbnis von Generator Y als neuem Randseed gefüttert wird.
Das heisst , das die Generatoren fast ständig (bei 1 von 24 nicht) Ihre Position wechseln.

Gruß Horst

das habe ich nich verstanden und werde es wohl auch nie verstehen

Mal Abgesehen davon, dass es falsch war ...

Wenn ich 4 verschiedene Vignere-Verschlüsslungen nacheinander mit der gleichen Schlüssellänge ablaufen lasse, so ist die Länge des Gesamtschlüssels nicht 4 mal die Ausgangslänge, sondern gleich dem kgV der Ausgangsschlüssellängen ...

Um die Schlüssellänge stark zu verlängern müsstest Du 4 Zufallsgeneratoren haben, die alle eine prime Wiederholfrequenz haben, deren Periodizität 4 aufeinanderfolgende teilerfremde Zahlen sind.

d.h. Längen 2,4,8,16 = schlecht (Periode 16 = 2^4)
Längen 3,5,7,11 = besser. (Periode 1155 = 2^10,173677)

Fazit: Lass die Finger von, wenn Du nicht mal die Grundlagen der Kryptographie verstehst!

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Fazit: Lass die Finger von, wenn Du nicht mal die Grundlagen der Kryptographie verstehst!

Richitg. Es ist naiv, anzunehmen, daß man als Laie mal eben einen sichereren Algorithmus aus dem Ärmel schüttelt, wenn sich ganze Arbeitsgruppen von Mathematikern einige Jahre lang mit nur einem einzigen Verfahren beschäftigen.
delphin, nimm ein existierendes Kryptosystem, zum Beispiel DSA oder RSA. Beide sind um ein vielfaches sicherer als das, was jeder einzelne von uns hier in der Lage ist, sich auszudenken.