wert Arbeit Verschlüsselung schlüssel Passwort kryptographie Schlüssellänge

noch mal Kryptographie

Von: , Frage gestellt am Do, 10. Jul 2008

Hallo nochmal,

ich möchte einen Login-Mechanismus mittels "Challenge-Response" Verfahren und asymetrischer Verschlüsselung (RSA) realisieren:

1. A erzeugt eine Zufallszahl (4 Hexziffern) und sendet diese an B.
2. B verschlüsselt diese Zufallszahl mit seinem Public-Key zu einem Passwort und sendet das Passwort an A.
4. A entschlüsselt das Passwort mittels seines Private-Key.
5. Wenn das entschlüsselte Passwort mit der ursprünglichen Zufallszahl übereinstimmt kann sich A einloggen.

Zur Realisierung habe ich mir die "Crypto++ Library 5.5.2" runtergeladen. Leider musste ich feststellen das ich damit nur RSA-Verschlüsselungen ab einer Schlüssellänge von 384 Bit durchführen kann. Das ist für mein Vorhaben etwas unpraktisch da ich das Passwort mündlich am Telefon übertragen muss. Bei einer Schlüssellänge von 384 Bit ergibt das eine sehr lange Sequenz. Das Passwort soll aber maximal 8 Stellen lang sein.
Nun meine Fragen:
1. Ist bei der Verschlüsselung von kurzen Texten (4 Hexziffern) überhaupt so ein langer Schlüssel notwendig und sinnvoll?
2. Gibt es C++ Quellcode für RSA der kürzere Schlüssel akzeptiert?
3. Wenn nicht gibt es andere asymetrische Verschlüsselungsverfahren für kurze Textsequenzen die nicht mehr als 8 Stellen verschlüsselten Text erzeugen?

9 Antworten zu dieser Frage

