\startpage

1 \editor \booktitleBeitrag für den 17. Deutschen IT-Sicherheitskongress, 2021 2021

Zur Integration von Post-Quantum Verfahren in bestehende Softwareprodukte

Alexander Zeier¹¹1Hochschule Darmstadt, FB Informatik, Haardtring 100, 64295 Darmstadt ¡vorname¿.¡nachname¿@h-da.de Alexander Wiesmaier¹¹footnotemark: 1 Andreas Heinemann¹¹footnotemark: 1

Zusammenfassung

Aktuell werden PQC-Algorithmen standardisiert, um der aufziehenden Gefahr für konventionelle asymmetrische Algorithmen durch Quantencomputer zu begegnen. Diese neuen Algorithmen müssen dann in bestehende Protokolle, Applikationen und Infrastrukturen eingebunden werden. Dabei ist mit Integrationsproblemen zu rechnen, die einerseits durch Inkompatibilitäten mit existierenden Standards und Implementierungen begründet sind, andererseits aber auch durch fehlendes Wissen der Softwareentwickler über die Handhabung von PQC-Algorithmen zustande kommen. Um Inkompatibilitäten beispielhaft aufzuzeigen, integrieren wir zwei unterschiedliche PQC-Algorithmen in zwei verschiedene bestehende Softwareprodukte (InboxPager E-Mail Client und TLS Implementierung der Bouncy Castle Bibliothek). Hierbei setzen wir auf die hoch-abstrahierende Krypto-Bibliothek eUCRITE, die Entwicklern das Detailwissen über die korrekte Verwendung klassischer und PQC-Algorithmen abnimmt und damit bereits einige potentielle Implementierungsfehler vermeidet. Die dabei zutage getretenen Probleme bestätigen teilweise bereits bekannte Inkompatibilitäten, beinhalten aber auch neue, bisher nicht angesprochene Schwierigkeiten.

Stichworte: Post-Quantum Verfahren, Kryptoagilität, eUCRITE-API, API

1 Einführung

Quantencomputer sind Gegenstand der laufenden Forschung. Bei ausreichender Leistung, d.h. wenn Shor’s Algorithmus [23] auf einem Quantencomputer mit ausreichender Qubitlänge ausgeführt werden kann, wird man in der Lage sein, die derzeit verwendeten asymmetrischen Algorithmen wie RSA, DSA, ECDSA und ECDH zu brechen [9]. Der Bedarf an Post-Quanten-Kryptographie (PQC), insbesondere asymmetrischen Verfahren²²2Auch symmetrische Verfahren wie DES oder AES sind durch den Algorithmus von Grover ([11]) bedroht, jedoch können längere Schlüssel hier die Gefahr lindern., ist offensichtlich, da potentiell unsicher werdende asymmetrische Verfahren in vielen ausgerollten hybriden Kryptosystemen zu finden sind.

Dieser Beitrag stellt die im Rahmen des Forschungsprojektes Use-A-PQClib [13] entwickelte eUCRITE-API [12] vor, die als Designziele eine gute Benutzbarkeit und Verständlichkeit für einen Entwickler sowie eine hohe Abstraktion von technischen Parametern wie beispielsweise Schlüssellängen von Krypto-Algorithmen aufweist.

Der Hauptteil beinhaltet darauf aufbauend einen Erfahrungsbericht bei der Integration der PQC-Verfahren McEliece [19] und SPHINCS+ [6] auf Basis der eUCRITE-API in zwei bestehende Softwareprodukte. Zum einen die Integration in InboxPager³³3https://github.com/itprojects/InboxPager (besucht am 29.12.2020), einen E-Mail Client für das Android Betriebssystem, zum anderen die Integration in die TLS Implementierung von Bouncy Castle⁴⁴4https://www.bouncycastle.org (besucht am 29.12.2020). Bouncy Castle ist eine weit verbreitete Krypto-Bibliothek für Java und C#, welche neben den grundlegenden Krypto-Operationen wie Verschlüsseln und Signieren auch eine TLS Implementierung zur Verfügung stellt. Hierbei konzentriert sich die Integration auf den Austausch der klassischen asymmetrischen Krypto-Verfahren gegen die oben genannten PQC-Verfahren der jeweiligen hybriden Kryptosysteme.

