Neues Verschlüsselungsprogramm (selbst gecodet)

Hi, Seth, irgendwie bringst Du symmetrisches und asymmetriches Krypto durcheinander !! :-P

Tecs Proggy ist 1A!
Ich würde darauf aufbauen.
Seine Passwortroutine und die Zufallszahlenerzeugung sind doch nicht schlecht!
Es sollte aber mit dem erzeugten Schlüssel nicht direkt verschlüsselt werden!
Dieser sollte nämlich als Samen für einen weiteren Zufallsgenerator eingesetzt werden, der dann für den Plaintext ein On - Time - Pad bildet!
Zeig mir den Hobbycryptografen, der dies dann noch crackt !! :-P

Golgotha
 
1.)
Zeig mir den Hobbycryptografen, der dies dann noch crackt !! :-P

OTP-verschlüsselte Daten sind bei Einhaltung der Regeln ohne Kenntnis des Schlüssels nicht zu entschlüsseln.

Das OTP-Verfahren ist das einzige Verschlüsselungsverfahren, das auch theoretisch unknackbar ist.


2.) Das OTP-Verfahren ist auch für Home-Use unpraktisch, da für jeden zu verschlüsselnden Text ein neuer Schlüssel benötigt wird. Man stelle sich vor, man müsste für jede E-Mail auf zweitem Wege noch einen Schlüssel liefern ...


3.) Mit OTP lässt sich alles sicher verschlüsseln, und das Verfahren ist einfach und leicht nachzuvollziehen.
Das Problem liegt in seiner Unhandlichkeit.


4.) Weitergehende "geheime" programminterne Verschlüsselungen bringen überhaupt nichts, jeder fähige Reverser kann "geheime" Algorithmen und Schlüssel in Programmen aufdecken. Von daher liegt die wirkliche Wirkung solcher Algorithmen bei null.


5.) Will man sich mit unzähligen Riesenschlüsseln herumschlagen, ist das Programm erste Wahl, dafür sicher, wenn die Schlüssellänge der Textlänge entspricht. Ansonsten sollte man sich anderen Kryptovarianten zuwenden.
 
----
Hi, Seth, irgendwie bringst Du symmetrisches und asymmetriches Krypto durcheinander !! :-P

noe..
deswegen ja durch rsa schicken..
--------

btw..golgotha..wo bleibt der code ? :)

--------

-----
4.) Weitergehende "geheime" programminterne Verschlüsselungen bringen überhaupt nichts, jeder fähige Reverser kann "geheime" Algorithmen und Schlüssel in Programmen aufdecken. Von daher liegt die wirkliche Wirkung solcher Algorithmen bei null.


alle algos populaerer kryptotechniken sind bekannt...
bei RSA zb liegt die sicherheit nicht im algo sonder bei der Tatsache dasz
es heutzutage praktisch nicht moeglich ist keys einer bestimmten groesse zu faktorisieren...
Mit steigender LEistung der REchner und der optimierung von algos die eine solche faktorisierung durchfuehren minimiert sich auch die sicherheit..



:wq!
 
Ich habe diesen Thread nur fast, aber nicht ganz vollständig durchgelesen und habe auch eine mögliche Theorie von verschlüsselung:
Meine Theorie wäre es, wenn ich 2 CD-ROMS brennen würde mit den gleichen Daten: 700 MB voll Schlüssel ;) und eine CD-ROM mein Partner gebe.

Die Verschlüsselung geht z.B: mit:
for (i=0;i<buflen;i++) {encoded=(buffer+key[i+startpos])&0xFF}

wobei der Schlüssel nur einmal benutzt wird.
Jeder hat 350 MB, womit er nur sendet und der andere empfängt und 350 MB, womit er nur empfängt und der andere sendet.

Wenn der Schlüssel aufgebraucht ist, wird eine neue CD gebrannt und die Personen müssen sich im realen Leben wieder treffen ...

Was haltet ihr von dieser Idee ?
 
Zeichen 1 + Schlüssel 1 ab pos x = Enkodiert 1
Zeichen 2 + Schlüssel 2 ab pos x = Enkodiert 2


Brief 1:
Schlüssel: WRJKLJKLWHRLJWRHJKLHJKRLLHJKRRHRHHRW...
Text.....: DIES.IST.EIN.TEST...................
Kodiert..: ??￾žz?ž ?￾?šx???ž...................

Brief 2.
Schlüssel: WRJKLJKLWHRLJWRHJKLHJKRLLHJKRRHRHHRW...
Text.....: ...................NOCH.EIN.TEST....
Kodiert..: ...................??Žšz???y????....



Die Zeichen a wird einfach mit Schlüssel b addiert, wobei der Text nur ein Teil des Schlüssels nimmt
 
Ganz abgesehen, dass isch statt einer Modulo - Addition ein bitweises XOR vorziehen würde ---