1. Antwort von nach 47 Minuten 0 hilfreich

   Re: noch mal Kryptographie

   Hallo, ich möchte einen Login-Mechanismus mittels
   "Challenge-Response" Verfahren und asymetrischer
   Verschlüsselung (RSA) realisieren:
   
   1. A erzeugt eine Zufallszahl (4 Hexziffern) und sendet diese
   an B.
   Ist das nicht ein bisschen wenig? 4 Hex-Ziffern = 16 bit = 65536 Möglichkeiten - das ist schnell geknackt. 2. B verschlüsselt diese Zufallszahl mit seinem Public-Key zu
   einem Passwort und sendet das Passwort an A.
   4. A entschlüsselt das Passwort mittels seines Private-Key.
   Wus? A kennt doch die Zufallszahl schon. Er/sie hat sie ja schliesslich generiert. Ausserdem hat A ja sicher nicht den private key von B, d.h. er kann das gar nicht entschlüsseln. 5. Wenn das entschlüsselte Passwort mit der ursprünglichen
   Zufallszahl übereinstimmt kann sich A einloggen.
   Wenn A sich einloggen will, musst du eher sowas machen:
   1) B erzeugt eine Zufallszahl, verschlüsselt sie mit As öffentlichem Schlüssel, und schickt das Ergebnis an A
   2) A entschlüsselt mit seinem private key, und schickt das Ergebnis zurück an B
   3) B vergleicht die ursprüngliche Zufallszahl mit dem, was A geschickt hat. Wenn es übereinstimmt, betracht B A als authentifiziert. 1. Ist bei der Verschlüsselung von kurzen Texten (4
   Hexziffern) überhaupt so ein langer Schlüssel notwendig und
   sinnvoll?
   Nein. Ich würde Challenge-Response mit kryptographischen Hashes machen.
   
   Aber fürs Telefon sind die alle immer noch ein bisschen zu lang. Ich bezweifle, dass du zu einem sicheren Verfahren kommst, das so kompakt ist, dass es am Telefon funktioniert.
   
   Grüße,
   Moritz
   

   • Antwort von nach 6 Stunden 0 hilfreich

     Re^2: noch mal Kryptographie

     Hallo Moritz, Ist das nicht ein bisschen wenig? 4 Hex-Ziffern = 16 bit =
     65536 Möglichkeiten - das ist schnell geknackt.
     Schon aber die vc++ rand() liefert nicht mehr. Ich mache nach dreimaliger Falscheingabe ein reboot. Das macht es ziemlich mühsam und ein Geldautomat hat auch nicht mehr. Ich kann aber auch mit zwei unabhängigen Zufallszahlengeneratoren arbeiten. Dann hätte ich 8 Hexziffern. Mehr sollten es aber wegen dem Telefon nicht sein. Wus? A kennt doch die Zufallszahl schon. Er/sie hat sie ja
     schliesslich generiert.
     Schon aber A kennt nicht das Passwort da nur B den public-key hat. Das Passwort wird im Loginprogramm entschlüsselt und mit der uhrsprünglichen Zufallszahl verglichen. Ausserdem hat A ja sicher nicht den
     private key von B, d.h. er kann das gar nicht entschlüsseln.
     Doch den hat er im Rechner abgespeichert. B hat den public-Key. Wenn A sich einloggen will, musst du eher sowas machen:
     1) B erzeugt eine Zufallszahl, verschlüsselt sie mit As
     öffentlichem Schlüssel, und schickt das Ergebnis an A
     2) A entschlüsselt mit seinem private key, und schickt das
     Ergebnis zurück an B
     3) B vergleicht die ursprüngliche Zufallszahl mit dem, was A
     geschickt hat. Wenn es übereinstimmt, betracht B A als
     authentifiziert.
     Es geht mir nicht darum das A sich gegenüber B authentifiziert sondern darum das A nur von B die Berechtigung zum Login erhällt. Sowas kann ich nur durch ein Challenge-Response-Verfahren oder durch ein One-Time-Passwort realisieren. Die Lösung mit dem One-Time-Passwort wäre mir zwar lieber aber dazu muss ich auf dem Rechner von A dauerhaft etwas speichern können. Das kann ich leider nicht (Plattenloser PC wird von CD gebootet). Ausserdem bringt das für B erheblichen Verwaltungsaufwand da er nicht nur für A sondern auch für C, D, E ... die Login-Berechtigung erteilen muss.
     Güsse soso
     

     • Antwort von nach 8 Stunden 1 hilfreich

       Re^3: noch mal Kryptographie

       Hallo, Ist das nicht ein bisschen wenig? 4 Hex-Ziffern = 16 bit =
       65536 Möglichkeiten - das ist schnell geknackt.
       Schon aber die vc++ rand() liefert nicht mehr.
       Die kann man ja zwei mal hintereinander aufrufen.
       Übrigens glaube ich nicht, dass die kryptographisch gute Zufallszahlen liefert. Ich mache nach
       dreimaliger Falscheingabe ein reboot.
       Damit jeder, der dein System lahmlegen will, einfach nur drei mal ein falsches Passwort eingeben muss, und dein System nur noch mit rebooten beschäftigt ist? Das macht es ziemlich
       mühsam und ein Geldautomat hat auch nicht mehr.
       Was sicherheitstechnisch auch ein Faux Pas ist. Weil andere es schlecht machen heisst nicht, dass du das auch machen musst.
       
       Versteh mich nicht falsch, ich will dir kein Paranoia-Level vorschreiben, aber wenn du hier im Mathe-Brett fragst gehe ich davon aus, dass dich die kryptographischen Aspekte interessieren. Und aus der Sicht muss ich dir einfach sagen, dass dein System so nicht sicher ist. Wus? A kennt doch die Zufallszahl schon. Er/sie hat sie ja
       schliesslich generiert.
       Schon aber A kennt nicht das Passwort da nur B den public-key
       hat. Das Passwort wird im Loginprogramm entschlüsselt und mit
       der uhrsprünglichen Zufallszahl verglichen.
       Es gibt also noch ein Paswort? Falls dich genaueres Feedback interessiert, solltest du auch ein bisschen genauer Beschreiben.
       Welche Partei hat welche Schlüssel? Haben beide ein gemeinsames Geheimnis? Muss die Authentifizierung in beide Richtungen verlaufen?
       
       Grüße,
       Moritz
       

       • Antwort von nach 9 Stunden 0 hilfreich

         Re^4: noch mal Kryptographie

         Hallo, Die kann man ja zwei mal hintereinander aufrufen.
         Übrigens glaube ich nicht, dass die kryptographisch gute
         Zufallszahlen liefert.
         Zweimal hintereinander aufrufen bringt nix. Wenn man die erste kennt kann man die zweite selbst generieren. Im Übrigen ist eine Teilfolge einer Pseudozufallsfolge nicht notwendig wieder eine gute Zufallsfolge. Ich mache nach
         dreimaliger Falscheingabe ein reboot.
         Damit jeder, der dein System lahmlegen will, einfach nur drei
         mal ein falsches Passwort eingeben muss, und dein System nur
         noch mit rebooten beschäftigt ist?
         Genau das ist der Sinn. Denn es ist nicht mein System sondern das der Anderen und die wollen schlisslich damit Arbeiten. Ich will lediglich vor jedem booten das Login-Passwort zuteilen. Versteh mich nicht falsch, ich will dir kein Paranoia-Level
         vorschreiben, aber wenn du hier im Mathe-Brett fragst gehe ich
         davon aus, dass dich die kryptographischen Aspekte
         interessieren. Und aus der Sicht muss ich dir einfach sagen,
         dass dein System so nicht sicher ist.
         Eine hundertprozentige Sicherheit gibt es ohnehinn nicht. Aber gerade durch das rebooten habe ich die Möglichkeit des Knackens doch wesentlich erschwert. Passwortgeschützte RAR-Files sind übrigens aus diesem Grund ziemlich sicher da nur 3 Passworter pro Sekunde getestet werden können. Die Verzögerung ist also auch ein wesentlicher Bestandteil der Sicherheit. Es gibt also noch ein Paswort?
         Ja das hatte ich doch im ersten Posting geschrieben. Die von B mit seinem public-key verschlüsselte Zufallszahl dient A als Loginpasswort.
         
         Vielleicht wird der Ablauf durch folgende Skitze klarer:
         
         

         B                               A
         /--<----- Challenge ---------<--\
         |                               |
         |                               |
         |                             rand() <--- Start
         |                               |
         public Key ---> RSA                              =?
         |                               |
         |                              RSA <--- privat Key
         |                               |
         \-->----- Passwort ---------->--/
         

         
         
         Alles was ich jetzt noch brauche ist der Source-Code einer RSA-Verschlüsselung mit kleiner Schlüssellänge.
         
         Gruss soso
         

         • Antwort von nach einem Tag 0 hilfreich

           Re^5: noch mal Kryptographie

           Hallo, Die kann man ja zwei mal hintereinander aufrufen.
           Übrigens glaube ich nicht, dass die kryptographisch gute
           Zufallszahlen liefert.
           Zweimal hintereinander aufrufen bringt nix. Wenn man die erste
           kennt kann man die zweite selbst generieren.
           Dann ist das ein sehr schlechter Zufallsgenerator. Normalerweise haben die noch intern Informationen gespeichert, die dafür sorgen, dass sich die Zahlenfolge nicht sofort wiederholt, wenn zwei mal hintereinander die gleiche Zahl herauskommt.
           Die Periodenlänge muss ja nicht auf die Anzahl der möglichen Ausgaben beschränkt sein. Im Übrigen ist
           eine Teilfolge einer Pseudozufallsfolge nicht notwendig wieder
           eine gute Zufallsfolge.
           Und zwei Zufallsgeneratoren sind da besser? Wo bekommst du deine Entropie eigentlich her? Ich mache nach
           dreimaliger Falscheingabe ein reboot.
           Damit jeder, der dein System lahmlegen will, einfach nur drei
           mal ein falsches Passwort eingeben muss, und dein System nur
           noch mit rebooten beschäftigt ist?
           Genau das ist der Sinn. Denn es ist nicht mein System sondern
           das der Anderen
           Und du kannst die zwingen, einen Reboot zu machen? Wie denn? Hast du Kontrolle über ihr System? Es gibt also noch ein Paswort?
           Ja das hatte ich doch im ersten Posting geschrieben. Die von B
           mit seinem public-key verschlüsselte Zufallszahl dient A als
           Loginpasswort.
           Und A hat die generiert? Vielleicht wird der Ablauf durch folgende Skitze klarer:
           
           

           B                               A
           /--<----- Challenge ---------<--\
           |                               |
           |                               |
           |                             rand() <---
           Start
           |                               |
           public Key ---> RSA                              =?
           |                               |
           |                              RSA <---
           privat Key
           |                               |
           \-->----- Passwort ---------->--/
           

           
           Versteh ich einfach nicht, wie das sicher sein soll. Oder überhaupt funktionieren soll. Aber vielleicht bin ich einfach zu beschränkt dafür. Alles was ich jetzt noch brauche ist der Source-Code einer
           RSA-Verschlüsselung mit kleiner Schlüssellänge.
           Schaum mal in die gpg sources. Da ist das für verschiedene Schlüssellängen implementiert.
           
           Schönes Wochenende,
           Moritz
           