Damit soll aufgezeigt werden, mit welchen Herausforderungen und technischen Problemen Entwickler bei der Integration von PQC-Verfahren rechnen müssen. Des Weiteren werden die Vor- und Nachteile sowie die Implikationen einer hohen API-Abstraktion vorgestellt.

Abschließend wird ein Fazit gezogen und ein Ausblick auf weitere Schritte und noch zu adressierende Fragestellungen bei der Umstellung von klassischen auf PQC-Verfahren gegeben.

2 Verwandte Arbeiten

Der Dagstuhl Report [4] berichtet über Biggest Failures in IT Security und empfiehlt (unter anderem) Entwickler bei der Implementierung von Sicherheitsmechanismen stärker zu unterstützen. Dazu gehört zum einen die Bereitstellung von Werkzeugen und Methoden, die es dem Entwickler leichter machen guten Code zu schreiben (to do the good/right thing, Seite 20). Zum anderen gilt es, die verschiedenen Kenntnisse und Vorlieben der verschiedenen Entwickler- bzw. Benutzergruppen zu beachten.

[21] präsentieren zahlreiche Forschungsfragen zur Kryptoagilität [18] und Migration nach PQC und decken dabei auf hohem Diskussionsniveau ein weites Feld an Themen ab, darunter Implementierungsaspekte. Dabei geht es den Autoren nicht nur um die Umsetzung der in mathematischen Formeln ausgedrückten PQC-Algorithmen auf verschiedensten Plattformen und in unterschiedlichen Programmiersprachen. Es ist ebenfalls von enormer Wichtigkeit, die implementierten Algorithmen so in vorhandene Systeme einzubringen, dass Kontinuität und Interoperabilität während der Migrationsphase erhalten bleiben.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gibt Handlungsempfehlungen zur Migration zu Post-Quanten-Kryptografie [24] und empfiehlt (zumindest während der Migrationsphase) den Einsatz hybrider Lösungen, d.h. der Kombination klassischer und PQC-Algorithmen, und die entsprechende Anpassung kryptographischer Protokolle. Dabei soll die Umsetzung dem Prinzip der Kryptoagilität folgen, um auch zukünftige Empfehlungen und Standards entsprechend umsetzten zu können. Als besonders dringend gilt der Umstieg auf (hybride) PQC-Verfahren bei Schlüsseleinigungsverfahren zum Schutz langfristiger Geheimnisse.

[8] nennen, neben der Beschreibung des State-of-the-Art in PQC und Anpassungsempfehlungen, um die Standards X.509, IKEv2, TLS 1.2, S/MIME und SSH2 PQC-bereit zu machen, wichtige Anwendungsfelder und -fälle für Kryptographie. Je nach bereits vorhandener Kryptoagilität beschränken sich die Empfehlungen auf die einfache Einführung neuer OIDs bzw. Cipher Suites oder beinhalten die mehr oder weniger tiefgreifende Anpassung vorhandener Standards. Die Gefahren von Quantencomputer-Angriffen auf typische Anwendungsfelder (Verschlüsselung, Authentisierung, …) werden vorgestellt und in dieser Hinsicht besondere Verwundbarkeiten verschiedener Industriezweige diskutiert.

[10] stellen ihre Integration von PQC-Verfahren in die Protokolle TLS 1.2, TLS 1.3 und SSH2 vor, und berichten von den dabei zu bewältigenden Herausforderungen. Ein Beispiel für eine solche Herausforderung ist die zertifikatsbasierte Übermittlung mehrerer Schlüssel für unterschiedliche Verfahren, die in hybriden Umsetzungen benötigt werden. Ein anderes Beispiel sind Limitierungen für die Größe von Nachrichten zum Schlüsseltausch oder Signaturen, die teilweise implementierungsbedingt sind, aber teilweise auch auf die Spezifikationen in den Standards zurückzuführen sind.

