Verschlüsselung

[rüdiger]

die Verschlüsselung ist dann egal, weil jeder halbwegs geeignete Cracker wird den Key ohne Probleme aus deiner Anwendung auslesen und schon wars das.

[dEUs]

wenn ich das hab:

char chKey[2]; //Nur 2 weil ich grad n bissle Tippfaul bin :)
chKey[0]=34;
chKey[1]=19;

kann man das dann so einfach auslesen?

[Mr. IfThen]

@Mart

Ich benutze für mein Programm diese Blowfish-Verschlüsselung:

http://maakus.dyndns.org/software.html

Nennt sich BlowfishJ 2.11.

J, weil eigentlich für Java gedacht, gibt aber auch ne C++-Klasse für ECB und CBC.

[Mart]

ich habe es so gemacht
'a' ist glaube ich 65 ?? oder egal ist ja nur ein beispiel.
also 65 +5 =70

int offset = 5 ;

char chKey[2]; //Nur 2 weil ich grad n bissle Tippfaul bin :) 
chKey[0]=70-offset;//=a 
chKey[1]=19-offset;//=irgendwas

wie lest ihr dann das aus ???;-)
und wenn ja dann lass ich einfach meinen schlüssel dur ne mathe-funktion ausrechnen, das geht schon, und nix mit resourcen hacker

[rüdiger]

@dEUs
wo soll das Problem sein?

hier mal nen kleiner Beweis

> g++ -Wall -W -std=c++98 key.cc
> objdump -d a.out | less
[...]
08048364 <main>:
 8048364:       55                      push   %ebp
 8048365:       89 e5                   mov    %esp,%ebp
 8048367:       83 ec 08                sub    $0x8,%esp
 804836a:       83 e4 f0                and    $0xfffffff0,%esp
 804836d:       b8 00 00 00 00          mov    $0x0,%eax
 8048372:       29 c4                   sub    %eax,%esp
 8048374:       c6 45 fe 22             movb   $0x22,0xfffffffe(%ebp)
 8048378:       c6 45 ff 13             movb   $0x13,0xffffffff(%ebp)
[...]

die letzten Beiden Zuweisungen sind dein Schlüssel

ob wuerde das irgend wen vor ein Problem stellen und wenn du das Code Beispiel verkomplizierst, dann schaut man sich einfach mal dein Programm im Debugger an, dass sollte jeder können, der Halbwegs Ahnung von Reverse Enginering oder Cracken hat.

@Mart
dein Code stellt auch niemand vor Schwierigkeiten, vorallem wenn du Optimierung aktivierst und dein Compiler die Subtraktion einfach bei der Compile-Zeit auflöst.

[Walli]

Jo, dEUs Vorschlag kann noch etwas sicherer gemacht werden wenn man irgendwelche Befehle dazwischen streut. Hält den richtigen Freak aber auch nicht ab. Es gibt echt Leute die lesen dir Kurzgeschichten in Binärcode vor. Die hält sowas nicht wirklich ab...

[Cpp_Junky]

Wenn ich ne einfache Verschlüsselung brauche, verwende ich in etwa folgendes Prinzip:
Als Verschlüsselungs-Profil wird das Passwort genommen.
Also wenn ich den Text "AAAAA" mit dem Passwort "BCDEF" verschlüssel, sieht das so aus:

A + B (65 + 66 = 131) = â
A + C (65 + 67 = 132) = ...
usw

daraus ergibt sich dann eine kryptische meist gar nicht mehr lesbare Zeichenfolge. Wenn der errechnete AscII Wert eines Zeichens grösser 255 ist, muss man natürlich wieder bei 0 anfangen. Der Witz an der Sache ist, das die Verschlüsselung völlig abhängig vom Passwort ist. Selbst wenn der böse Hacker den Algorithmus kennt, kann er ohne Passwort nicht an die Daten. Man kann es nur per Brute-Force knacken. Und da es keinen Validity-Check gibt, müsste der böse Bub jedes Passwort durchprobieren und anschliessend das Ergebniss begutachten

[dEUs]