2. Antwort von nach 20 Stunden 1 hilfreich

   Re: noch mal Kryptographie

   Und jetzt kommt der Angreifer Mallory (M). 1. A erzeugt eine Zufallszahl (4 Hexziffern) und sendet diese an B.
   M erzeugt eine Zufallszahl Z und sendet diese im Namen von A an B. 2. B verschlüsselt diese Zufallszahl mit seinem Public-Key zu
   einem Passwort und sendet das Passwort an A.
   B denkt, dass sich A einloggen will. Er verschlüsselt Z mit dem Public-Key von A und sendet es zurück an M. 4. A entschlüsselt das Passwort mittels seines Private-Key.
   M kann die Nachricht nicht entschlüsseln, weil er natürlich nicht im Besitz des Private-Key's von A ist. Muss er aber auch gar nicht, denn er kennt den Inhalt der Nachricht ja sowieso: Es ist ja schließlich Z.
   
   
   Soweit kann also ein beliebiger Angreifer dein Verfahren ohne Probleme durchlaufen.
   
   
   5. Wenn das entschlüsselte Passwort mit der ursprünglichen
   Zufallszahl übereinstimmt kann sich A einloggen.
   Häh?
   Wer überprüft denn das?
   B offensichtlich ja nicht, weil A ja nichts mehr zu B schickt. Also weiß B ja überhaupt nicht, ob A wirklich A oder M ist. Inwiefern soll sich A deshalb einloggen können.
   
   
   So, wie du das Verfahren beschrieben hast, weiß nach Ablauf der 5 Punkte auf jeden Fall weder A dass B wirklich B ist, noch weiß B dass A wirklich A ist.
   
   Fazit: Nach Ablauf des Verfahrens wissen beide genau so wenig wie vorher. Das ganze Verfahren hat also absolut nichts gebracht.
   

   • Antwort von nach 22 Stunden 0 hilfreich

     Re^2: noch mal Kryptographie

     So, wie du das Verfahren beschrieben hast, weiß nach Ablauf
     der 5 Punkte auf jeden Fall weder A dass B wirklich B ist,
     noch weiß B dass A wirklich A ist.
     Ich glaube, es ist geplant, damit einen Benutzerlogin auf A zu sichern:
     Also in etwa so:
     1. A zeigt eine Zufallszahl an.
     2. Benutzer gibt Zufallszahl an B (offenbar telefonisch)
     3. B gibt mit PublicKey verschlüsselte Zahl zurück an Benutzer (ebenfalls telefonisch, vermutlich nach Prüfung auf Berechtigung)
     4. Benutzer gibt so erhaltene Zahl als Passwort bei A ein
     5. A entschlüsselt Eingabe mit PrivateKey
     6. Wenn entschlüsselte Eingabe und ursprüngliche Zufallszahl übereinstimmen -> Login erlaubt
     
     Der PublicKey von A müsste bei so einem Verfahren aber auch geheim bleiben und darf dem Benutzer nicht bekannt werden, sonst kann der das Passwort nämlich selbst generieren.
     
     Sebastian.
     

     • Antwort von nach 22 Stunden 0 hilfreich

       Re^3: noch mal Kryptographie

       Genau so war das gedacht. Nur das A den privat-key hat (entschlüsseln) und B den public-key (verschlüsseln).
       Gruss soso
       

   • Antwort von nach 22 Stunden 0 hilfreich

     Re^2: noch mal Kryptographie

     Das Ganze Verfahren soll nicht der gegenseitigen Authentifizierung dienen sondern dazu das B ein Loginpasswort für A vergiebt mit dem A seinen Rechner booten kann (als Alternative zu einem one-time-passwort). Da der Datenaustausch per Sprache über das Telefon läuft müsste sich ein Angreifer schon in die Telefonleitung einhacken. Das Ergebniss deines Scenarios ist das M jetzt das einmalige Loginpasswort für einen Rechner hat der Ihm nicht zur Verfügung steht und A sich nicht in seinen Rechner einloggen kann da er von M das falsche Passwort bekommen hat. Die Entschlüsselung des Passworts und der Vergleich mit der Zufallszahl findet im Loginprogramm auf dem Rechner von A statt. Die einzige Sicherheitslücke ist meiner Meinung das A das Loginprogramm hackt und die Überprüfung des Passworts überbrückt.
     Gruss soso
     

Keine passende Antwort gefunden? Jetzt eigene Frage stellen!