[14] untersucht, unter anderem, Eigenschaften von hybriden Signaturverfahren und deren Integration in verschiedene Implementierungen von X.509, TLS und S/MIME. Als wichtige Eigenschaften hybrider Signaturverfahren werden Unfälschbarkeit unter Signaturorakeln (EUF-CMA) und Nicht-Separierbarkeit⁵⁵5Eine hybride Signatur kann vom Angreifer nicht in eine Einzelsignatur umgeformt werden. identifiziert. Die Integration eines zweiten Signaturschemas wurde über Erweiterungsmechanismen (X.509 extensions), nachgelagerte Authentifizierung (TLS) oder parallele/verschachtelte Signaturen (S/MIME) erreicht. In vielen Konstellationen führt die Einführung von Zusatzinformationen über ca. 40KiB zu Kompatibilitätsproblemen.

Die vorliegende Arbeit eruiert an zwei real umgesetzten PQC-Migrationen die dabei auftretenden Probleme und konkretisiert so die in den obigen Arbeiten aufgeführten theoretischen Überlegungen bzw. ergänzt die dort vorgestellten praktischen Herausforderungen.

3 Verwendete Softwarekomponenten und Produkte

Im Rahmen dieser Arbeit wurden Post-Quantum Verfahren in zwei Software-Produkte integriert. Hierbei wurde zum einen ein E-Mail-Client ausgewählt, da es sich hierbei mit über 300 Milliarden E-Mails pro Tag⁶⁶6https://de.statista.com/statistik/daten/studie/252278/umfrage/prognose-zur-zahl-der-taeglich-versendeter-e-mails-weltweit/ (besucht am 29.12.2020) um eine der wesentlichen Anwendungen im Internet handelt. Zum anderen wurde mit TLS 1.2 ein Sicherheits-Protokoll gewählt, welches der aktuell gebräuchliche Standard zur Absicherung von HTTP im Internet ist. Zur Bereitstellung der benötigten PQC-Algorithmen wurde auf die Krypto-Bibliothek eUCRITE-API zurückgegriffen. Da es sich dabei um eine Java-API handelt, sind die beiden betrachteten Implementierungen ebenfalls in Java geschrieben. Die API sowie die Softwareprodukte werden im Folgenden kurz vorgestellt.

3.1 eUCRITE-API

Refer to caption — Figure 1: Klassendiagramm der eUCRITE-API

Die eUCRITE-API [28, 12] ist eine kryptografische Bibliothek mit Fokus auf einfache Benutzbarkeit, die auch Laien die sichere Verwendung kryptografischer Verfahren ermöglicht. Dazu werden sogenannte Templates eingesetzt, um die Auswahl der Algorithmen und Parameter für den Entwickler transparent zu gestalten. Die Auswahl wird durch die einfache Angabe des gewünschten Sicherheitsniveaus umgesetzt. Hier hat ein Entwickler die Wahl zwischen den Niveaus LOW, MEDIUM, HIGH. Das Sicherheitsniveau HIGH würde intern dann beispielsweise zur Wahl der PQC Verfahren McEliece und SPHINCS+ führen.

Abbildung 1 zeigt das Klassendiagramm der eUCRITE-API. Die Klasse EasyEncrypter enthält Funktionen zur Ver- und Entschlüsselung, die Klasse EasySigner zur Signierung und Verifizierung von Daten. Beide Klassen nutzen einen KeyManager zur Speicherung des Schlüsselmaterials. Je nach Algorithmus wird ein StatelessKeyManager oder StatefulKeyManager verwendet. Bei der Erzeugung eines neuen Schlüsselpaares werden durch AlgorithmParameters der verwendete Algorithmus sowie dessen Parameter festgelegt. StorageParameters geben den Speicherort des Schlüsselmaterials an.

Die Usability der eUCRITE-API wurde in einer Reihe von vorgelagerten Nutzerstudien untersucht. Bei der zu diesem Zeitpunkt letzten Studie [15] wurde ein API-Usability Score nach Acar [2] von 70,5 (aus maximal 100) erzielt. Im direkten Vergleich hat die API tink⁷⁷7https://github.com/google/tink (besucht am 29.12.2020) einen Score von 48,23 erreicht. In einer früheren Studie wurde insbesondere die Benutzbarkeit von zustandsbehafteten Verfahren in der eUCRITE-API untersucht ([28]).

Das Codebeispiel in Listing LABEL:list:classicBC zeigt – vereinfacht – Methodenaufrufe für die Signierung mit einem klassischen Verfahren (SHA256 und RSA) mithilfe der Implementierung von Bouncy Castle, welcher als Provider über die Java Cryptography Extension (JCE) eingebunden wird.

