libnetplus

Tuxist1

Moin,

habe ein Bibliothek geschrieben für Netzwerk Abstraktion, wollte fragen ob jemand gegenchecken kann ob ich bei den Crypto Methoden mir keinen groben Fehler erlaubt habe. Bin nicht so mega stark in Mathe . Wird bald ernst will den traefik Proxy ausstauschen gegen eigene Lösung mit HTTP3 backend support.

https://tuxist.de/git/jan.koester/libnetplus

Anon-81275

@Tuxist1 sagte in libnetplus:

wollte fragen ob jemand gegenchecken kann ob ich bei den Crypto Methoden mir keinen groben Fehler erlaubt habe

Nope, alles richtig. Würde aber dennoch mal eine KI drüber schauen lassen. Ich kenne das von mir, ab ca. 2000 LoCs (an einem Tag...) steigt bei mir die Flüchtigkeitsfehlerrate.

DocShoe

Bei crypto Sachen wäre ich immer sehr vorsichtig und würde eher bestehende Bibliotheken benutzen, wie z.B. crypto++. Weiß allerdings nicht, ob du dir nicht zusätzliche Abhängigkeiten in's Boot holst.

Quiche Lorraine

@Tuxist1
Das Hauptproblem was ich hier sehe, sind nachprogrammierte Verschlüsselungsalgorithmen. Und irgentwie sieht es so aus, als hättest du TLS nachprogrammiert.

Das sieht zwar gut aus, aber die Entwicklung eigener Verschlüsselungssysteme ist leider nicht trivial. Schaue dir mal die folgende Doku zu cryptopp-modern an:

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

Weitere Dinge:

Lagere Tests in einen eigenen IDE Ordner aus.
Probiere mal Testprojekte mit CppUnit zu entwickeln.
Nutze Clang-Tidy um deinen Code zu kontrollieren. -> Apropos, Clang-Tidy meldet für deine Funktion void rsa::add(const bigInt& a, const bigInt& b, bigInt& res) die folgende Meldung:

Clang Power Tools : Out of bound access to memory after the end of the heap area [clang-analyzer-security.ArrayBound,-warnings-as-errors] C:...\libnetplus-main\src\crypto\rsa.cpp 627
Wenn du unter Linux unterwegs bist, dann rufe mal dein Programm mit valgrind auf. Unter Windows gibt es zwar Dr. Memory, das hat aber unter Win11 die Grätsche gemacht.
Nutze CppCheck.
Manuelle Speicherverwaltung ist veraltet. (siehe socket.cpp)

Kleinigkeiten:

Nutze vorkompilierte Header.
Initialisieren primitive Member von Klassen immer direkt.
Vermeide C Casts.
Versuche Pointer soweit wie möglich zu vermeiden.

Finnegan

@Quiche-Lorraine sagte in libnetplus:

@Tuxist1
Das Hauptproblem was ich hier sehe, sind nachprogrammierte Verschlüsselungsalgorithmen.

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. Und selbst dann würden bestimmt noch viele überraschende Schwachstellen gefunden, wenn Community-Experten das mal so richtig in die Mangel nehmen.

Wie gesagt, ziemlich cool, aber für produktiven Einsatz würde ich auch auf etablierte Bibliotheken zurückgreifen.

Achja: Sind solche Algorithmen wie RC4 und DES notwendig für Kompatibilität? Ich hätte wahrscheinlich gar nicht erst mit solchen Altertümchen angefangen, sondern mich vielleicht nur auf curve25‎519 und vielleicht noch die NIST-Kurven konzentriert. Weniger Code und weniger potentielle Angriffsfläche.

Und noch was beim groben Überfliegen: Der Code sieht echt sauber und professionell aus. Das sagt zwar nix über die Korrektheit, aber das macht einen guten Eindruck für ein OSS-Projekt

Th69

@Finnegan sagte in libnetplus:

Und noch was beim groben Überfliegen: Der Code sieht echt sauber und professionell aus.

Sehe ich auch so.

Was mir aber aufgefallen ist: die Source-Dateien sollten als erstes direkt den eigenen Header einbinden und erst danach dann weitere Header, um sicherzustellen, daß die Header für sich alleine fehlerfrei kompilieren (also z.B. "connection.cpp" als erstes #include "connection.h"), insbesondere wenn sie die öffentliche API darstellen.

Edit: @Tuxist1, du könntest auch mit cpp-header-checker (oder ähnlichen) dein Projekt mal überprüfen, ob die einzelnen Dateien wirklich so viele Header einbinden müssen (oder evtl. auch Vorwärtsdeklarationen reichen).

Anon-81275

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

Tuxist1

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.