Ende der asymmetrischen Verschlüsselung?

[m.fuchs]

Dieser Vorgang ist bewusst "willkürlich" und unterliegt keinen mathematischen Algorithmen,so dass sie auch nicht "berechnet" werden können.

Und wie wird dieser Vorgang in der Praxis umgesetzt?

[Aliobaba]

... wie gesagt: Ausgesprochen "unelegant"!

Man hat einen z.B. mit GPG-verschlüsselten Text (in ASCII-Format) und "schickt" diesen durch ein Programm, das z.B. den eingangs aufgeführten Code enthält.
Der Empfänger braucht auch dieses Programm(!), "schickt" das File erneut durch dieses Programm und entschlüsselt das Resultat dann "ganz normal" mit GPG.
Dies geht natürlich programmgesteuert "in einem Rutsch".

Mir ist klar, dass das Code-Beispiel noch stark verbesserungswürdig ist! So sollten keine "goto"-Sprünge verwendet werden, globale Variablen sind "ganz mies". Auch könnte man die Zeilen, bei denen Buchstaben vertauscht werden per übergebener Variable frei wählen lassen usw. usw.

Ich habe z.B. mit diesem Programm einen "Code-Wort-Tresor" geschrieben, der diese Prozedur enthält. Dabei wird GPG-verschlüsselt mit:
1. einem Passwort,
2. Einer per Maus einzugebender Zahlenfolge (PIN)
3. einer Schlüsseldatei
4. und schließlich mit obiger Prozedur

Funktioniert seit 1 Jahr prima! Soll sie nur kommen die "NSA" mit ihrem popeligen Quantenrechner .....

Aliobaba

[Aliobaba]

Sollte jemand Interesse haben, sh. Anhang. Funktioniert seit fast 1 Jahr zuverlässig; trotzdem könnte man noch so einiges "eleganter" programmieren.
Aber wie's halt so geht: Man gewöhnt sich an "Provisorien", wenn sie gut laufen....
(Allerdings vorerst "nur"für Linux64Bit kompiliert)

[m.fuchs]

... wie gesagt: Ausgesprochen "unelegant"!

Man hat einen z.B. mit GPG-verschlüsselten Text (in ASCII-Format) und "schickt" diesen durch ein Programm, das z.B. den eingangs aufgeführten Code enthält.
Der Empfänger braucht auch dieses Programm(!), "schickt" das File erneut durch dieses Programm und entschlüsselt das Resultat dann "ganz normal" mit GPG.
Dies geht natürlich programmgesteuert "in einem Rutsch".

Aha, also ist es nicht willkürlich sondern wird automatisiert durchgeführt.

[AndreasMR]

Hallo zusammen,

da habe ich doch glatt was vergessen:

seit über 30 Jahren nutze ich bei Verschlüsselungen selbst ersonnene Algorithmen, bei denen der Schlüssel nach jedem verschlüsselten Zeichen in Abhängigkeit vom letzten Schlüssel, dem zu verschlüsselnden Zeichen und dem erhaltenen verschlüsselten Zeichen UND einer Zufallszahl neu berechnet wird.

Diese Zufallszahl wird meines Wissens in jeder Programmiersprache nach einem anderen Algorithmus berechnet und ist (bei Verwendung des gleichen Ausgangswertes) reproduzierbar. Und muss dies auch sein, da für die Entschlüsselung die gleiche Folge von Zufallszahlen erforderlich ist.
Dies führt dann auch dazu, dass Verschlüsselung und Entschlüsselungsroutinen in der gleichen Programmiersprache geschrieben werden müssen. Somit sind einer Entschlüsselung durch Unbefugte noch größere Hürden gesetzt. Ohne Kenntnis der bei der Verschlüsselung eingesetzten Programmiersprache, ohne Kenntnis des Startwertes für den Zufallszahlengenerator kann kein Computersystem die erforderlcihe identische Zufallszahlenfolge generieren.

Der Startwert für den Zufallszahlengenerator ist beispielsweise eine Funktion aus Dateilänge, Erstelldatum und -uhrzeit der zu verschlüsselnden Datei. Nach Abschluss der Verschlüsselung werden die Dateiattribute auf identische Werte gesetzt. Somit stehen die gleichen Informationen auf der Seite der Entschlüsselung ebenso bereit.

Beste Grüße

Andreas

[Warf]

Sollte jemand Interesse haben, sh. Anhang. Funktioniert seit fast 1 Jahr zuverlässig; trotzdem könnte man noch so einiges "eleganter" programmieren.
Aber wie's halt so geht: Man gewöhnt sich an "Provisorien", wenn sie gut laufen....
(Allerdings vorerst "nur"für Linux64Bit kompiliert)

Wenn du eine fundierte Meinung haben willst musst du schon den Source rausrücken, ich denke hier hat keiner Lust das Programm zu reverese Engeneeren, potentielle Angreifer würden das allerdings tun, damit hat dein Algorithmus durch das geheim bleiben keinen Sicherheitsvorteil.
Und du verwendest 3 Schlüssel, das ist zwar schön und gut allerdings macht das den Algorithmus allerdings nicht sicherer, wenn der Algorithmus eine Schwachstelle hat sind 3 Schlüssel genauso wenig ein Problem wie 1 Schlüssel.