Um auf ein PQC Verfahren zu wechseln, müsste hier die erste Zeile mit dem Codebeispiel aus Listing LABEL:list:pqcBC ersetzt werden, die Zugriff auf PQC-Verfahren von Bouncy Castle erlaubt. Beide Codebeispiele illustrieren, dass ein Entwickler eine Reihe von technischen Parametern kennen und korrekt anwenden muss, z.B. den Namen und die Bitlänge des zu verwendenden Hash-Algorithmus.

⬇

1Signature sig = Signature.getInstance("SHA256withRSA", "BC");

2sig.initSign(privateKey);

3byte[] toBeSigned = "Hallo␣Welt!".getBytes();

4sig.update(toBeSigned, 0, toBeSigned.length);

5byte[] signature = sig.sign();

Listing 1: Signieren von Daten (klassisch) mit BouncyCastle

⬇

1Signature sig = Signature.getInstance("SHA3-512WITHSPHINCS256", "BCPQC");

Listing 2: Neue Zeile 1: Signieren von Daten (PQC) mit BouncyCastle

⬇

1AlgorithmParameters algorithmParameters =

2 AlgorithmParameters.Template.Signature.Security_Level.HIGH.getParameters();

3KeystoreParameters keystoreParameters = new KeystoreParameters(keyStoreFile, "password");

4EasySigner signer = EasySigner.withNewKey(algorithmParameters, keystoreParameters);

5byte[] signature = signer.sign("Hallo␣Welt!");

Listing 3: Signieren von Daten mit der eUCRITE-API

In eUCRITE kann hingegen das bereits erwähnte Template verwendet werden (siehe Codebeispiel in Listing LABEL:list:pqcEucrite). Die Wahl des Sicherheitslevels HIGH für Signaturen führt intern z. Zt. zur Auswahl von SHA3-512 und SPHINCS+.

In einem späteren Schritt soll eUCRITE durch einen Update Mechanismus stets ein zur Laufzeit als sicher geltendes Verfahren ausgewählen, d.h. sollte SPHINCS+ in Zukunft gebrochen werden, würde hier ein anderer Algorithmus zum Einsatz kommen.

3.2 InboxPager (Android E-Mail Client)

Als erster Untersuchungsgegenstand zur Integration von PQC-Verfahren auf Basis der eUCRITE-API wurde ein E-Mail Client ausgewählt, da hier sowohl asymmetrische Verschlüsselung als auch Signaturen zum Einsatz kommen. Die Auswahl des Clients erfolgte auf Basis der folgende Kriterien:

1.

Klassische Kryptographie-Verfahren müssen bereits integriert sein
2.

die kryptographischen Funktionen sind gut getrennt vom restlichen Code
3.

die Anwendung ist nicht zu umfangreich
4.

die Anwendung ist in Java geschrieben.

Durch eine erste Recherche standen die folgenden drei E-Mail Clients zur Auswahl: K9 [26], InboxPager [16] und FairMail [1]. Anhand der oben genannten Kriterien fiel die Wahl auf InboxPager (Version 4.5).

Abbildung 2 zeigt die Abhängigkeiten der verwendeten kryptografischen Bibliotheken. In der überarbeiteten InboxPager Implementierung werden die Funktionen zur Verschlüsselung und Signierung der E-Mails über die eUCRITE-API implementiert. Intern greift diese, abhängig vom Krypto-Verfahren, auf verschiedene Provider zurück. Die beiden PQC Verfahren Classic McEliece und SPHINCS+ werden über die MTG PQC Extension⁸⁸8Siehe Abschnitt 4.2 des Bouncy Castle Providers angesprochen.

Für weitere Details wird auf die Bachelorarbeit von [27] verwiesen, in deren Rahmen wesentliche Teile der Integration entstanden.

3.3 TLS Implementierung in Bouncy Castle

Aufgrund der zum Durchführungszeitpunkt immer noch sehr weiten Verbreitung von TLS 1.2 (vgl. [10]) sowie der Verfügbarkeit einer TLS 1.2 Implementierung in Bouncy Castle (Version 1.66) wurde die Integration der eUCRITE-API in diese TLS Implementierung untersucht. Wesentliche Teile der Integration sind im Rahmen der Bachelorarbeit von [20] entstanden.