coole Idee. Allerdings auch nur sicher, wenn das passwort net im programm steht

[rüdiger]

nicht schon wieder so eine One-Time-Pad geschichte, dass diese in der Praxis nicht nur unpraktisch, sondern auch idr. leicht zu brechen sind, sollte einem doch mittlerweile klar sein. Die Theorie bringt doch nichts, wenn man das System nicht wirklich praktisch umsetzen kann.

[dEUs]

Kannst du das mal etwas mehr ausführen?

[Cpp_Junky]

dEUs schrieb:

coole Idee. Allerdings auch nur sicher, wenn das passwort net im programm steht

Warum sollte das Passwort im Programm stehen ?

nicht schon wieder so eine One-Time-Pad geschichte, dass diese in der Praxis nicht nur unpraktisch, sondern auch idr. leicht zu brechen sind, sollte einem doch mittlerweile klar sein. Die Theorie bringt doch nichts, wenn man das System nicht wirklich praktisch umsetzen kann.

Ist genauso "leicht" zu knacken wie jede andere gängige Verschlüsselung.
Ohne den Aufwand von Bruteforce nichts zu machen.
Das Problem ist nur, das beide Seiten den Schlüssel kennen müssen da sie diesen zum Entschlüsseln der Daten brauchen (logisch oder ? :p )
Und wenn jemand das falsche Passwort eingibt, bekommt er nur Datenmüll

[*aleph_0]

One-Time-Pad ist genau dann absolut sicher, wenn die Schlüssellänge gleich der Textlänge ist und der Schlüssel absolut zufällig. Daher muss man für jede Nachricht vorher einen neuen Schlüssel mit diesen Eigenschaften übertragen, d.h. ohne besondere Hilfsmittel ("Quantenkryptographie") scheitert diese Methode am Problem der Schlüsselverteilung.

[Sgt. Nukem]

\aleph_0 schrieb:

ist genau dann absolut sicher

Nada.

Jemand könnte den Schlüssel ja auch zufällig durch Kotzen auf die Tastatur eingeben... :p

[*aleph_0]

Sgt. Nukem schrieb:

Jemand könnte den Schlüssel ja auch zufällig durch Kotzen auf die Tastatur eingeben... :p

Er weiß dann aber nicht, dass er den Schlüssel gefunden hat, d.h. man kann dabei nicht von "Entschlüsseln" reden.

[Cpp_Junky]

Warum muss der Schlüssel denn Textlänge haben ?
Ein Passwort mit min. 8 Zeichen das immerfort auf den Text angewendet wird sollte doch ausreichen. Zum Thema Passwort nur einmal:
Man könnte eine riesenlange Liste zufälliger Schlüssel generieren. Diese bekommen Absender und Empfänger. Die Liste wird dann von oben nach unten durchgearbeitet. Bei jeder Verschlüsselung ein anderer Key.
So in der Art von TAN's bei Online-Banking.
Sollte doch ziemlich sicher sein dann.

[Sgt. Nukem]

\aleph_0 schrieb:

Sgt. Nukem schrieb:

Jemand könnte den Schlüssel ja auch zufällig durch Kotzen auf die Tastatur eingeben... :p

Er weiß dann aber nicht, dass er den Schlüssel gefunden hat, d.h. man kann dabei nicht von "Entschlüsseln" reden.

Doch, wenn das Endergebnis stimmt und er 'nen KeyLogger laufen ließ...

[EDIT] Is' vielleicht sogar effektiver als BruteForce demnächst... [/EDIT]

[rüdiger]

Ein Passwort mit min. 8 Zeichen das immerfort auf den Text angewendet wird sollte doch ausreichen.

Nein, dann kann man die Verschluesselung sehr leicht knacken, weil man eine natuerliche Wiederholung hat. Deswegen darf man auch nie den gleichen Schluessel 2 mal fuer ein One-Time-Pad benutzen!

