Kommentare

3 Kommentare zu „PQC – Post-Quantum Cryptography #07“

1. 

   26.06.2026

   Lukas Meinl

   Und schon wieder gibt es Neuigkeiten bei dem Thema. Die US-Regierung meint es ernst und hat einige Vorgaben angepasst, u.a.
   – NSPM-12 (12. Juni): Die Nationale Richtlinie für die Cybersicherheit von NSS wurde zum ersten Mal seit 35 Jahren grundlegend überarbeitet
   – EO 14412 (22. Juni): Feste Fristen zur PQC-Migration für 2030/2031 für zivile „High Value Assests“ und Systeme mit hoher Auswirkungsrelevanz
   – EO 14413 (22. Juni): Quanteninnovation, QC-ADDS-Computer, Einsatz von Sensoren bis September 2028
   – DoW PQC-Strategie (23. Juni): ministeriumsweite Migrationsfristen für 2030/2031, zwei Umsetzungswege
   – OMB M-26-15 (24. Juni): Fünf-Phasen-Umsetzungsleitfaden, Pläne der Behörden bis Oktober fällig

   Mal schauen, was noch so in Europa kommt…

   Antworten
2. 

   22.08.2026

   Lukas Liebig

   Ich habe gerade bemerkt, dass Lukas und ich auf derselben Uni waren. 🙂

   Auch zu dieser interessanten Folge noch ein paar Anmerkungen:

   Zur QKD: Wenn man durch die Quantenverschränkung bemerkt, dass ein Man In The Middle den Schlüsselaustausch belauscht hat und den Schlüssel deshalb nicht verwenden kann, dann stellt das Belauschen eines solchen QKD-Kanals ja theoretisch einen Denial of Service Angriff dar. Aber vermutlich ist das eher ein kleineres Problemchen.

   Bei der hybriden PQC bin ich voll bei dir. Es ist doch schlau, klassische Verfahren und PQC zu kombinieren. Ich kann gar nicht verstehen, warum das in manchen Kreisen anders gesehen wird.

   Dann hattet ihr noch die Länge von Schlüsseln bzw. Signaturen angeschnitten, die bei PQC deutlich größer ist. Dazu hatte ich erst eine interessante Erfahrung in Kombination mit Wireshark. Ich habe ein wenig mit DTLS 1.3 herum experimentiert (ein Blog-Beitrag dazu kommt bald). Die KI hatte mir dafür https://github.com/wolfSSL/wolfssl vorgeschlagen. Dazu gibt es noch die https://github.com/wolfSSL/wolfssl-examples wo ein paar einfache Client- und Server-Implementierungen enthalten sind. Das kann man dann einfach auf seinem Linux starten und mit tcpdump den Traffic auf 127.0.0.1 mitsniffen. Während der Anpassung und des Kompilierens von wolfSSL habe ich in den Sourcen auch den Namen des einen oder anderen PQC-Verfahrens gesehen (FrodoKEM, ML-KEM, aber auch Falcon). Jedenfalls habe ich dabei sogar einen Bug im Wireshark DTLS-Dissektor entdeckt: https://gitlab.com/wireshark/wireshark/-/work_items/21518 – Client und Server einigen sich im Beispiel-Capture auf die Gruppe SecP384r1MLKEM1024 für den KeyExchange. Der hat dann > 1600 Bytes, weshalb es zur Fragmentierung des DTLS-Handshakes kommt. Dabei schlägt dann die Versionserkennung fehl und statt DTLS 1.3 gibt Wireshark 1.2 aus.

   wolfSSL kann ich dir für deinen Ultimate PCAP nur wärmstens empfehlen. Und die KI gibt gute Ratschläge, wie man Feature xy ein- oder auskompiliert. So kam ich dann doch noch an einen DTLS 1.3 Capture mit unfragmentiertem Handshake inkl. SSLKEYLOGFILE.

   Ziemlich am Ende sprichst du noch von einem Dashboard eines Firewall-Herstellers, das zeigt welche Ciphersuites in deinem Netz im Einsatz sind. Das kann die Allegro (https://allegro-packets.com/de/allegro-network-multimeter-b) mit ihrem TLS-Analysemodul auch richtig gut. Auf die erkannten Ciphersuites kann man sogar Incidents konfigurieren und wird von der Allegro benachrichtigt, sobald ein solcher Cipher gesehen wird. 😉

   Antworten
   1. 

      16.09.2026

      Lukas Liebig

      Ich weiß nicht, ob du diese Folge schon gehört hast: https://open.spotify.com/episode/6hs7BHMHCHA8HS3vBv4XmS

      Hier wird das QKD Verfahren BB84 grob erklärt. Eine gute Ergänzung zu deiner PQC-Folge.

      Antworten