Listing 4: Verwendete Cipher Suite Definition

⬇

1public static final int TLS_CME_SPX_WITH_AES_25_CBC_SHA512 = 0x1306;

Wie in Abschnitt 1 erwähnt, lag der Fokus dieser Arbeit auf dem Austausch der asymmetrischen Krypto-Verfahren in einem hybriden Kryposystem wie TLS. Da zum aktuellen Zeitpunkt seitens der IANA noch keine passende TLS Cipher Suite mit PQC-Verfahren definiert ist [5], wurde für die Implementierung der Wert 0x1306 verwendet, der noch nicht von der IANA vergeben wurde⁹⁹9Status unassigned (siehe Listing LABEL:list:def).

Der PQC-basierte TLS Handshake lief erfolgreich zwischen zwei Knoten ab, die beide die neue Cipher Suite verarbeiten konnten. Die Analyse des Datenverkehrs mithilfe von Wireshark meldet erwartungsgemäß an dieser Stelle eine unbekannte Cipher Suite (siehe Abbildung 3).

4 Erkenntnisse

Im Folgenden wird auf die wesentlichen Hürden eingegangen, die bei der Integration der PQC-Verfahren in hybride Krytosysteme auftraten. Diese lassen sich in konzeptionelle/organisatorische (Abschnitt 4.1) und technische Aspekte (Abschnitt 4.2) unterscheiden.

4.1 Konzeptionelle/organisatorische Aspekte

Die eUCRITE-API bietet bei der Wahl der Krypto-Verfahren eine höhere Abstraktion als herkömmliche Bibliotheken. Ein Entwickler spezifiziert zur Compile-Zeit nur noch sein gewünschtes Sicherheitslevel (LOW, MEDIUM, HIGH). Intern wählt eUCRITE dann die passenden Krypto-Verfahren aus. Beispielsweise könnte für LOW noch RSA ausreichend sein, während HIGH bereits auf das Quantencomputer-resistente McEliece-Verfahren zurückgreift. Diese genau spezifizierte Angabe zur Wahl des Krypto-Verfahrens wird dann z.B. im TLS-Handshake verwendet. Hier offenbart sich eine semantische Unschärfe, sollten eUCRITE-basierte Kommunikationspartner zu unterschiedlichen Compile-Zeiten unterschiedliche Verfahren für ein Sicherheitslevel ausgewählt haben. Ein Sicherheitslevel HIGH im Jahr 2021 könnte zur Wahl eines anderes Verfahrens führen als ein Sicherheitslevel HIGH im Jahr 2031. Es muss also eine Möglichkeit geschaffen werden (z.B. über einen Update Mechanismus der eUCRITE-API oder durch Versionsnummern der eUCRITE-API) dies zu erkennen und programmtechnisch zu behandeln.

Zum jetzigen Zeitpunkt fehlen Spezifikationen für Cipher Suites, die PQC-Verfahren unterstützen. Es gibt erste Ansätze¹⁰¹⁰10z.B. https://tools.ietf.org/html/draft-campagna-tls-bike-sike-hybrid-01 (besucht am 29.12.2020) , die jedoch nicht alle Kombinationen von Verfahren abdecken. So haben wir für unsere Umsetzung TLS_CME_SPX_WITH_AES_256_CBC_SHA512 gewählt. In Folge einer Standardisierung könnte dieser Wert ungültig werden.

4.2 Technische Aspekte

Die Analyse des Netzwerkverkehrs unserer prototypischen Implementierungen zeigt, dass bei unserem TLS Handshake, basierend auf McEliece, ca. 1.5 MB an Nutzdaten bei der Übermittlung des Zertifikats anfallen. Diese Beobachtung deckt sich mit anderen Arbeiten [25, 17, 7] und könnte sich negativ auf die User-Experience beim Surfen im Internet auswirken, da der TLS Handshake zu viel Zeit konsumiert, insbesondere bei sog. lossy networks verschärft sich dieses Problem [22].