Außerdem bieten die meisten Synchronen Verschlüsselungen keine erhöhte Sicherheit beim stumpfen mehrfach verschlüsseln, ein Beispiel ist DES, das Problem bei DES ist, das die Schlüssellänge mit 56 Bit ein wenig knapp bemessen, darum wird DES oft mehrfach, in form von Tripple DES verwendet. Das stumpfe hintereinanderschalten von DES würde allerdings keinen Sicherheitsvorteil bringen (da dies letztlich nur der einfachen Verschlüsselung mit einem anderen Schlüssel entspricht), was also gemacht wird ist zunächst mit Schlüssel 1 verschlüsselt, dann mit Schlüssel 2 entschlüsselt, damit Schlüssel 3 wieder Verschlüsselt. Es lässt sich Analytisch zeigen, das das effektiv der Sicherheit einer Verschlüsselung mit einem 3 mal so langem Schlüssel entspricht. Ob das auf dein PGP auch zutrifft kann ich nicht sagen, da PGP zu viele Algorithmen kombiniert, von denen ich schlicht weg nicht genug weis. Allerdings gilt die Faustregel: Doppelt verschlüsseln nützt kaum (zumindest bei naivem Ansatz, einfach nochmal mit anderem Passwort drauf zu ballern)

Außerdem glaube ich, dass in diesem Forum niemand das nötige Know How und die Ressourcen hat um einen solchen Algorithmus auf herz und Nieren zu testen (Krypto Experten sind relativ rar). Aber wie ich bereits sagte, du könntest dein Glück eventuell beim CCC versuchen.

Hallo zusammen,

da habe ich doch glatt was vergessen:

seit über 30 Jahren nutze ich bei Verschlüsselungen selbst ersonnene Algorithmen, bei denen der Schlüssel nach jedem verschlüsselten Zeichen in Abhängigkeit vom letzten Schlüssel, dem zu verschlüsselnden Zeichen und dem erhaltenen verschlüsselten Zeichen UND einer Zufallszahl neu berechnet wird.

Diese Zufallszahl wird meines Wissens in jeder Programmiersprache nach einem anderen Algorithmus berechnet und ist (bei Verwendung des gleichen Ausgangswertes) reproduzierbar. Und muss dies auch sein, da für die Entschlüsselung die gleiche Folge von Zufallszahlen erforderlich ist.
Dies führt dann auch dazu, dass Verschlüsselung und Entschlüsselungsroutinen in der gleichen Programmiersprache geschrieben werden müssen. Somit sind einer Entschlüsselung durch Unbefugte noch größere Hürden gesetzt. Ohne Kenntnis der bei der Verschlüsselung eingesetzten Programmiersprache, ohne Kenntnis des Startwertes für den Zufallszahlengenerator kann kein Computersystem die erforderlcihe identische Zufallszahlenfolge generieren.

Der Startwert für den Zufallszahlengenerator ist beispielsweise eine Funktion aus Dateilänge, Erstelldatum und -uhrzeit der zu verschlüsselnden Datei. Nach Abschluss der Verschlüsselung werden die Dateiattribute auf identische Werte gesetzt. Somit stehen die gleichen Informationen auf der Seite der Entschlüsselung ebenso bereit.

Beste Grüße

Andreas

Welchen Zufallszahlen Algorithmus verwendest du? Die OpenSSL hatte mal die gravierende Sicherheitslücke einen Standard Algorithmus zu verwenden, womit die Zufallszahlen analytisch berechnet werden konnten, und somit der komplette Schlüsseltausch für die Katz war. Wenn du einfach Random verwendest, oder irgendeinen Standard Algorithmus ist dein Algorithmus genauso sicher als würdest du ohne diese Zahl arbeiten, am besten verwendest du die Funktionen aus der OpenSSL zum generieren der Zufallszahl.

Noch dazu, wenn die Zufallszahl ein normaler Integer ist macht das für einen Supercomputer auch nur einen Unterschied von höchstens Sekunden, nimm am besten eine 1024-2048 Bit Zufallszahl.


Und ich möchte nochmal erwähnen, nutzt lieber andere Algorithmen wie Rijandael, Rijandael ist super schnell, und sicher. Seit 2001 wird nach Sicherheitslücken von Rijandael geforscht, und keine wurde bisher gefunden. Und wenn ihr denkt das euer Algorithmus eventuell genauso gut ist, lasst euch das mal durch den Kopf gehen. Als NIST ankündigte, sie würden nach dem nächsten Verschlüsselungsstandard suchen wurden, von Kryptoexperten auf der gesamten Welt Hunderte von Algorithmen eingereicht, aufgrund von Sicherheitsmängeln nur 15 übrig blieben. Und von diesen 15 Algorithmen war Rijandael der beste, der alle Anforderungen (Schnell, Sicher, Anpassbar, etc.) am besten erfüllte.
Und nun stellt euch die Frage, glaubt ihr wirklich ihr wärt unter den 15 von hunderten die überhaupt sicher sind? Und selbst wenn, dann ist Rijandael sehr wahrscheinlich immer noch besser. Von dem statistischen Standpunkt aus haben eure Algorithmen keine Chance.
Und ich möchte jetzt weder auf euch noch euren Algorithmen rumhacken, es geht mir nur darum dass ihr realistisch bleibt, und lieber eure Sicherheit auf Expertenmeinungen verlasst, da Sicherheitslücken entstehen können, wo man es als Laie kaum erwartet