Meinst Du wirklich, dass zwei On-time pads sicherer sind als eins??


*g*
 
Ist doch egal, ob Add, Sub, Xor oder sonstwas, war eine Demonstration :D

Und mit dem 2 On-time pads da habe ich mich verschrieben, sorry - ich meinte
Schlüssel an pos x
Schlüssel an pos x+1

Wollte sagen, das z.B. mit 100 MB Schlüssel theoretisch jeder 50 MB verschlüsselte Daten verschicken könnte, die man nicht knacken kann
 
Ts,ts ...

Wollte sagen, das z.B. mit 100 MB Schlüssel theoretisch jeder 50 MB verschlüsselte Daten verschicken könnte, die man nicht knacken kann

Und ich behaupte sogar, das dies auch praktisch geht, aber der Crux mit der Schlüsselverteilung
ist dann immer noch nicht gelöst.
 
Original von Golgotha
Ts,ts ...

Und ich behaupte sogar, das dies auch praktisch geht, aber der Crux mit der Schlüsselverteilung
ist dann immer noch nicht gelöst.

Ich habe mich ein bischen (zu) vorsichtig ausgedrückt, was ist, wenn jemand via Trojaner an den Schlüssel kommt ? Wenn du das so siehst (Trojaner nicht mitzählen), bin ich auch der Meinung, man könnte das wirklich nicht knacken.
 
Code ist sehr einfach knappbar

Hi,

ich bin weis Gott (bzw. weiß er auch nicht) kein Kryptologe (oder wie die Leute heißen), allerdings sehe ich auf Anhieb ein Problem in deinem Verfahren.

1. Alle Wörter wurden mit dem gleichen Schlüssel verschlüsselt. Das führt dazu, das wenn sich jemand der Lust dazu hat, einfach guckt, welche Zahlnefolge kommt den besonders oft vor? Diese Zahlenfolge ist mit annähernder Sicherheit der Buchstabe e. Wenn man dann alle e entschlüsseln kann, kann man ganz einfach die Wörter erraten und den Schlüssel brechen.

2. Dein Schlüssell übersetzt die Zeichen eines Zeichenvorrats (ASCII) 1:1 in die eines anderen Zeichenvorrats (also deeinen Schlüssel). Ich meine damit, ein Buchstabe/Zeichen entspricht identisch einem Zeichen/Zahl im verschlüsseltem Zustand. Das erleichtert Punkt 1. Hinzu kommt dadurch, dass man via Wörterbuch-Attacke einfach durchprobieren kann, welche Wörter in Betracht kommen, da man ja die Länge des Textes heraus bekommen kann. Dann guckt man einfach welche Wortfolge macht in deisem Fall WSinn und hat dann den Schlüssel gebrochen.

Da man weiß wie dein Code funktioniert (im übrigen weiß man das bei allen guten Codes, daher weiß man dann auch wie sicher er ist), also der ASCI-Zeichen-Code + eine Zufallszahl genutzt wird, kan man auch einen Computer einfach so lange durchprobieren lassen (in dem er einfach versucht zu erraten, mit welcher Zahl verschlüsselt wurde) bis sinnvolle Wörter herauskommen und dann prüfen ob die Wörter einen sinnvollen Satz darstellen.

Ich würde mir glatt die Arbeit mmachen und versuchen deinen Code zu knacken, leider habe ich im Moment wenig Zeit :) (gute Ausrede). Ich werde es zu einem späteren Zeitpunkt mal versuchen.

Auf jeden Fall, ist es aber besser als gar keine Verschlüsselung.

Mit freundlichen Grüßen

Mailerdemon
 
Hallo,
@ 1. Post:
Also wenn der Key genausolang ist wie der Text, dann ist er unknackbar, sofern der Key wirklich zufällig ist, und nicht nur Pseudozufall.

Aber sagen wir mal ich möchte ein Referat von 10 000 Zeichen verschlüsseln. Da benutze ich bestimmt keinen Key von 5000, denn den kann ich mir ja gar nicht merken im Kopf, und Aufschreiben ist mir zu unsicher, also benutze ich einen Key von 10 Zeichen.

Das ergibt eine Keywiederholung von 1000.

Per PC kann man ganz einfach (per Autokorrelation) die länge des PW's herrausfinden.
Gut ich weiß jetzt dass das PW 10 Zeichen lang ist.

Dann schreibe ich mir von den 10 000 Wörter jedes 10. Zeichen herraus, und führe dort eine Häufigkeitsanalyse durch, denn jedes 10. Zeichen wurde mit dem gleichem Key Zeichen verschlüsselt.

Jetzt kenn ich den häufigsten Buchstaben, rechne mir aus was für eine Verschiebung das bis nach E ist, und schon habe ich den 1. Buchstaben meines Key.
Das mache ich 10 mal, und schon hab ich den Key.


