 The next talk is called The Year in Post-Quantum Crypto by Daniel Lange, who is researching in Eindhoven. Daniel Bernstein und Daniel Lange aus den Universitäten Chicago und Eindhoven. Sie haben die erste ever Konferenz auf Post-Quantum-Kryptografie im Jahr 2006. Sie haben über Post-Quantum-Kryptografie 2006 gehalten. Der Talks wird ein Summary der NIST Post-Quantum-Krypto-Kompetition. Sie tragen weiter in der Bibliothek zur Post-Quantum-Kryptografie. Sie hoffentlich hat es zu integrieren Post-Quantum-Krypto in existenten Software. Sie versuchen diese Post-Quantum-Krypto in existenten Software zu integrieren. Bitte Applaus. Das ist die Übersetzung von Kaste und Jopdy. Wir übersetzen für euch ins Deutsche. Viel Spaß. Vielen Dank. Der Titel bedeutet, wir reden über Kryptografie. Wir designen unter dem Aspekt, dass der Angreifer einen großen Quantencomputer hat. Nicht der Benutzer, aber der Angreifer. Also wir reden hier von Angreifern. Was wir die letzten Jahre gesehen haben, 2015, da gab es eine große Ankündigung der NSA. Das geht tatsächlich auch um Forschung in Post-Quantum-Krypto. Und direkt danach haben sich alle anderen Agencies durchgerungen, was Ähnliches zu verlaut waren. Über die Zeitliche Tränke, die wir implementieren. Und nach einem öffentlichen Input-Phase hat dann die NIST auch Einreichungen für Stabilisierungen, für ein Stabilisierungsprojekt, für Postkonten-Kryptografie ins Leben gerufen. Also ja, es ist eine US-Einrichtung, aber es hat in der Vergangenheit einen relativ guten Beruf gehabt. Und bisher ist es nicht bekannt, dass da kein Problem mehr werden. Die haben zum Beispiel auch Schaar-Implement standardisiert. Und die Competitions bei der NIST, die sind wahrscheinlich eine gute Sache, über alles andere kann man sich noch streiten. Und Dan hier auf der Bühne hat den Term Postkonten-Kryptografie benannt als Erster. Der hat ihn eingeführt und 10 Jahre danach erst hat die NSA zugegeben, dass da wirklich was zu tun ist. Wir haben die ganze Zeit schon versucht, Leute dazu zu kriegen. Aber ja, wir können nicht mehr sagen, als wir haben es euch ja gesagt. Ja, also die NIST hat dann gesagt, ja, sendet uns da mal was rein. Und viele haben es gemacht. Also über 80 sind reingekommen und ein paar von denen waren nicht so komplett. Die hat man dann wieder rausgenommen, aber 69 davon haben es dann durchgeschafft. Von 260 Leuten, von überall von der Welt, Akademie, Industrie und so weiter. Hat hier viele Namen. Wir werden die dann nicht alle einzeln angucken. Wir haben ja auch nur 60 Minuten. Ja, genau. Wir geben hier da einen kleinen Überblick, überall diese Einreichungen. Und am 21. Dezember, also letztes Jahr, wurden die da veröffentlicht. Die, die unseren Talk letztes Jahr geschaut haben, haben gesehen, ja, da hat es schon ein bisschen Schaden angerichtet. Da wurden schon acht von diesen Einreichungen herausgelichtet. Hier hat es eine Farbkodierung. Das braune ist weniger sicher, als dass sie eigentlich behauptet haben, wie zum Beispiel anstatt 2 zu 200 werden es dann 2 hoch 80 Operationen um irgendwas zu brechen. Und bei den Roten, hier sieht man, ja, die sind eigentlich wirklich angreifbar. Die Roten ist alles, wo, bei den Roten ist alles, was behauptet wurde, eigentlich wirklich, das stimmt nicht, also da geht, da demonstriert, dass die komplett kaputt sind. Das war Ende 2017. Und wie schaut es denn heute aus, also in drei Tagen, Ende 2018 werden wohl 22 von 69 Einreichungen angreifbar sein. Ihr seht hier, die 13 von diesen sind rot und vor allem auch unter Strichen. Einige von uns, einige von anderen Leuten, da haben wir auch etablieren können, dass Leute hier Skrips schreiben, die Angreifangriffe demonstrieren können auf diese Einreichungen. Wenn man das hier jetzt so anschaut, wir werden jetzt hier nicht im Detail durchgehen, aber kategorisieren wir die kurz mal. Wir haben hier die, die nicht so ganz kaputt sind. Was ist das mathematische Problem hier? Wie können wir die eigentlich da einführen? Es gibt eine Kategorie von den Fair Breaking Codes, die verwendet man um Unterschriftungssysteme zu verwenden. Dann gibt es isogeniebasierte Verschlüsselungen, die sind, was wir so gesehen haben, relativ ineffizient. Dann gibt es sehr glattes Base-Systeme, das sind die, die wir letztes Jahr ein bisschen erklärt haben, mit der wir den vom letzten Jahr anschauen. Und dann gibt es noch welche, bei denen es viele Variable und viele Systeme gibt, die bis zu losengilt. Das ist diese multivariate-quadratische Verschlüsselung. Das bedeutet nicht, dass alles, was in diesen Boxen in diesen Schachteln ist, sicher ist. Manchmal kann es sein, dass ein Angreifer einfach einen Bektrum rumfindet und gar nicht das System selbst angreift. Das ist zum Beispiel die oberen. Es gibt eines der, zum Beispiel eines, das hat, das ist in der oberen Kategorie, also das ist ein codebasiertes System, aber es ist trotzdem angegriffen worden. Aber es hilft uns manchmal, die Dinge einfach zu kategorisieren und zu schipladen. Jetzt wollen wir erklären, was die Situation genau ist. Also manche sagen einfach, was sicher ist, ist, dass man letztes Base-Kryptografie verwirrt und dass alles andere nicht wirklich funktioniert. Wenn man das aber genau ansieht, dann gibt es immer noch Dinge, die rot sind. Also das bedeutet, die haben schon einen Angriff oder die sind zumindest nicht so sicher wie gedacht. Das heißt, auch die Lattes basierten, die wirklich sich gut gehalten haben. Und es sind auch nicht nur einzelne Fehler, die dabei gemacht wurden, sondern es gibt auch Paper, die zeigen, dass da auch grundsätzliche Probleme bestehen können. Wenn wir darüber reden, dass die gebrochen werden können durch Entschlüsselungsfehler, dann ist es so, dass manche dieser Systeme gelegentlich Entschlüsselungen haben. Also z.B. also was wie einst ist zu 10, minus 6. Das heißt, gelegentlich passiert was, und es ging erst mal nicht so schlimm. Das heißt, dass z.B. der Braut sich einfach neu verbinden muss. Aber so simpel ist das nicht, weil wenn der viele den Angriff verhelfen können, wenn er den versucht, den schiffrierten Text zu entschliessen, das kann es ihm helfen, das zu knacken, dadurch, dass er einfach die Fehler beobachtet beim Entschlüsseln und die Fehler, die Paper sagen jetzt, dass diese Fehler unter gewissen Bedingungen systematischerweise häufiger passieren und das dann helfen dabei, das zu entschliessen. Dann gibt es noch eine Aussage, dass vieles aus dem Portfolio des europäischen Pickel-Krypto-Projekts sicher wäre. Es klingt erst mal gut, aber es ist ein bisschen besser als bei den Lettespaces. Es gibt eins, es ist ein bisschen braun, das bedeutet, es ist nicht ganz so sicher wie gedacht, aber es kann auch einfach sein, dass es noch eine andere Erklärung gibt. Und zwar, dass es halt eher die Leute sind, die das machen. Aber es gibt auch noch die andere Möglichkeit, dass die Kryptoanalisten sich überlegen, dass aus dieser großen Menge von 69 Möglichkeiten, die sie angreifen können, dass sie auch einfach sagen, nehme ich jetzt die, die das schon jahrelang machen, oder schaue ich mir lieber die anderen an, die deutlich schwieriger sind, weil sie wahrscheinlich, weil die deutlich einfach sind, weil sie einfach von einer externen Firma kommt, wo nicht unbedingt die Experten daran gearbeitet haben, wie z.B. bei Microsoft oder so. So rein zuviel, ich war auch Microsoft, eins von denen, das funktioniert halt. So, ihr müsst euch halt immer in Erinnerung halten. Es gibt ungefähr, es gibt knapp 70, das ist, ich würde sagen, mehr Effort als eine Million Lange zu kochen. Das ist eine lote, das ist mehr als eine Million Zeit, zahlen einen Code und das ist eine ganze Flutankode, den man da durchwarten muss. Und die Leute müssen einfach eine Auswahl treffen und die nehmen wahrscheinlich einfach die einfachsten Ziele. Das heißt, wenn du wirklich Sicherheit haben willst, dann musst du dir überlegen, dass du diesen Genial of Service Attacke einfach im Kopf hast. Und das ist im Moment so, dass es einfach so viele Einreichungen gab, dass die Leute, die sowas normalerweise angreifen, gar nicht die Zeit haben, das alles anzugucken. Also wir bitten euch, dass ihr uns helft und dass ihr uns unterstützt, es zu knacken, aber bitte nicht in so einen eigenen Tisch. Wir haben tatsächlich jetzt auch eine ganze Reihe Leute, die sich interessieren für Postkonten, Kriptografie. Das ist die Konferenz, die wir dazu gemacht haben. Und dies sind jetzt 350 Leute, die wir 2018 dafür gekriegt haben. Für Akademiker ist das riesig. Es gibt wirklich ein sehr großes Interesse an diesem Thema im Moment. Und die Leute schauen wirklich, und das sind gute Nachrichten für uns. Das ist ein... Sie hoffen einfach, dass dieses Ding nicht geknackt ist. Und wir haben jetzt die Parameter immer wieder gerecht. Die Schlüssel und die Signaturen könnten mehrere Terabyte groß sein bei diesem Verfahren. Das Problem ist hier natürlich, dass man sowas schon gar nicht mehr angreifen kann, weil einfach die Oramedingungen zu schlecht sind. Nächster ist sich da bewusst, dass da eine DOS-Tacke stattfinden. Das ist ein Problem, dass die Leute, die die DOS-Tacke angreifen, auf der Konferenz gesagt haben, also wenn ihr ähnliche Einreichungen habt, dann schaut doch, ob ihr das irgendwie zusammenführen könnt. Und dann haben wir da eine kombinierte Einreichung, die wir dann einfach analysieren können. Sie haben versucht, zu garantieren, wir akzeptieren hier eine Konferenz. Das ist das Problem, dass die Leute, die die DOS-Tacke angreifen, versuchen zu garantieren, wir akzeptieren hier eine kombinierte Einreichung bis in die zweite Runde. Also, könnte man hier das jetzt angreifen, wenn man eine gute Einreichung hat und dann noch eine schwache hat, dann kann man die irgendwie kombinieren und dann kommt die schwache Einreichung auch in die zweite Runde. Aber Nester hat dann gesagt, dass man nur die ähnlichen Einreichungen zusammenführen und das müsste dann eine irgendwie Kombination sein, der zwei ursprünglichen Einreichungen. Weil das Beispiel hier, Nester hat nicht unbedingt gesagt, dass man das auch veröffentlichen muss. Healer 5 und Round 2 wurden da zusammengeführt. Das war schon nach Healer 5, nach dem Angriff auf Healer 5 und die haben da Round 5 gemacht und haben dann gesagt, ja, das ist ein führender, Gitterbasierter Kandidat für Sicherheit und Bandpreiter und CPU Performance. Ja, und dann schon nur zwei, drei Wochen später hat sich herausgestellt, ja, es gibt eine starke Gründe zu glauben, dass das hier doch nicht funktioniert mit der Entschlüsselung und die haben dann das akzeptiert und gesagt, ja, Ups, das haben wir nicht richtig gemacht. Und mit diesen Entschlüsselungsfehlern kann man die Sicherheit des Systems angreifen. Und das war auch ein interessanter Angriff, weil bei der Kombination sollte man ja eigentlich die zwei besten Sachen von den einzelnen Einreichungen zusammenführen. Und interessanterweise war dieser Fehler gar nicht in der originalen Implementation hier in der Einreichung. Und ja, wie sollte man das denn beheben? Wir machen hier da eine Sicherheitsbeweisupdate und dann sollte das so in mehreren Runden gehen und da iterieren die da noch über ihre Einreichung und was bedeutet denn hier jetzt diese Sicherheitsbeweis? Was bedeutet der, wenn man den dann überhaupt noch anpasst im Anschluss da ziemlich seltsam? Dann gab es noch mehr Zusammenführungen. Sie haben dann behauptet, ja, das ist jetzt ein führender Kandidat hier für Sicherheitsanalyse und Netzwerkanalyse und Flexibilität. Da könnte man dann erst mal mit Gigabyte oder Terabyte Schlüssel nutzen und da würde man dann natürlich auch die Bandbreite erhöhen. Wenn man die, ja, Menge von verschlüsselten Zeugs dann misst, dann geht das hoch und da kommen mehr und mehr Zusammenführungen zusammen und das vereinfacht nicht unbedingt immer da hier die Sicherheitsanalyse und zwei NTRU-Vereinheitlichungen hier. Die haben sich das gut überlegt und das ist jetzt ein Beispiel, wo tatsächlich die Kombination einfacher war zu analysieren als die zwei ursprünglichen Einreichungen. Nach der November-Date-Line hat NIST gesagt, ja, sie werden die zweite Rundekandidaten veröffentlichen und vielleicht wird das jetzt da ein bisschen kleiner von der Anzahl her, dass man das analysieren kann und das sollte am 10. Januar dann veröffentlicht werden und eine Woche nachdem sie gesagt haben, dass sie das veröffentlichen würden und ja, jetzt hat die USA noch ein Problem mit der Regierung, dass die da ein Shutdown macht und dann ist es so, dass NIST nicht unbedingt zum essentiellen Teil gehört und deshalb sind die dann nicht dazu befugt, Arbeit zu führen. Und auch die Datenbank, die die NIST-Website betreibt, darf dann auch nicht bearbeitet werden. Vielleicht bezahlen sie ja Oracle und dann verschwindet die Zahlung an Oracle und dann funktioniert die Datenbank nicht mehr, also es ist nicht ganz klar hier, aber irgendwie, ja, man findet hier nichts mehr. Wir wissen dann nicht genau, wie lange dieser Shutdown dauern wird. Es gibt natürlich Leute, die sagen, ja, es wird kein Problem sein, weil wir können das ja auch ohne diesen Wettbewerb herausfinden, wie wir das machen könnten. Ja, also kommen jetzt die Quantencomputer. Ja, das wissen wir nicht, aber was wir anschauen können, ist, wie weit geht denn hier die Forschung mit Quantencomputern? Hier haben wir ein kleines Startup, der gesagt hat, ja, wir haben hier ein Quantencomputer entwickelt aufgrund von Eigentraps. Und hier sehen wir nun wieder ein Rennen zwischen verschiedenen Technologien und wir sehen auch, wer da vielleicht gewinnen könnte. Auf jeden Fall, es sieht so aus, als ob das kommt. Und hier, ja, was ist der Unterschied oder welches ist der Quantencomputer und welches ist die Micro-Brauerei hier? Wisst ihr, welches ist welches? Mit all diesen Neuigkeiten sagt jetzt die Nationalakademie der Wissenschaften, dass die hier noch ein Journal herausgegeben haben, jetzt ein Bericht über Quantenberichtung, Quantencomputing mit einem Schlüsselergebnis. Ja, keine Panik. Wir glauben jetzt nicht, dass in den nächsten 10 Jahren irgendetwas passieren würde, dass RSA 2048 überhaupt gefährden würden oder die elliptischen Kurven mit dem diskreten Logarithmsproblem. Ja, es hat jetzt halt nicht nur einer, aber also dann bis Nummer 10, dann kommt hier Panik. Wir haben hier ein Gefahr, dass die Möglichkeiten mit so einer Maschine so hoch sind, dass wir Postquanten-Kryptografie sofort müssen herausrollen, weil das ist kritisch, um die Sicherheits- und Privatspferndesage zu verhindern. Also, was können wir tun, um das zu verhindern? Manche Leute behaupten, wir haben das schon längst ausgerollt. Die Frage ist, wie hängt das zusammen mit den NIST-Einreichungen? Die Frage ist tatsächlich die Größe. Das ist das Hauptproblem für die meisten Einreichungen in der Postquanten-Kryptografie. Was man hier auf dem Bild sieht, ist, auf der horizontalen Achse sieht man die Länge des Kiefs, nicht alle Signaturesysteme. Also alle, die nicht in den ersten fünf Versionen mit einem Skript schon kaputt gemacht wurden. Also ohne RSA, was sind sie gerade so verzert? Es ist die Zukunft von Kryptografie, die Postquanten und RSA, ob ich sie... Was man hier sehen kann, ist, die Größe-Einreichung da unten, wenn man die Signature-Größe auf 32 runterkriegen kann, aber man braucht dann halt irgendwie 100.000 Zeichen in seinem Schlüssel. Und da gibt es drei verschiedene Sicherheitslevel und vielleicht sind die auch nicht alle gleich kräftig in ihrer Verschlüsselungsstärke. Wir wissen auch, wie sicher die Symptone in die Analyse zum Betreiben, aber umso ziemlich alles ist möglich, also sowas wie unter 100 Bytes für die Größe des Kies und unter 100 Bytes für die Größe der Signature. Also in der alten Kryptografie war das einfach, dass sowas möglich war. Aber das ist heutzutage nicht mehr möglich in der Postquanten-Kryptografie. Ihr seht ja, wie groß es hier die jeweiligen Aspekte sind. Man muss jeweils ein Trail-off machen, was einem wichtiger ist an der Stelle. Aber es gibt nichts, was wirklich klein ist in beiden Dimensionen. Das ist jetzt der nächste Graf, der jetzt wieder über Verschlüsselung. Es gibt hier mehr Einreichungen für die Verschlüsselung. Hier gibt es wieder nicht so richtig tolle Größen. Die größte Hinsicht auf die Größen ist die Einreichung, die heißt Psyche. Sie sind etwas kleiner als 1.000 Bytes für die Größe des Schiffertecks und für den Schüssel. Alles andere ist ein bisschen größer. Man kann zum Beispiel runter auf 100 Bytes für die Größe des Schiffertecks und den öffentlichen Schüssel, der größer macht, also z.B. der rechten Seite bei NTS. Wenn man jetzt den nächsten Graf anschaut, wenn man alles kleiner wird als 1200 Bytes, und dann ein paar andere Möglichkeiten, was sind die Sicherheitslevel für diese verschiedenen Einreichungen? Wie viele von denen wurden schon untersucht? Das ist relativ gruselig eigentlich, weil meist davon ist er einfach noch unbekannt. Also ja, Größe ist entscheidend. Das ist jetzt ein Google Cloud-Fair Experiment. Wir wollten wissen, was die Resultate dieses Wettbewerbs sind. Deswegen haben wir jetzt mal geguckt, was passiert, wenn man verschiedene Größen dieser Verschüsselung über das Internet schicken und das ist jetzt mit Cloud-Fair gemacht. Das heißt, sie wissen sehr genau, wie das mit der Verteilung über die Welt aussieht. Jetzt haben sie wieder diese super-singuläre Isogenie versucht. Das sind nur 400 Byte, bei strukturierten Gitter sind es 1100 Byte. Und die Zereins sind so mehr oder weniger korrekt, die man hier sieht. Das ist unschuldig. Die sind so ungefähr von der Größe der MTU, also so 1100 Bytes. Ein bisschen zugewinnen, aber immer noch unter 20% immer kann, aber was die Internet verteilen. Aber mit den unstrukturierten Gittern ist es so, dass über 10K dann einfach zu viele Seiten verwarfen, zum Beispiel bei LinkedIn. Weil 10K sind schlechter als 9999. Die sind dann mit 3300 Bytes und können dann mit dem Faktor 3 multipliziert. Die Zunahme in der Latence sind nicht mehr akzeptabel. Es sind die kleinsten, aber auch die langsamsten, Aber es sind die einzigen, bei denen die Geschwindigkeit ein sehr, sehr viel größeres Problem als die Größe. Aus dem Grund hat Google gesagt, wir können es nicht verwenden. Es ist ein relativ neuartiges System und es ist erst 2012 und deswegen ist es auch noch ein bisschen fragwürdig, wie die Sicherheit ausschaut. Sie bauen jetzt da noch so ein strukturiertes Guitarsystem mit Jostreinfeld-Peterschwabe und Hansgang. Super für Eindhoven. Sie bauen jetzt ein System, das ist eine kombinierte elliptische Kurve und mit Postkonten. Das wird jetzt mal bald zu ein paar Browsern kommen. Nächstes ist ja nicht das Einzige. Die Internet Research Task Force hat hier auch noch was standardisieren wollen. Das Extended-Mehr-Klassiknaturenschema. Es ist nicht sehr schnell, aber es ist das erste Mal, dass die IETF da ein Postkonten-RFC publiziert hat. Da ist also noch sehr viel Text drin, der gar nicht wirklich mit dem Inhalt zu tun hat, der halt mit dem ganzen Postkonten-Problematik hier zu tun hat. Es ist jetzt keine der NIST-Einreichungen, weil sie nicht alle Kriterien erfüllt hier für Signaturen. Die Signature erwartet hier einen öffentlichen Schlüssel, mit dem man die Signature dann überschlüsseln kann. Und hier hat man noch den Status, den man updaten muss. Und wenn man das mal vergisst, dann verliert man hier die Sicherheit. Also ist nicht gleich cool wie eine normale Signature, aber es gibt dann auch genug Anwendungen, wo wir wissen, ja, wie viele Signaturen haben wir denn hier überhaupt schon gemacht. Also es ist nicht unmöglich anzuwenden, aber es ist vielleicht nicht unbedingt was wir hier wollen für Web-Applikationen. Das Gute über XMSS ist, dass die Größe hier viel kleiner ist. Eine andere Größe hat hier mit Glowstick, das kommt von einer Gitter-Einreichung, die Saber heißt. Und Saber hat eine große Version, die heißt Fire Saber, mit Ursicherheit. Und dann eine kleine Sicherheit, die heißt Light Saber, also auch Lichtschwert. Und das Glowstick ist jetzt sogar noch eine kleinere Version von Lichtschwert, die so klein ist, dass sie vielleicht noch nicht ganz kaputt ist. Und hier hat es noch die technischen Details dazu und ist bis jetzt noch nicht ganz gebrochen worden. Ist tatsächlich sehr interessant, ist ein interessantes kleines Sample, das man versuchen kann zu brechen. Also ein relativ simples System, da kann man dann üben, wie man die Sachen hier angreift. So, jetzt der Jahr haben wir da die lustigen Namen. Nein, die Größen. Wieso scheren wir uns da überhaupt um die großen Größen? Google macht jetzt alles irgendwie klein. Wieso sagen dann die Leute, ja, Postquantensystem ist in größer und das ist ein Problem? Hier sehen wir unsere Einreichungen, die haben viel Analysen unterzogen worden. Die haben hier viel Analysen gemacht und bewiesen, ja, das hier ist das gleiche wie das andere. Die haben eine 200-weite Größe, das ist für die Signatur, das ist okay, aber ein megabyte für den Schlüssel. Es geht dann lange, bis man den Schlüssel generiert hat und dann muss man das Ganze noch endkapseln und wieder dekapseln. Das ist ein tolles System, gute Geschichte hier, außer dass hier die Größe des Schlüssel so groß ist. Also Großmutter, warum hast du so einen großen Schlüssel? Also einerseits ist es ein zweidimensionaler Schlüssel, da haben wir links ein Identitätsmatrix mit ungefähr 7000 Spalten und die Höhe L-K ist ungefähr 5000. Die Höhe ist 5000, das heißt, wir haben hier zufällige Daten und natürlich wissen alle, wie ein Identitätsmatrix aussieht, also links die Identitätsmatrix und dann rechts haben wir den zufälligen Teil. Das funktioniert jetzt dadurch, dass der Versender weiß, welche dieser einzelnen Spalten genommen werden und dann XOR'd. Und ja, da muss man halt wissen, welche Spalten sind dann die, die man darf. Und so kommen wir zu diesem 1 megabyte, einer megabyte. Ja, das Problem hier ist natürlich mit der Bandbreite. Ja, also gut, wenn man ein Foto runterladet, dann ist das ja auch megabytes, also das okay. Gut, wenn man auf deutschen Zügen ist, dann ist das ziemlich kacke. Aber sonst in der Welt und mit Mobile funktioniert das. Google hat dann gesagt, ja, wir haben hier ein paar Sachen wieder rausgenommen, also die haben gar nicht mit Classic MacLeese richtig rumgespielt und sogar bei 10.000, die haben da schon verloren Messages gehabt. Aber ja, es ist halt ein sicheres System. Man könnte sogar noch ein sicheres Protokoll damit entwickeln, muss nicht TLS sein. Aber es gibt ein echtes Problem, wenn das Protokoll davon ausgeht, dass der Klient ein 1 megabyte Schlüssel generiert und dann an den Server sendet, dann muss der Server 1 megabyte von jedem Klient akzeptieren. Dann ist das klar, das ist eine Einladung, ein Dosangriff zu starten, weil das braucht ja alles Speicher auf dem Server. Es geht zwar schnell, also ist schnell, aber braucht trotzdem 1 megabyte pro Klient. Und ja, das ist ein Problem, das müssen wir irgendwie verhindern können. Können jetzt die Server das verhindern? Ja, wir wollen dieses Spalten XORN. Wir haben hier Limitation bei kleinen Geräten. Wir sind jetzt ein kleines Gerät, aber wir wollen hier die paar Positionen auswählen und dann können wir der Außenwelt sagen, ja, bitte gib mir doch nur die ganzen Sachen ein bisschen stückchenweise. Und dann macht es hier stückchenweise, geht es durch und XORN, falls das ausgewählt wurde, oder eben nicht. Und das funktioniert und am Schluss kommt dann der normale schifre Text raus. Und was wir hier haben, ja, ist ein nettes, eine nette Umgebung, da gehen wir davon aus, dass die Außenwelt nichts Böses mit uns machen will. Jetzt setzen wir das auf das echte Internet raus, ohne irgendwie den Zustand zu speichern. Wir wissen gar nicht, ja, wann kommt die nächste Spalter? Dann wird nicht funktionieren. Wenn man dem Klient sagt, ja, das habe ich im Moment und dann kriegt der Server die nächste Spalter und dann wird das hier und her gesendet. Jeder, der hier dazwischen sitzt und das Zeug anschaut, sieht dann, ja, hat sich was geändert oder nicht? Also, und damit habe ich mich dann beschäftigt. Oder, ja, also, die Frage ist, krieg ich das jetzt noch publiziert? Ich arbeite jetzt hier an McTiny, also Tiny for Winzig, und will ich damit für winzige Webserver machen? Es geht davon aus, dass der Webserver gar nicht den Zustand speichert für jeden Klient. Wir gehen davon aus, dass alles, was der Server bekommt und wieder raus schickt, ist schon verschlüsselt und identifiziert. Es gibt da ein paar Schutzmechanismen gegen Replayattacks. Und ja, die Sachen hier sind eben alle verschlüsselt. Und hier nutzen wir jetzt Eigenschaften von den Summen in einzelnen Stücken. Das geht, wenn wir das in ein eigenes U-Rang schmeißen und dann haben wir noch Platz für ein Cookie. Ein Cookie, das mit dem Server, von dem Server, verschlüsselt wurde. Und der kann das dann so mit dem Cookie jeweils hin und her schicken und das funktioniert. Der Cookie ist verschlüsselt, aber der Server handelt den Schlüssel für alle Clients. Das ist also etwas ganz Kleines, was sich der Server merkt. Und der ganze Rest der Client sucht sich da die Spalten raus und das sollte eigentlich funktionieren. Das Resultat ist mehrere Hin- und Herwege der Kommunikation, aber kein Zustand, der gespeichert wird für jeden Klient. Wir haben keine Probleme damit, wir kennen das nicht aus, viel Daten umzuschicken, aber was anderes, was mit der Ausrollung mit einem Ausrollen-Probleme machen könnte, sind Patente. Was jemand sagt, der aus irgendwem Gründen was Kleines möchte, ist dann Aus- und Herwege. Wir haben in hohen Informationen über das Thema Systeme, die patente sind, als wir es zum Beispiel hier haben. Ein Teil der das Wettbewerbs war, dass man Statements abgeben musste, die aussagen mussten, ob man keinerlei Patente hat, die relevant wären für das Verfahren. Oder man braucht Patente und testen die folgenden Nummern. Das sind jetzt genau die 18 Submissions. Ein Grab, ist die alle Patenten unterliegen, als z.B. kompakt. Das gibt es auch schon Skripte, gibt es die, die nicht kaputt sind. Es ist jetzt kein Grund, dass diese Patente, und vielleicht sind sie nicht so schlimm, weil man nicht einfach die 18 Submissions erzielen kann. Aber du kannst auch nicht einfach die alle verbrauchen und sagen, okay, die sind jetzt patentiert, deswegen niemals nicht. Es gibt manche Patente, die mehr als eine Eingabe abdecken. Es gibt keine Regelung, die einreichend vorstellt. Es gibt keine Regelung, in der OWN 1 OP oder 2 als was Dansetown welche von den Eingaben durchs Iya Patent abgedeckt wird. member of the submission teams. This patent was issued in 2015 at the top there, which might make you think, oh, if something was published before 2015, it would be okay, and some submissions were published earlier. But what's important is the date down at the bottom here, which is the priority date of February 18th, 2010. If you look on Google patents, the good thing is they put the priority date pretty far upward. What this means is that in order to be prior art for this patent, well, you have to check what exactly they filed in 2010, they might have made later changes, but the 2010 thing, assuming that all the stuff was published in 2010, which taught me that. I think anything that was published after 2010 is not prior art for this. Now, what's really scary about this patent, I hope that really soon I'm gonna have an analysis online of which submissions are covered by which patents of all the patents I've seen. This one is by far the scariest, because this one covers a whole bunch of submissions. This one covers basically every submission, which is using what's called the LPR-Kryptosystem, im Prinzip jede Eingabe, die das LPR-Kryptosystem verwendet. This is a very popular type of Lattespace-Kryptosystem, which was published by LPR, in May 2010, which is after this patent application was published. Now, there was a talk in April, which had the same stuff from LPR, and it seems like there might even have been a talk in January from LPR, but they didn't put the slides online. And then, well, it started getting interesting questions of patent loss, which looks like a very strong patent covering all of the submissions. Und das sind wir uns jetzt schon voll in den Patent-Rechts sind. Das ist eine ganz tolle Idee, das manche Firmen aber so... Das nennt das Landmien-Setz, das ist eine einfach einzelne Erkunft, die immer wieder patentieren lässt. Und jetzt ist es sehr schwierig festzustellen, was alles patentiert ist und was nicht. Da brauchen wir jetzt ein ganzer Patent an, ein bisschen. Wir müssen hoffentlich nicht umpatentisch rumschlagen, solange wir irgendwas finden, das nicht von Patenten abgedeckt wird. So, jetzt haben wir uns wieder... wir schlagen uns wieder mit lustigen Namen um. Was sind wir jetzt hier? Können wir das jeder lesen? Seaside, okay, so Seaside. Seaside ist, was du wirklich immer wolltest. Seaside ist eine effiziente, fast quantenkommutative Gruppenwirkung. Allerleute, ich frage, ich benutze Diffie-Harman im Moment. Was kannst du mir in der Post-Quantenwelt geben? So, jetzt kommst du drauf an, wie definiert Diffie-Harman? Es sind manche Leute, die benutzen Diffie-Harman, einfach nur um... Alle Leute, dass sie öffentlichen Schlüssel über öffentlichen, und dass man die untereinander austauschen kann. Es geht darum, dass man die öffentlichen Schlüssel in den Löffelbruch nachschauen kann, und dass man die dann verwenden kann, um etwas zu verschlüsseln, um die wichtigsten in Schicke. Und dass ihr in der Lage seid, das dann auch zu entschließen. Es gibt noch andere Features, die wie z.B. irgendwas ausblenden. Es ist aber kein Unterschied, ob ich jetzt der Initiator einer Konversation bin, der Antworten, aber alle die Systeme, die jetzt in der NIST eingegeben wurden, machen einen Unterschied, ob ich der Initiator bin, oder derjenige, der antworten muss. Das ist jetzt der erste Unterschied, der besteht zwischen der Post-Quanten-Kontografie und der Aktuellen. Wenn du jetzt ein Nutzer bist, interessiert dich natürlich überhaupt nicht für diese ganzen Details, die da auftreten. Vielleicht sehen wir das aber nicht. Was uns interessiert ist einfach nur eine feste Prinzzahl, die das Feld definiert, also den Körper, den wir angucken. Was sie dann machen, ist, man nimmt dann ein Element aus diesem Körper raus und veröffentliche den dann. Und dann haben sie einen geteilten öffentlichen Key, mit einem geteilten geheimen Schüssel. Jetzt müssen wir uns ein bisschen in die Manomatik dahinter anschauen. Wir haben jetzt hier elektrische Gruppe, über die wir schon mal 2014 geredet haben, oder 2015. Also da unten in die Gleichung, y squared hat es x hoch 3, plus a, x squared hat plus x. Was die Berechnung macht, ist, dass nur von einem Schuss zum anderen geht, dass man benutzt, ein bisschen nie. Das ist eine elektrische Gruppe auf eine andere, was wird. Wenn man das implementieren will, man braucht eine Prinzhalt-P, man muss daraus eine elektrische Kurvenoperation bauen und kann daraus dann ein Isogenier rechnen. Da ist nichts Wahnsinnes Kompliziertes dabei. Es ist nur, es ist auf einer Konferenz an dem, an diesem Strand, aber bitte verwendet es noch nicht. Das hat noch nicht genug Analyse erfahren. Was wir jetzt kennen, ist die Sicherheit der Schlüsselraums. Jetzt lassen wir die Frage, wie viele Schlüssel gibt es in diesem Körper? Wenn man jetzt die Prinzhalt-P festgemacht hat, dann kann man wissen, dass ungefähr die Wurzel aus P valide Schlüssel in diesem Körper sind. Das sind jetzt die Anzeige der öffentlichen Schlüssel. Das kreten Logo muss man auf den elektrischen Kurven. Dann kommt man daraus, das ist eben die Wurzel P als Sicherheit. Man braucht dann die vierte Wurzel aus P, Zeit, um rauszufinden, auf seinen möglichen Schlüssel ist. Aber jetzt sind wir ja in einer postkrannten kriptografischen Diskussion hier. Da ist es so, wir haben noch keinen kompletten, die zu knacken in der postkran- In RSA und DFI haben wir, das Wachstum der Bits nicht mehr hilft, bei postkran-kripto. Aber hier haben wir eine Analyse, die wir in der postkran-kriptografischen Diskussion haben. Wir haben eine Analyse, die in der postkran-kriptografischen Diskussion ist. Da kann man sich die Kosten der jeweiligen Attacken angucken. Die elektrischen Kurven muss man auch validieren. Da kriegt man einen Punkt. Mit diesem öffentlichen Schlüssel muss ich mal auf der Kurve gucken. Ist der jetzt korrekt? Das Gleiche mit der isogeniebasierten Krypto von C-Side. Müssen wir schauen. Da hat es hier irgendwie, mit den Punkten ein paar Modifikationen machen und dann überprüfen. Das ist was anderes, da haben wir uns voll daran gewohnt. Das können wir machen. Das ist etwas, was ziemlich schwer ist für alle Postkwandensysteme. Bei Postkwandensystemen muss man noch ein Weibchen per Weiß dazu nehmen. Wenn man jetzt ein Schlüssel sendet, dann ist der Schlüssel veröffentlicht. Dann kann man den nicht wieder benutzen. Oder man muss viel versinnen, um zu zeigen, dass man das selber gemacht hat. Aber bei C-Side ist das schon eingebaut. Von der Größe her ist das auch cool. 32 bytes für den privaten Schlüssel und 64 bytes für den öffentlichen Schlüssel. Das ist wirklich so ganz links unten in der Ecke von diesem Graf. Das ist also eine große Lücke mit einem kleinen Schlüssel. Also Postkwanden wollen wir hier jetzt eine vergleichbare Größe haben, mit der AES 128. Und C-Side 512 sollte jetzt basierend auf diese Analyse ungefähr gleichsicher sein. Gibt hier, wenn man das hier sieht, ungefähr gleichsicher sein. Gibt hier noch eine. Ja, der Lorenz sitzt da. Der hat mit Skylake der Performance-Test gemacht. Jetzt noch nicht die konstante Zeit. Das macht ungefähr 3-mal langsamer. Es ist nicht wie Syke, also kleine Schlüssel und halte für etwas langsamer. Sykes hat hier schon viel Arbeit gemacht und wir haben hier Hoffnung, dass das noch irgendwie schneller werden kann und dass das hoffentlich auch noch nicht gebrochen wird bis nächstes Jahr. Aber ich weiß jetzt nicht, ob ich hier darauf wetten will. C-Side ist vielleicht noch besser als Syke. Aber ja. Apropos Kaputt, ja, es gibt ja einige Leute, die in Kryptowährung investieren. Ich glaube, Nick Matthewson, der ist da schuld mit der Quantum Blockchain. Gibt da verschiedene Variationen. Da kann man sogar T-Shirts kaufen. Wir haben hier jetzt noch ungefähr 10 Minuten. Also noch ein paar Kommentare zu Software. Schauen wir mal 40 Jahre zurück auf öffentliche Schlüsselverschlüsselung Kryptografie mit RSA von 1978. Und jetzt schauen wir hier mal, was die Softwarequalität ist, wenn man da über Kryptografie redet. 1978 weiß ich nicht. 1988, was klar. Ja, ziemlich schrecklich. 1998, ja, ein bisschen besser. Immer noch scheiße. 2008, schlecht. 2018, wir sind wieder. Am Anfang ist es ziemlich scheiße. Und ja, eine haupte Angelegenheit. Hier ist diese Nisteingabe, welcher Code hat von Mathematikern, die keine Ahnung haben, wie man da Zeug implementiert und Codequalität hochhaltscht. Aber ja, es gibt ein paar Perlen, aber ja. Es gibt ein paar andere, wo das gut ist, aber wenn man da so eine zufällige Sache rauspickt, dann ja, ist interessant. Wenn ihr da was rausfinden wollt, ja, versucht nicht mit NIST, archive.org, und wenn ihr da sucht nach NIST, round 1, round 1, dann könnt ihr das damit, archive.org, versuchen, Boter zu laden, und die kriegt man hier noch. Die haben da vermutlich oder hoffentlich alles können. Und mehr als die Hälfte von diesen Eingaben kann man da noch von den eigenen Webseiten noch herunterladen. Und der schnellste Code, den kann man von Supercop Benchmarking herunterladen. Und da haben wir die primitiven von 40 der 69 Eingaben drin haben. Und vielleicht haben wir da alle patentierte irgendwie Rahus gelassen. Und ja, man muss jetzt halt hier einfach eingeben und dann funktioniert das. Dann werden wir das Benchmarken, aber wenn man die uns dann halt so nicht gibt, dann werden wir das nicht tun. Und ja, da habe ich dann auch noch mal versucht, einen Code zum Teil zum Laufen zu kriegen. Die Primitiven haben wir hier zum Beispiel RSA, 512, 1024. Das sind da verschiedene Primitiven und die haben da verschiedene Sicherheitslevels. Und bei den Eingaben hat es da meistens 3. Manchmal mehr, manchmal weniger. Und viele der Primitiven haben da mehrere Implementationen und die sind dann auch unterschiedlich und die sammeln wir halt dann so zusammen. Bei LibPQ Crypto, die fokussieren sich da auf eine API für kriptografisches Rausrollen in der Zukunft. Wenn man sich da noch vorstellen könnte, dass die Imlementation verbessern werden könnte, dann hat man das Interface, das man benutzen könnte. Hier gibt es noch PQM4, eine Bibliothek für ARM, Mikrocontroller, PQHW, das ist für FPGAs und Open Quantum Safe, die haben hier nicht so viele Primitiven wie Yandern, aber was da toll ist, die haben gute Integrationen von diesen Dingen in OpenSSL und OpenSSH. Wenn man da in der Terles-Welt unterwegs ist, dann wäre es mal klar, dass man mal die hier ausprobiert. So, schauen wir noch ganz kurz auf LibPQ Crypto. Es gibt hier ganz viele verschiedene Bibliotheken, die eine einfache API zur Verfügung stellen. Zum Beispiel hier CryptoHashShare 256, da gibt man halt so ein paar Sachen rein und da kriegt man dann zurück einen Hash. Wenn man in einer höheren Sprache das Ganze macht, dann ist das natürlich etwas einfacher, aber C sieht es dann ungefähr so aus. Warum machen wir das nicht für alle kriptografischen Funktionen? Also, ja, viele kriptografischen Bibliotheken haben da so die tollen Interfaces und sobald man Signaturen machen will, dann muss man zuerst die Factory holen, die dann die Schlüssel macht und dann mit einem Generator und so weiter. Aber warum nicht einfach hier, was LibPQ Crypto macht? Ja, jetzt signieren wir halt eben diese Sachen und eben in C. Da müssen wir dann halt das Zeug mit reingeben. Wir kriegen da die signierte Message, die ursprüngliche Message, geben wir rein und so. Dann funktioniert das alles ohne Konversionsfunktion und so weiter. Das kommt jetzt wieder zurück auf Supercop. Das haben wir schon viele, viele Jahre gemacht mit LibSolium und NACL und so. Die benutzen hier alle die gleiche API und wir sehen hier auch einen Einfluss auf die Benutzbarkeit von diesen Bibliotheken. Wir sehen hier auch, da sind wir noch zuverlässig da, dass wir sagen können, ja, das macht Sinn. Nächster Tag hat er gesagt, ja, mach das vielleicht mit dieser API. Das muss so sein, aber die haben kein Test-Frame-Work dazu geschrieben und haben also da kein Test-Frame-Work durchgesetzt. Das heißt, es hat dann ja nicht funktioniert und das haben wir halt in Supercop dann gemerkt. Deshalb habe ich noch viel manuelle Arbeit gemacht. Aber war schon ziemlich nahe, also das hat gut funktioniert. Da hat es auch viel Teilen gegeben, das kurz. Und ja, heißt auch, dass es weniger Dublikation hat. Ja, hat so verschiedene Signaturen, Verschlüsselungssysteme, hier noch ein Beispiel für ein Python-Interface hier mit Lepeco-Crypto. Wenn man hier so eine Nachricht designieren will, dann muss man zuerst den Public und den Geheimenschlüssel machen. Ist hier so eine zustandslose hash-basierte Algorithmus mit Sicherheitsdebel 128 und schade, 256. Und dann muss man einfach das wissen. Dann kann man das signieren, die Message, und dann die Message wieder aufmachen von der signierten Sache. Falls jetzt hier die Verifizierung nicht funktioniert, dann gibt das eine Exception. Und das ist hier ein Sicherheitsschritt. Falls das jetzt irgendwo nicht funktioniert mit der Verifikation, dann wollen wir das nicht ignorieren, sondern was wir wollen, ist, dass das, wenn man hier so eine Signierte Nachricht hineingibt, dass das dann, wenn man die öffnen will, eine Signierte Nachricht öffnen will, dann muss, wenn es eine Signorte gibt, dann heißt das, dass die Signatur nicht valide war. Und ja, das gibt dann eine Exception, also sogar, wenn man die ignoriert, dann hat man immerhin keinen Output. Ja, so ein paar kleine Gedanken, die da noch eingeflossen sind und ein größeres Beispiel. Ja, dann mit einer Bibliothek, alles rein, generieren, signieren und wieder öffnen. Ja, mit LibPQ Crypto. Wie geht das dann in der Zukunft weiter? Erst ist hier mal ja Code Qualität. Da haben wir das Problem mit den ganzen Timing Angriffen, wie zum Beispiel mit Spectre. Und da gibt es viele Angriffe und das Problem mit diesen Angriffen ist, dass wir hier sowohl Hardware fixes machen müssen. Ich hatte schon ein paar Implementierungen gegeben. Ja, bei einem Mehrarbeit für Korrektheit und der Code, ja, mit Adress-Sanitation muss irgendwie funktionieren und es gibt viel zu viel Code, der das noch nicht macht. Ja, das passiert halt eben, wenn man Mathematiker darum fragt, Code zu schreiben. Mit formaler Verifizierung wollen wir die das wird uns garantieren, dass der Code tatsächlich tut, was er tun sollte für alle möglichen Inputs. Da war ich zuerst skeptisch, das klingt ziemlich nach viel Arbeit und ungemütlich. Aber die Tools werden hier viel besser. Und ich habe da mal eine Sortierungsverifizierung geschrieben, wo der Maschinencode hier verifiziert wird. Also sogar wenn man Compiler Box hat, dann ja, man schadet den Maschinencode an, also hat man hier höchste Garantie. Mit einem speziellen Tool gibt es coole Tools dazu für symbolische Ausführungen. Ja, die Geschwindigkeit hier, Codevolumen runterkriegen, also dass wir das hier einfacher auch können anschauen und schlussendlich hoffentlich können wir so viele Primitive wie möglich wegwerfen und uns dann nur noch auf eine sehr kleine Anzahl Sachen konzentrieren und dann sagen, ja, wir haben das jetzt wirklich sehr, sehr gut angeschaut und sind sehr zuversichtlich, dass das super funktioniert. Vielen Dank für Ihre Aufmerksamkeit. Danke, Daniel. Danke, Daniel und Daniel. Wir haben jetzt noch kurze Frage-Runde. Eine Frage vom Internet, erste Frage. Gibt es da bei Codebase irgendwelche andere mit kleinen Schlüsseln? Mit kleinen? Ja, so Codebase-Kotografie, da gibt es zwei Submissions-Klassik-McLeese, die ich highlighte, weil es ours ist und da ist NDS-CAM, die hat diese Gigantik-Keyes. Beides sind mit Gopacodes, die die meisten Analyse haben, aber als Gigantik-List gibt es viele. Ja, dann ist es shown here. Several of those are actually code-based, so Big Quake, for instance, down there is a code-based system, then Lake, Lake is one down there, so Lake would be fitting this by saying it's very small keys and signature, cybertext. The downside is it is using far less well studied codes, so we can't be sure. For people in the room please try to limit your questions to a single sentence. Microphone number three, your question. Okay, how exactly do you... Wie genau definiert ihr die Post-Quantum-Krypto? Ihr habt hier Shores-Algorithmus, die anderen Algorithmen, aber sagt ihr jetzt, ja okay, wir wollen jetzt einfach gegen Faktorisierungen oder das diskretenden Logaritmus sicher sein und dann könnt ihr auch Optimierungsprobleme und so in Betracht ziehen. So, I mean the definition is we're trying to protect against any attacker who has a big quantum computer and we have a rough understanding of what quantum computers can do because they're limited by the laws of quantum physics, which tells us that okay, if you can build a computer that supports what are called Toffoli Gates and Hadamard Gates, it's very plausible that you can simulate the matrix at that point, a quantum matrix, yes, you have a universal quantum computer at that point. The problem is, how do we know, okay, by believing that quantum physics is everything we can do in the universe, that tells us we have a computation built on Hadamard Gates Toffoli, that doesn't tell you what kinds of algorithms you can put together and there's a big problem and that's why we're trying to imagine what all possible algorithms are and sometimes people mess on things. And so if from the algorithm system as ruleably secure, there can't possibly be an algorithm which is faster than this to break the system. No, there's no guarantee that you can use actually a faster algorithm. If you had a lot of work on people trying to figure out what algorithm is using quantum computers, for instance, for the sub-exponential attacks against each side. And that's something where there's a long history to those attacks from the first algorithm. And this is going beyond Schor's algorithm and Robert Schor's algorithm. And it's really important to look more at what sort of quantum algorithms could attack cryptographic systems. There's been some issues here with the devilish algorithm. But we are outtaken about to do whatever they want. The only thing we know is dass ein Quantencomputer hat. Interessant, aber wie sieht das aus mit klassischen Algorithmen versus Postquantum auch in Bezug auf FPGAs? Auf der großen Liste PQM4 verwendet einen Cortex-Armen-Info. Ein ziemlich kleines Gerät. Sie haben nicht alles implementiert. Aber was Sie gesagt haben, ist, es ist sehr umständlich mit den großen Schüsseln. Wir sind einfach verwöhnt von den elliptischen Kurven. Weil man da nur 256 Bits braucht. Seaside ist das Nächste, wo man da rankommt. Aber es braucht halt viel Berechnung. Die kleineren Systeme wurden schon implementiert. Da hat jemand schon Aufwand reingesteckt. Ihr habt gesagt, als Google da die Tests gemacht hat, dann haben sie gesagt, es ist zu langsam, die werden es nicht brauchen. Könnte hier die Lösung sein mit Beschleunigungs-Units wie IS bei CPU? Google hat bestimmte Dinge ausgeschlossen. Ich kenne nicht alle Details. Aber meine Annahme war, dass man die Zeit, die die Leute verwendet haben, um die Sicherheit zu analysieren, mit einbezogen hat. So dass man diese IS ausgeschlossen ist. Aber man kann viel beschleunigen, wenn man die Entry-HRSS verwendet. Aber das ist relativ große Aufwand. Dass die Videoausfall, die sie getroffen haben, ist eine ziemlich gute Klingelung, dass es in ziemlich viele Anwendungen reinpasst. Im Vergleich zu den Daten, die wir rumschicken, ist es ziemlich vernünftig. Es gibt nur bestimmte, wo so kleine Palos geschickt werden, dass das ein Thema ist. Der letzte, der sagen würde, das geht der Verfahren ziemlich sicher sind. Machen wir mehr Sorgen, dass Entry-HRSS wirklich viel knackt werden kann. Aber es gibt eigentlich kein Verfahren, das 20 Jahre entgehalten hat, ohne dass es ein sehr guter Kompromiss zwischen relativ klein, relativ sicher keine großen Comput-Zeiten. Die letzte Frage kann Seaside auf einer hardwarebeschleunigten Sache funktionieren mit elliptischen Kurven problematischer. Das hängt davon ab, was dein hardwarebeschleuniger hat. Wenn das so ein generischer elliptische Kurvenbeschleuniger ist, dann kann man es verwenden. Es hängt davon ab, ob der jetzt Bayer-Strasseform oder Montgomery-Form verwendet. Viele Systeme sind optimiert auf 256 Bit, 512 ist schon relativ weit draußen, aber viele Operationen sind ziemlich genau gleich aus. Es ist einfach eine riesige Skalarmotifikation und manche Isogenien, die man darauf ausführen muss, die aber ziemlich ähnlich sind, die, nachdem man ja schon die ganze Körperarithmetik auch implementiert hat, ist es als ziemlich ähnlich. Also ja, es kann beständig werden, klar. Also klar, es ist vom Januar, und der Sicherheitsanalyse also baut noch keine Hardware, bitte. Thank you so much. Please give a round of applause for the talk. Applaus, bitte. Und damit beschließen wir auch die Übersetzung. Das waren Kaste und Jopdi. Und bedanken euch für eure Aufmerksamkeit. Bitte schickt euer Feedback an.