Unsere Wahl der Programmiersprache Java für die eUCRITE-API und die E-Mail Anwendung InboxPager sowie die Bibliothek Bouncy Castle zog die folgenden technischen Anpassungen nach sich: Die Implementierung der PQC-Verfahren wurde uns in Form einer Erweiterung der Bouncy-Castle-Bibliothek durch unseren Projektpartner, der MTG AG aus Darmstadt [3], bereitgestellt, die aus Gründen der Performance über das Java Native Interface die eigentlichen Algorithmen nah an der Ziel-Hardware in der Programmiersprache C umsetzt und auf Prozessorarchitektur-Optimierungen setzt. Dies limitiert die Portabilität unserer Lösungen.

Weiter ist es aufgrund der Größe des McEliece Schlüsselmaterials notwendig, die Größe des JVM Thread Stack zu erhöhen, da das Schlüsselmaterial über den Stack an die native C-Anbindung (via Java Native Interface) übergeben wird.

Schließlich sei erwähnt, dass das Android OS bereits mit einer Bouncy-Castle-Bibliothek als Java Cryptographic Service Provider ausgeliefert wird. Dieser Provider muss zunächst deaktiviert werden, da es ansonsten zur Auswahl des falschen Providers kommt. Weiter wird Google für Android in Zukunft obligatorisch auf Conscrypt¹¹¹¹11https://conscrypt.org (besucht am 29.12.2020) als Implementierung für die klassischen Krypto-Algorithmen setzen, was für die Integration von PQC-Verfahren Anpassungen beim Zusammenspiel mehrerer Provider erfordern wird.

5 Fazit und Ausblick

5.1 Fazit

Die vorliegende Arbeit berichtet über praktische Erkenntnisse bei der Integration von PQC-Verfahren in bestehende Softwareprodukte. Die Integration erfordert zum Teil detaillierte Kenntnisse bzw. Änderungen an der Laufzeitumgebung, wie der beobachtete Thread-Stack-Fehler zeigt. Um die Interoperabilität zwischen (beliebigen) Anwendungen sicherstellen zu können, bedarf es weiterer Standardisierung, z.B. bezüglich der zu verwendenden Konstanten für Cipher Suites. Der Punkt Endbenutzerfreundlichkeit bedarf ebenfalls der Aufmerksamkeit. So müssen z.B. die PQC-Algorithmen hardwarenah ausgeführt werden, um eine akzeptable Wartezeit zu erreichen. Obwohl die Integration von PQC in TLS-1.2 technisch erfolgreich war, ist es anzuraten hier auf modernere Protokolle (z.B. TLS-1.3 oder Google QUIC) zu setzen, da diese den Overhead zum Aufbau einer Sitzung, und damit die Ausführung von PQC-Verfahren deutlich reduzieren werden.

5.2 Ausblick

Weiterführend soll das korrekte Zusammenwirken der hier vorgestellten Abstraktionsmechanismen über System-, und Zeitgrenzen untersucht werden. Hierfür wird, insbesondere für die zeitliche Komponente, der erwähnte Update-Mechanismus von Bedeutung sein. Neben der Durchführung von weiteren Integrationen und Tests sollen die erzielten Ergebnisse in das Design und die Funktionalität der eUCRITE-API zurückfließen.

Danksagung

Dieser Beitrag wurde im Rahmen der Innovationsförderung des Landes Hessen aus Mitteln der LOEWE – Landes-Offensive zur Entwicklung Wissenschaftlich-ökonomischer Exzellenz, Förderlinie 3: KMU-Verbundvorhaben unter HA-Projekt-Nr.: 633/18-56 gefördert.

References

