4. libnetplus

libnetplus

  • A

    @Anon-81275 sagte in libnetplus:

    alles richtig

    Bitte diese/meine Aussage mit absoluter Vorsicht genießen... Ich hatte lediglich in die src/crypto/aes.cpp geschaut, und bin auch kein Cryptoexperte...

    Seiteneffekte können auftreten, @Finnegan erwähnte es, diese sind unbedingt auszuschließen, und gehören für mich auch zur Korrektheit der Algos dazu.

    @DocShoe und @Th69 erwähnten es, das ist eigentliche Reinventing the wheel... In fast allen Fällen, würde man bereits "fertige" Libs dafür einsetzen.

    Wenn man es doch selbst machen will, um etwas zu lernen usw., setze alle gebräuchlichen Analyzer-Tools ein, wie @Quiche-Lorraine es erwähnte.

    0
  • T

    Danke für die vielen hilfreichen Tipps erste maßnahme wird sein Clang Power Tools zu nutzen um alles nochmal zu durchsichten und die manuele Speicher verwaltung raus zu schmeißen sowie die C-casts zu entfernen.

    Gibt es ein Penetrations Tool für simulierte angriffe ?

    Habe bist jetzt mit valgrind und wrk versucht fehler zu finden.

    0
    A
    F
     3 Antworten
  • A

    @Tuxist1 Für bspw. AES und DES müsstest du dafür die Unit-Tests selbst schreiben, und den NIST-Testvektor für AES verwenden.

    Hier ist eine Roadmap:

    [Krypto-C-Code]
   │
   ├──► 1. Known Answer Tests ──► Stimmen Ciphertexte mit NIST-Vektoren überein?
   ├──► 2. Dieharder / NIST ───► Ist der Geheimtext statistisch von Zufall unterscheidbar?
   ├──► 3. Valgrind / Cppcheck ─► Gibt es Speicherlecks oder Buffer Overflows?
   └──► 4. Dudect Testing ─────► Ist die Ausführungszeit unabhängig vom Schlüssel?

    Tools:

    • offiziellen Vektoren des NIST für AES
    • Dokumente des alten NBS FIPS PUB 46 für DES-Testvektoren
    • NIST Statistical Test Suite: Standard-Werkzeugpaket (15 statistische Tests), um zu prüfen, ob der erzeugte Geheimtext mathematisch von echtem Zufall unterscheidbar ist
    • Dieharder Test Suite: Ein extrem strenges, auf Linux/Kali verfügbares Werkzeug zur Überprüfung von Zufälligkeit
    • Valgrind
    • Cppcheck
    • dudect-Testframework: Prüfung auf Seitenkanal-Angriffe (Side-Channel Attacks)

    ... Brute-Force würde man hingegen nicht für ein Krypto-Audit verwenden, da dadurch keine Aussage über die kryptografische Sicherheit bzw. Qualität getroffen werden kann.

    0
  • F

    @Tuxist1 sagte in libnetplus:

    Habe bist jetzt mit valgrind und wrk versucht fehler zu finden.

    Bin da kein Spezialist, aber Valgrind gehört auf jeden Fall dazu. Und ich denke auch der Speicher, in dem Keys gehalten werden, sollte sehr spezieller Speicher sein, der z.B. nicht ausgelagert und nach verwendung der Keys auch explizit und garantiert überschrieben wird. Der Code von Crypto-Bibliotheken den ich bisher gesehen habe, verwendet soweit ich mich erinnere OS-spezifische Funktionen für sowas. Für (statische) Keys auf dem System will man vielleicht auch noch Keystores des OS oder gar Unterstützung für HSMs oder USB-Tokens haben.

    Aber wie gesagt, bin kein Experte auf dem Gebiet. Daher noch ein praktischer Tip für C++ und korrekten, Standardkonformen Code: Schau dir mal Sanitizer an ie z.B. ASAN und UBSAN und bau dein Programm und alle Abhängigkeiten auch mal mit LTO (-flto). Wenn die Code-Generierung auf die Link-Time verschoben wird kann der Compiler nicht nur besser optimieren, sondern auch noch wesentlich mehr informative Warnungen ausgeben, da er das ganze Programm sieht, und nicht nur eine Übersetzungseinheit. Das ist manchmal eine echte Überraschung, was da plötzlich noch an zusätzlichen Warnungen kommt, wenn man ein Projekt mit LTO baut.

    Ausgiebige Unit-Tests für Bestandteile der Bibliothek sollten natürlich auch nicht fehlen.

    Das hier sieht mir auch nützlich aus: Compiler Options Hardening Guide for C and C++

    0

  • @Finnegan sagte in libnetplus:

    Ich muss sagen, ich finde das ziemlich cool. Allerdings ist diese Algorithmen korrekt (im Sinne des Algorithmus) hinzubekommen nur ein kleiner Teil der Miete. Das Hauptproblem dürfte sein, die so zu implementieren, dass keine Side-Channel-Attacken möglich sind, und auch keine subtilen Bugs, mit denen man irgendwie an Schlüsselmaterial oder Klartexte kommen kann. Ich würde mir das absolut nicht zutrauen, ohne mich nicht viele Jahre damit beschäftigt zu haben.

    Das Problem ist sogar dass man selbst mit Libs ala Cryptopp-(modern) auch noch diese Probleme hat. Ein paar grundlegende Probleme stehen im folgenden Link:

    https://cryptopp-modern.com/docs/guides/security-concepts/

    Der Klassiker ist aber die Anwendung der Cryptop-Modi. Ich habe selbst schon mal den Kommentar gehört:

    Warum denn Crypto-Modi einsetzen? AES ist doch sicher!

    Darauf habe ich auf den folgenden Link verwiesen:

    https://de.wikipedia.org/wiki/Electronic_Code_Book_Mode

    Was mir aber so richtig die Augen für Kryptograhie öffnete, war das Buch "Practical Cryptography " von Bruce Schneier. Und ich lernte, selbst die Anwendung von Kryptographie ist nicht einfach.

    0
    *
     1 Antwort
  • *

    @Quiche-Lorraine sagte in libnetplus:

    @Finnegan sagte in libnetplus:

    Was mir aber so richtig die Augen für Kryptograhie öffnete, war das Buch "Practical Cryptography " von Bruce Schneier. Und ich lernte, selbst die Anwendung von Kryptographie ist nicht einfach.

    Ich hatte das Vergnügen vor einer halben Ewigkeit eine Vorlesung und anschließendes Seminar bei Prof. Schnorr zu besuchen. Das ist richtig harte Kost. Dazu kommt, dass die Informatiker und und die Mathematiker aus der diskreten Mathematik meist nicht seht gut bewandert sind in der theoretischen Physik insbesondere in der Ausprägung der Quantenmechanik. Das ist mittlerweile notwendig, um Algorithmen gegen Angriffe durch Quantencomputer zu sichern. Verschlüsselungen sollen ja nicht nur aktuell sicher sein, sondern auch über einen entsprechend langen Zeitraum Daten vor Veränderung schützen. Die komplette Algorithmenforschung auf Quantenrechner steckt noch in den Kinderschuhen, weil Quantenrechner bisher kaum zu etwas zu gebrauchen sind. Allerdings kennt man einen Algorithmus mit dem man die Module des RSA Algorithmus knacken kann.

    0 1 Antwort

  • @Tuxist1 sagte in libnetplus:

    Gibt es ein Penetrations Tool für simulierte angriffe ?

    Es gibt das Metasploit Framework. Ich habe aber damit noch nie gearbeitet.

    Ich würde aber zuerst schauen dass du das Ganze sehr sauber implementiert bekommst und danach mittels Tests die gängisten Pen-Tests durchführst.

    Habe bist jetzt mit valgrind und wrk versucht fehler zu finden.

    Versuche mal zu verstehen was Clang-Tidy an dieser Stelle für ein Problem hat. Evt. könntest du den Code auch in einen Test packen und schauen ob du diesen herausprovozierst bekommst.

    0

  • @john-0 sagte in libnetplus:

    Allerdings kennt man einen Algorithmus mit dem man die Module des RSA Algorithmus knacken kann.

    In der Lib cryptopp-modern wird dies auch beschrieben:

    https://cryptopp-modern.com/docs/algorithms/post-quantum/

    0
  • T

    So dass Dudect/Dieharder hat sehr geholfen konnte 5 Bugs beseitigen

    So dass habe bis jetzt gemacht:
    -socket.cpp malloc entfernt
    -nist werte in den tests implementiert
    -gegen overflows gecheckt
    -compiler warnings behoben (clang/gcc) msvc mache ich morgen
    -dudect tests (konnte zwei problem stellen dadurch entschärfen)
    -u256/p256 zu einer richtigen klasse geformt mit operator überladung

    1
    A
     1 Antwort
  • A

    @Tuxist1 sagte in libnetplus:

    konnte 5 Bugs beseitigen

    Das ist super!

    Ein Brute-Force-Pen-Test hätte dir nur sagen können: Ja, kann - oder nein, kann nicht innerhalb von x Zeit gefunden werden... und daraus hättest du dann noch nicht ableiten können.

    Insgesamt ist es sicher ein gutes Gefühl, Industriestandard erreicht zu haben... 🙂

    0
Anmelden zum Antworten