3. Verschlüsselung

Verschlüsselung

  • *

    mart schrieb:

    was soll RSH ein?
    meinst du rsa ??

    Scheinbar.RSA ist aber nur leicht zu implementieren, wenn man eine Bibliothek für Langzahlarithmetik hat.

    Korbinian schrieb:

    wenn du nur plain text verwendest, und die sicherheit nicht so groß sein muss, kannst ja auch base64 (oder wie die html-verschlüsselung heist) nehmen, die verkürzt automatisch den text.

    Base64 ist keine Verschlüsselung, sondern nur eine Kodierung (oder wie man es nennt). Man hat dadurch keine Sicherheit, weil der "verschlüsselte" Text nicht von einem Schlüssel abhängig ist. Zudem vergrößert sich die Ausgabelänge auf ca. 4/3 (?) der Eingabelänge.

    0
  • ?

    http://kvirc.firenze.linux.it/cgi-bin/pragma.cgi?view=code

    ganz unten

    0
  • R

    libgcrypt funktioniert auch unter Windows, schau dir mal die Manuals an.

    base64 dient dazu 8Bit Zeichensätze auf 7Bit Zeichen (ASCII) zu mappen

    0
  • D

    Wie sicher ist die CRijndael-Verschlüsselung, wenn man den Key fest ins Programm einbaut aber so, dass man ihn net mit nem Resourceneditor auslesen kann?

    0
  • R

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

    0
  • D

    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?

    0
  • M

    @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.

    0
  • ?

    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

    0
  • R

    @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.

    0
  • W

    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...

    0
  • C

    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 😃

    0
  • D

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

    0
  • R

    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.

    0
  • D

    Kannst du das mal etwas mehr ausführen?

    0
  • C

    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 😃

    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.

    0
  • S

    \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

    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.

    0
  • C

    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.

    0
  • S

    \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]

    0
Anmelden zum Antworten