Ich habe als Beispiel einen 1300 Langen Text mit einem Zufälligem 100 Zeichen langen Zufallskey verschlüsselt.

Der PC hat unter 1 Sekunde gebraucht und ich hatte den Key, bis auf 1 Buchstaben richtig!
 
*** RESPEKT ***


Und jetzt sollte ein Cyberdieb in der städtischen Bibliothek folgende
Abenteuerromane stehlen:

1). Simon Singh
Fermats letzter Satz
ISBN 3-423-33052-x

2). Nicholas Rescher
GLÜCK
Die Chancen des Zufalls
ISBN 3-8270-0202-8



Golgotha.
 
@elderan
hast du die routine/programme selber gecodet?


bin gerade dabei mir sowas ähliches zu erstellen. bis jetzt ist es nur eine simple häufigkeitsanalyse (hab ja auch heute erst angefangen *G)
aber so beginnen bei mir alle sachen :P
 
Hallo,
ne, habe CrypTool benutzt.

Aber das kann man auch per Hand ganz einfach machen, dauert nur etwas länger.

So wie er das gemacht hat, gibts noch einen Bug dadrin, glaub ich.

Und zwar wird dort alles verschlüsselt, also auch leerzeichen. Dieses Leerzeichen hat den ASCII Wert von 32 und ist somit eigentlich der kleinste Wert im Text.

Wenn das PW jetzt 10 stellen hat, schreibt man sich jeden 10. wert auf.

Dort fällt dann sehr oft ein besonders kleiner Wert auf (andere Buchstaben haben ASCII Werte von 1xx).
Wenn man von diesem kleinem Wert 32 abzieht, hat man den ASCII Wert für den 1. Buchstaben des Key.

Sowas kann man selbst per Hand in 10 Min machen
 
Das Prog was Tec da gecodet hat basiert auf einen prinzip ähnlich wie RSA (Buch: Simon Singh - Geheime Botschaften ab S. 295).
Nur der RSA Algorithmus basiert auf Primzahlen die miteinander multipliziert werden und nicht addiert wie bei Tecs Prog.

Die Verschlüsselung hier ist wie Elderan schon gesagt hat mit etwas zeit und durchhaltevermögen leicht zu knacken.
 
Mal was zum Thema Key:
Ein Key ist einmalig. Das Ergebnis was mithilfe von Ihm erzeugt wird, ist es auch.

Das Problem ist, der Key ist homogen. D.h. er produziert an gegebener Stelle immer die gleichen Werte.

Bsp.

Heute ist ein schöner Tag.
Heute ist ein besonders schöner Tag.

Würde ich glatt tippen, die ersten 3 Zahlen sollten gleich sein. Wenn nicht, kannst Du nicht gewährleisten, dass der der die Nachricht erhällt, diese ohne den neuen Key entschlüsseln kann. Somit hast Du das Problem des sicheren Transfers des Keys.
Wenn ein gleichbleibender Key existiert, dann sollte dein Verschlüsselungsalgorithmus eine morphische Eigenschaft haben.
Verschieden Techniken zum Verschlüsseln, aber in unterschiedlicher Reihenfolge angewandt. Allerdings sollte das Programm aus dem Code immer noch den Rückweg erkennen können, wann welches Rückvershlüsselungsverfahren anzuwenden ist.
Falls Dein Programm nur eine Chiffre macht, ist es sehr wohl knackbar.
Die NSA selber loggt jeden Text mit und errechnet Dir vielleicht mit 300 Textbeispipelen den Code bis zum längsten Satz und deren Länge-2.
Aber gut ist es, wenn man sich in der Entwicklung von Cryptotools beteiligt.
Offenlegen sollte man den Code vielleicht nicht, aber die Verfahren kann man ja offenlegen. Wenn schon die einzelnen Verschluesselungsverfahren nich mal sicher sind, ist auch das Tool nicht grad sicher.

ma mein Statement dazu ...

cromatic
 
Ich weiß, ich antworte erst ungefähr 5 Jahre später, aber was solls:

1. Ist dein Algorithmus schon deshalb kryptografisch nicht wertvoll, weil ein Teil davon geheimgehalten werden soll.

2. Kennst du den XECryption Algorithmus?Er addiert auch den Schlüssel zu den Buchstaben.
Ich habe ein Programm geschrieben, das diesen Algorthmus in weniger als 1 Sekunde bricht.

3.Ist es nett, das du so überzeugt von deinem Algorithmus bist, aber mit deiner Wortwahl ("unknackbar", "versucht es doch mal, ihr werdet es nicht schaffen" usw.) klingst du fast ein wenig arrogant ^^.

4.Wenn du einen wirklich guten Algorithmus machen willst, dann lies so viel du kannst über Kryptografie, und dann beginne einen Algorithmus zu schreiben.

Nicht jetzt persönlich nehmen, aber das musste einfach mal gesagt werden.

MfG, pi()
 
Zurück
Oben