[1] Marcel Bokhorst (M66B) “FairEmail - Open source, privacy friendly email app for Android” URL: https://email.faircode.eu
[2] Yasemin Acar et al. “Comparing the Usability of Cryptographic APIs” In 2017 IEEE Symposium on Security and Privacy (SP), 2017, pp. 154–171
[3] MTG AG “MTG AG - IT-Security für kritische Infrastrukturen” URL: https://www.mtg.de/de/start/index.html
[4] “Biggest Failures in Security” 9.11, Dagstuhl Reports Dagstuhl Publishing, 2019, pp. 1–23
[5] Internet Assigned Numbers Authority “Transport Layer Security (TLS) Parameters” URL: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[6] Daniel J Bernstein et al. “SPHINCS: practical stateless hash-based signatures” In Annual International Conference on the Theory and Applications of Cryptographic Techniques, 2015, pp. 368–397 Springer
[7] Kevin Bürstinghaus-Steinbach, Christoph Krauß, Ruben Niederhagen and Michael Schneider “Post-Quantum TLS on Embedded Systems”, 2020 URL: https://eprint.iacr.org/2020/308
[8] Matthew Campagna et al. “Quantum Safe Cryptography and Security: An introduction, benefits, enablers and challenges” In European Telecommunications Standards Institute ETSI White Paper.8, 2015, pp. 1–64 URL: https://www.etsi.org/images/files/ETSIWhitePapers/QuantumSafeWhitepaper.pdf
[9] Lily Chen et al. “Report on Post-Quantum Cryptography” US Department of Commerce, National Institute of StandardsTechnology, 2016 DOI: 10.6028/NIST.IR.8105
[10] Eric Crockett, Christian Paquin and Douglas Stebila “Prototyping post-quantum and hybrid key exchange and authentication in TLS and SSH” NIST, 2019
[11] Lov K Grover “Quantum mechanics helps in searching for a needle in a haystack” In Physical review letters 79.2 APS, 1997, pp. 325
[12] User-Centered Security Working Group (CS Dept. h_da) “eUCRITE API” URL: https://use-a-pqclib.h-da.io/eucrite-documentation/
[13] User-Centered Security Working Group (CS Dept. h_da) “Projekt - Use-A-PQClib” URL: http://fbi.h-da.de/ucs
[14] Udyani S Herath Mudiyanselage “Next-Generation Web Public-Key Infrastructure Technologies”, 2019 DOI: 10.5204/thesis.eprints.128643
[15] Rolf Huesmann, Alexander Zeier, Andreas Heinemann and Alexander Wiesmaier “Zur Benutzbarkeit und Verwendung von API-Dokumentationen” In Mensch und Computer 2020 - Workshopband Bonn: Gesellschaft für Informatik e.V., 2020 DOI: 10.18420/muc2020-ws119-002
[16] GitHub itprojects “An E-mail client for the Android platform. Imap, pop, and smtp via SSL/TLS, with AES/PGP support.” URL: https://github.com/itprojects/InboxPager
[17] Panos Kampanakis, Peter Panburana, Ellie Daw and Daniel Van Geest “The Viability of Post-quantum X.509 Certificates”, 2018 URL: http://eprint.iacr.org/2018/063
[18] Tyson Macaulay and Richard Henderson “Cryptographic Agility in Practice”, 2019
[19] Robert J McEliece “A Public-Key Cryptosystem Based on Algebraic Coding Theory” In Coding Thv 4244, 1978, pp. 114–116
[20] Matthias Merz “Integration von Post Quantum Verfahren in Bouncy Castle als Grundlage für eine Evaluation der Usability der eUCRITE API”, 2020
[21] David Ott and Christopher Peikert “Identifying Research Challenges in Post Quantum Cryptography Migration and Cryptographic Agility” arXiv: 1909.07353 In arXiv:1909.07353 [cs], 2019 URL: http://arxiv.org/abs/1909.07353
[22] Christian Paquin, Douglas Stebila and Goutam Tamvada “Benchmarking Post-Quantum Cryptography in TLS”, 2019 URL: http://eprint.iacr.org/2019/1447
[23] Peter W. Shor “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer” In SIAM J. Comput. 26.5 Philadelphia, PA, USA: Society for IndustrialApplied Mathematics, 1997, pp. 1484–1509 DOI: 10.1137/S0097539795293172
[24] Bundesamt Sicherheit in der Informationstechnik “Migration zu Post-Quanten-Kryptografie”, 2020 URL: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Krypto/Post-Quanten-Kryptografie.html
[25] Dimitrios Sikeridis, Panos Kampanakis and Michael Devetsikiotis “Post-Quantum Authentication in TLS 1.3: A Performance Study” In Proceedings 2020 Network and Distributed System Security Symposium Internet Society, 2020
[26] K9 Team “K9 Mail” URL: https://k9mail.app
[27] Basset Yousofzai “Integration von Post-Quanten-Kryptographie Verfahren in einen Android Open-Source Java E-Mail-Client”, 2020
[28] Alexander Zeier, Alexander Wiesmaier and Andreas Heinemann “API Usability of Stateful Signature Schemes” In International Workshop on Security, 2019, pp. 221–240 Springer