So hat die NSA Anfang der 50er Jahre einige russischen Spione enttarnt, weil die UdSSR nicht ueber genug Kapazitaeten verfuegte, so viele Schluessel zu produzieren, deshalb wurden verschiedenen Agenten Schluessel gegeben, die schon mal benutzt wurden und der NSA hat schoen alle Dokumente gesammelt und verglichen und irgend wann fanden die eben ein paar doppelte Schluessel. Naja, dass hat einigen Agenten das Leben gekostet!

Man könnte eine riesenlange Liste zufälliger Schlüssel generieren. Diese bekommen Absender und Empfänger. Die Liste wird dann von oben nach unten durchgearbeitet. Bei jeder Verschlüsselung ein anderer Key.
So in der Art von TAN's bei Online-Banking.
Sollte doch ziemlich sicher sein dann.

So sollte das ja sein, dass Problem, was sich eben ergibt, beim One-Time-Pad

a) man braucht eine gute Zufallsquelle, gerade ueber schlechte Zufallsquellen kann man leicht die Schluessel knacken! Vorallem wildes auf der Tastatur rumhacken, scheint gar nicht so Zufaellig zu sein, wie man glaubt, vorallem wenn man beachtet, wie viel Zeichen man nur auf der Tastatur hat.

b) man muss den Schluessel Sicher verstauen, was auch eine der schwersten Aufgaben ist

c) man muss den Schluessel austauschen und das auch noch Sicher machen. Also wenn man den Schluessel mit einer anderen Verschluesselung verschluesselt und dann verschickt, reduziert man die Sicherheit eines One-Time-Pads schonmal direkt auf die Sicherheit, des Algorithmus, mit dem die Schluessel verschickt werden (dann lohnt sich der Ganze Aufwand dafuer auch nicht mehr).

One-Time-Pad ist natuerlich von der Theorie das beste, aber in der Praxis laesst sich das One-Time-Pad idr. leicht angreifen.

[prolog]

Tag,

Öhm geht es jetzt überhaupt noch um das Ausgangsproblem ?

Kingruedi hat schon recht, wenn er sagt dass das One-Time-Pad, obwohl theorethisch mathematisch beweisbar sicher(blöd ausgedrückt, auch praktisch mathematisch beweisbar natürlich), in der praxis schwer durchführbar ist.

Also bleiben bekannte symmetrische Verschlüsselungen.
Also ich benutze folgende Methode.
Ich speichere Passworte oder gegebenenfalls Username und Passwort ala unix in einer Datei wobei ich das Passwort mit einer Einwegfunktion verschlüssele.

Dies ist nur dazu da zu prüfen ob das Passwort korrekt ist bevor ich anfange die eigentlichen Daten zu entschlüsseln. Stimmt das Passwort wird es benutzt die Daten mit IDEA,Blowfish,CAST,AES oder was auch immer zu ver-bzw. entschlüsseln.

Einziges Problem hierbei ist dass die Integrität deiner Daten von der Einwegfunktion abhängt (leider). Also dafür solltest du eine starke Cryptographische Funktion wählen. Ja und selbst implementieren ist in der Regel nicht nötig da es entsprechende Bibliotheken gibt.

google ist dein Freund *gg*

[*aleph_0]

...und wenn eine Nachricht von A an B, die keinen geheimen Schlüssel austauschen können/wollen, versendet werden soll, wählt A einen zufälligen Schlüssel, verschlüsselt mit einem symmetrischen Verfahren wie AES den Text und mit einem asymmetrischen Verfahren wie RSA den zufälligen Schlüssel und sendet beides an B.

[MArt]

das mir rsa den symetrischen schlüssel tauschen geht nicht weil b niemals antwortet, sondern nur A sendet.

ich dachte mir einfach einen pseudo-key mit dem man durch hilfe von hash-funktionen/math-funktionen einen neuen key generiert.
Aber am ende ist nie was sicher weil alles im speicher stehen muss, und der ist immmer(windows) auslessbar, durch "remotethread", aslo ist auch kein putty sicher weil der key auch imm speicher steht oder?da hilft putty auch kein ssh.

hier gehts ja nicht um e-commerce, sondern um ne private anwendung, und lern effekt.