Kryptographie Algorithmen 2017 Überblick DES 3DES AES ECC

Sind Krypto-Algorithmen wie AES knackbar?

Eines vorweg: dieser Artikel richtet sich nicht an Kryptographen und Mathematiker, die sich selbst mit der Bewertung von kryptographischen Schlüsseln und Algorithmen beschäftigen oder auf der Suche nach einer weiteren theoretischen Side-Channel-Attacke gegen AES-256 & Co. befinden. Bitte nur weiterlesen, wenn du einen Überblick über die gängigen Verschlüsselungs-Algorithmen suchst und dazu eine praxisorientierte Sicherheitsbewertung der verwendeten Schlüssellängen benötigst.

DES (1975: wie alles Begann)

Mit DES begann im Jahr 1975 die erfolgreiche Story der symmetrischen Verschlüsselung für die Allgemeinheit. Die Schlüssellänge ist mit 56 Bit definiert, wobei DES nur Datenblöcke von 64 Bit = 8 Byte(!) verschlüsseln kann. Als die NSA im Jahr 1977 den DES Algorithmus primär die die Behördenverschlüsselung verabschiedet hat, befand sich die Welt noch im Kalten Krieg. Der 56 Bit Schlüssel erlaubt eine Schlüsselvariation von 2^56 Schlüsseln das rd. 72 Billiarden (72 mit 15 Nullen) Schlüsseln entspricht. Ich denke, dass die NSA im Jahr 1977 etwas naiv war, als sie einen tatsächlich sicheren Algorithmus unterstützt hat, der von IBM weltweit veröffentlicht wurde und selbst die Datenkrake NSA für einige Jahre ausgesperrt hat. Persönlich denke ich, dass die Geheimdienste dann in viel teure Hardware investiert haben und Ende der 80er Jahre über Brute-Force-Attacke in wenigen Tagen jeden DES Schlüssel nachrechnen konnten. Das gilt meiner Meinung nach aber nicht für normale Unternehmen oder Hackergruppen, denen erst in den 90ern diese Möglichkeiten geschaffen wurde.

Von DES zu Triple-DES (3DES, TDES)

Outlook 2016 Einstellungen für Signaturhash und Verschlüsselungs-Algorithmus
Outlook 2016 Einstellungen für Signaturhash und Verschlüsselungs-Algorithmus

Bis vor kurzem war 3DES noch die Voreinstellung vieler Verschlüsselungsprodukte, hier ein Beispiel der Outlook S/MIME Einstellung für die E-Mail-Verschlüsselung.

3DES arbeitet auf Basis von DES nutzt den Algorithmus aber 3x hintereinander. Gängige Methode ist drei unterschiedliche Schlüssel zu erzeugen, die Nutzdaten (immer noch 8 Byte…) mit dem ersten Schlüssel zu verschlüsseln, mit dem zweiten Schlüssel zu entschlüsseln und mit dem dritten Schlüssel nochmals zu verschlüsseln. Da einem Angreifer aber oft die Quelldaten und die verschlüsselten Daten bekannt sind, z.B., weil viele Datentypen u.a. auch die Office Daten immer mit den gleichen Bytes beginnen (sogenannte Magic Bytes), reduziert sich in der Regel die 3x 56 Bit Schlüssellänge von 168 Bit auf 2x 56 Bit entspricht 112 Bit nutzbare Schlüssellänge. In den vielen Jahren bis heute sind weitere Angriffe auf den Algorithmus erkannt wurden, aktuell wird die 3DES Verschlüsselung mit 80-Bit Schlüssellänge bewertet.

Aufgrund der 56-Bit von DES und bewerteten 80-Bit Verschlüsselung von 3DES ist diese Verschlüsselung heute berechenbar.

Asymmetrische Verschlüsselung mit RSA-512 bis RSA-8096

Die RSA Verschlüsselung aus dem Jahr 1977 ist eine asymmetrische Verschlüsselung und es werden zwei Schlüssel typischerweise jeweils 1024 Bit, 2048 Bit oder 4096 Bit erzeugt, wobei der eine Schlüssel (Public-Key) für die Verschlüsselung und der andere Schlüssel (Private-Key) für die Entschlüsselung genutzt wird. Bei einer bidirektionalen Kommunikation arbeitet man mit zwei Schlüsselpaaren, wobei vom Kommunikationspartner A der Public-Key des Partners B zum Verschlüsseln an B genutzt wird. Partner B nutzt wiederum seinen Private-Key, um die erhaltene Nachricht zu entschlüsseln. Die Kommunikation von B nach A funktioniert genau umgekehrt über den Public-Key von A.

Die Schlüssel selbst errechnen sich aus zwei langen Primzahlen, wobei die Erstellung von RSA-2048 Schlüsselpaarn viele Sekunden dauern kann.

Bei den Schlüssellängen kann man asymmetrische RSA Schlüssel nicht mit symmetrischen Schlüsseln vergleichen. Ein RSA-1024 Bit Schlüssel ist nicht 4x so stark wie ein AES-256 Schlüssel, sondern deutlich schwächer. Hier meine Recherche als Vergleich:

  • RSA 1024 Bit -> entspricht ca. einem 80 Bit symmetrische Schlüssel
  • RSA 2048 Bit -> entspricht ca. einem 112 Bit symmetrischen Schlüssel, also beispielsweise dem kryptographischem Potential von 3DES
  • RSA 3072 Bit -> entspricht ca. einem 128 Bit symmetrischen Schlüssel, also z.B. AES-128
  • für die Darstellung der AES-256 Stärke wird ca. ein RSA 15400 Bit Schlüssel benötigt

Das deutsche BSI empfiehlt ab dem Jahr 2017 den Wechsel auf zumindest RSA 3000 Bit Schlüssel.

Cryptography Key CipherDie RSA Operationen sind im Vergleich zu AES und 3DES im Durchschnitt um den Faktor 1000 langsamer pro Datenblock. Daher wird RSA nicht für große Datenvolumen genutzt, sehr oft aber für den Austausch von symmetrischen Schlüsseln. Ein typisches Beispiel hierfür sind der TLS-Handshake einer HTTPS-Webseite und das S/MIME Protokoll für die Email-Verschlüsselung, bei der ebenfalls ein 3DES oder AES-Schlüssel innerhalb des S/MIME PKCS#7 Containers durch einen RSA-Schlüssel (oder ECC Schlüssel) geschützt ist.

Aufgrund der Performanceunterschiede eignet sich RSA nicht für größere Datenströme wie VPN, https, Email, Dateiverschlüsselung, Festplattenverschlüsselung. Einige der Protokolle nutzen eine Hybridverschlüsselung aus asymmetrischer Verschlüsselung zum Austausch eines symmetrischen Schlüssels und dann die schnelle symmetrische Verschlüsselung der Nutzdaten.

Zukünftig werden die langen RSA Schlüsseln und langsame RSA-Verschlüsselung von den deutlich kürzeren ECC-Schlüsseln mit deutlich besserer Performance abgelöst. Aus Kompatibilitätsgründen werden wir RSA Schlüssel aber noch viele Jahre in den Produkten unterstützt haben.

Serpent, Twofish, MARS, Rijndael und RC6

Zurück zur symmetrischen Verschlüsselung. Alle fünf Algorithmen Serpent, Twofish, MARS, Rijndael und RC6 waren im Jahr 1997 die Finalisten der NIST Ausschreibung um einen neuen AES Standard, der DES abgelöst hat. Rijndael hat das Rennen um AES gemacht, mit dessen Verabschiedung sich die NSA selbst ins Entschlüsselungs-Abseits bugsiert hat.

Serpent und Twofish gelten mit Schlüssellängen von bis zu 256 Bit als sicher und wurden als Public-Domain Basis veröffentlicht. Heute finden sich diese AES Alternativen in Linux- und OpenSource-Verschlüsselung Lösungen wie VeraCrypt und Linux dm-crypt.

Von MARS hat man nicht mehr viel gehört, der Algorithmus hat anscheinend keine Fürsprecher gefunden. Hingegen ist RC6 von RSA patentiert worden und kommt wahrscheinlich in den EMC / RSA Produkten zum Alternativeinsatz. In der Praxis bin ich aber noch niemals mit RC6 konfrontiert worden.

Das Smartcards und Hardware-Security-Module oder der TPM heute oft nur eine Auswahl von DES/3DES, RSA, AES und ECC unterstützen, ist man mit alternativen Algorithmen stark auf spezielle Software und Linux/OpenSSL eingeschränkt.

AES – Advanced Encryption Standard

Unglaublich innovativ war es von der NIST im Jahr 1997 eine Ausschreibung zu starten einen sicheren, symmetrischen Verschlüsselungs-Nachfolger für DES zu suchen, der überdurchschnittlich schnell ist, in Hardware und Software zu implementieren ist und Blöcke von 128 Bit (16 Byte) mit Schlüssellängen von 128-Bit, 192-Bit und 256-Bit verschlüsseln kann. Die belgische Rijndael Einreichung hat dieses Rennen gewonnen, was für mich bedeutet, dass die NSA keine Backdoors einbauen konnte.

AES beschreibt wie 16 Byte Blöcke verschlüsselt werden können, aber es ist auch sehr wichtig wie diese Blöcke aneinandergereiht werden können und große Datenmengen also einen VPN Datenstrom oder eine HTTPS Verbindung oder eine S/MIME-Email schützen können. Dazu ist es wichtig, dass die Blöcke sicher verkettet werden und nicht untereinander ausgetauscht werden können um Nachrichten oder Daten zu manipulieren.

Daher gibt es unterschiedliche AES Betriebsmodis. Eine detaillierte Empfehlung über sichere und unsichere Algorithmen liefert das BSI Empfehlung TR-02102 (78 Seiten) die du unter folgendem Link abrufen kannst.

AES-ECB (Electronic Cook Book)

Dieser Modus verkettet die 16 Byte AES Blöcke nicht, sondern verschlüsselt die Nutzdaten mit demselben AES-128 / -192 / -256 Schlüssel. Der Nachteil liegt auf der Hand, wenn man Teile des Quelltextes kennt, kann man Rückschlüsse auf den Inhalt ziehen und man kann den verschlüsselten Inhalt manipulieren, indem man einzelne 16 Byte Blöcke austauscht. Daher: nicht empfohlen!

AES-CBC (Cipher Block Chaining)

Bei CBC wird ein Initial-Vektor (IV) benutzt um den ersten 16 Byte Block zu verschlüsseln, dann wir eine Prüfsumme vom ersten verschlüsselten Block genutzt und als Verschlüsselungsschlüssel für den nächsten Block verwendet. Das wir so fortgeführt bis zum letzten Block. Der Modus ist eine sehr gängige Methode, bedeutet aber, dass wenn man in der Mitte eines großen Datensatzes ein paar Bytes lesen möchte, dass man alle Daten von Beginn der Datei an entschlüsseln muss um die wenigen Bytes in der Mitte lesen zu können. Ein weiterer Nachteil ist, dass wenn sich nur wenige Byte ändern sollen, alle Daten von Beginn an neu verschlüsselt werden müssen. Daher eignet sich der Modus ggfls. für Festplattensektoren, nicht aber für eine großes .PST Emailarchiv oder ein Volume einer virtuellen Maschine.

Hinweis: Der AES-CBC Modus war die Standardverschlüsselung für die BitLocker Verschlüsselung bis Windows 10 Version 1511 (November 2015). Mit Version 1511 wurde AES-XTS eingeführt.

AES-CFB (Cipher Feedback)

Der Cipher Feedback Mode arbeitet ähnlich auch mit einem Initialisierungs-Vektor IV und einem Schlüssel. Er verkettet ähnlich wie der CBC Modus, jedoch sind nicht alle 16 Byte Blöcke unmittelbar voneinander abhängig, sondern immer nur der aktuelle und der nächste Bock. Daher kann beim Entschlüsseln bei einem beliebigen Block begonnen werden und der übernächste Block kann dann entschlüsselt werden. Das macht es einfacher wenn man damit rechnet, dass eine Kommunikation nicht fehlerfrei ist und man durch Bitfehler gglfs. auf einzelne Blöcke verzichten kann.  In der Praxis scheint CFB aber nicht sehr gebräuchlich zu sein.

AES-OFB (Output Feedback)

Dieser besondere Streaming Block Modus nutzt einen Initialisierungs-Vektor (IV) und einen geheimen Schlüssel zur Erstellung eines 16 Byte Krypto-Blocks und nutzt die logische XOR Funktion, um die ersten 16 Byte Nutzdaten zu verschlüsseln. Nur der Krypto-Block (Nutzdaten unabhängig) wird als IV an den nächsten Block weitergegeben und darf wiederum mit dem geheimen Schlüssel einen neuen 16 Byte Krypto-Block bilden, der die nächsten 16 Byte Nutzdaten verschlüsselt.

Der Modus hat Vorteile. Unter anderem, dass Bitfehler sich nicht in weitere Blocke fortpflanzen, aber auch, dass man die Kette der Krypto-Blöcke vorab rechnen kann und dann nur mehr mit den Nutzdaten per einfachster XOR verknüpfen muss. Wichtig dabei ist aber, dass man bei jeder Nutzung einen neuen IV nutzt, da man mit zwei verschlüsselten Datenströmen sehr einfach die Schlüsselkette wegrechnen kann und damit einen Angriff auf die beiden Datenströme ermöglicht. Das deutsche BSI empfiehlt aus Sicherheitsgründen gar keinen Streaming Block Modus, ich gehe mal davon aus, dass die Experten wissen warum.

AES-CTR (Counter Mode)

Auch hier handelt es sich um einen Streaming Mode, wobei ein Initialisierungs-Vektor (IV) bei jedem Block um einen Blockzähler erhöht wird. Diese sich ändernde IV wird mit dem privaten Schlüssel zu einem Krypto-Block verschlüsselt der wiederum per XOR mit den Nutzdaten den verschlüsselten Datenstrom erzeugt. Die Nutzdaten bilden keine Verknüpfung mit dem nächsten Block, nur der erhöhte IV und der private Schlüssel. Daher gelten alle Vor- und Nachteile des OFB Modus, jedoch muss man nicht alle Krypto-Blöcke vom Beginn an errechnen, um einen Datenblock weit im inneren des Verschlüsselungsstroms zu errechnen, sondern muss nur wissen um welche Nummer des Datenblocks es sich handelt um sofort entschlüsseln zu können. Obwohl die Errechenbarkeit der Kryto-Blöcke sogar einfacher ist als beim OFB Modus empfiehlt das deutsche BSI diesen Modus.

Hinweis: Wichtige Anwendungen für diesen Verschlüsselungsmodus ist TLS 1.2 und die ZIP/AES Verschlüsselung.

AES-XTS (XEX-Based Tweaked-Codebook Mode with Ciphertext Stealing)

Der AES-XTS Modus wurde erst im Jahr 2007 durch die IEEE verabschiedet und ist ein vergleichsweise junger Modus für die AES Verschlüsselung. Fälschlicherweise nehmen manche Leser an, dass es sich um eine stärkere Verschlüsselung als 256 Bit handelt, da man für die Verschlüsselung einen 512 Bit Schlüssel benötigt der in der Verschlüsselungsoperation geteilt wird. Der Modus wurde speziell für die Festplattenverschlüsselung entwickelt und eliminiert theoretische Schwächen der CBC Betriebsart.

Leider ist dieser Modus sehr komplex. Im Prinzip verwendet der Modus aber je 16 Byte Nutzdaten zwei Schlüssel, einen 512 Bit Krypto-Block („A“) der über einen definierten Vektor und den geheimen Schlüssel erzeugt wird und einen weiteren 256 Bit Schlüssel („B“). Der 512 Bit Krypto-Block „A“ wird in die Schlüssel „AA“ und „AB“ geteilt und die Nutzdaten über XOR mit dem Schlüssel „AA“ chiffriert. Dann erfolgt die AES Verschlüsselung der XOR Daten über den Schlüssel „B“ und anschließend noch eine XOR Operation mit dem Schlüssel „AB“, um die verschlüsselten Daten zu erhalten.

Der definierte Vektor besteht aus 1. einem beliebigen Initial-Vektor IV der mit 2. Festplatten-Sektor-Nummer und 3. der Nummer des Datenblockes innerhalb des Festplattensektors verändert ist. So wird sichergestellt, dass jeder Sektor und jeder Block innerhalb eines HDD-Sektors mit einem eigenen Schlüssel geschützt ist und niemals auf der HDD verschoben werden kann.

Warum wird so aufwendig chiffriert? Den definierten Vektor kann man zu jeder Zeit über die Sektor-Nummer und Offset errechnen und kann so (Besitz des zweiten geheimen Schlüssels vorausgesetzt) sofort an einer beliebigen Stelle die gewünschten Daten entschlüsseln.

AES-XTS ist ein moderner Modus und ich sehr ihn als sehr sicher an. Er ist aber nur für die Full-Disk-Encryption / Festplattenverschlüsselung entwickelt worden. Vorsicht daher wenn man den Modus als Wettbewerbsvorteil für andere Sicherheitslösungen wie Datei- oder Volume-Verschlüsselung anbietet.

Hinweis: Der AES-XTS Modus ist die Standardverschlüsselung für die BitLocker Verschlüsselung ab Windows 10 Version 1511 (November 2015).

Ist AES angreifbar?

Aufgrund der großen Verbreitung von AES gibt es zahlreiche Theoretiker die Angriffe auf den AES-Schlüssel aufzeigen. Die meisten Angriffe benötigen direkten physikalischen Zugriff auf das Verschlüsselungsgerät und Messen Abstrahlung, Stromverbrauch oder greifen in den Speicher oder Prozessor-Cache ein. Daher meine Empfehlung für Verschlüsselungssysteme: packt diese sicher in dein eigenes Rechenzentrum und kümmere dich um eine physikalische Absicherung der Systeme. Natürlich benötigst du auch Schutz vor unbefugter Benutzung übers Netzwerk, damit der Angreifer keine User- oder Adminrechte auf dem Verschlüsselungssystem selbst hat. In der Regel richten sich die Angriffe aber auf den Ablageort der Verschlüsselungsschlüssel selbst und nicht gegen den Verschlüsselungsalgorithmus. Mit Software alleine kann man weder einen AES-128 noch einen AES-256 Schlüssel schützen, bedenke das gut, wenn du über Verschlüsselung nachdenkst.

Forscher meinen errechnet zu haben, dass sich die Schlüssellänge von AES-256 auf unter 100 Bit eingrenzen lässt. Meiner Meinung nach ist das Boolshit-Bingo, um mit bekannten Schlagwörtern in der Kryptographie Publicity zu erlangen.

Koffer mit GeldIch bin der Meinung, dass jeder sichere Algorithmus – zu dem ich AES hinzuzähle – mit >128 Bit Schlüsseln eine sichere Methode ist Daten vertraulich zu übertragen. ABER: wer generiert den sicheren Schlüssel? In der Regel generieren die Verschlüsselungslösungen wie https/TLS, VPN, Messenger-Dienste, Festplattenverschlüsselungen, E-Mailverschlüsselungen usw. die symmetrischen AES-Schlüssel still in heimlich in der eigenen Software. Angeblich werden diese Schlüssel nach wenigen Minuten oder nach jeder Nachricht gewechselt, aber das ist für den Benutzer genauso intransparent wie die Entropie der Schlüssel. Wenn ich jemanden nicht vertrauen würde, dass ist es die Software die den Schlüssel erzeugt, also beispielweise der israelischen Firewall, der asiatischen End-Point-Encryption, der russischen Open-Source Software oder dem amerikanischen Router. Falsche Entropie kann man so erklären: man nehme eine beliebige Zahl z.B. 13 und würfle diese ein paar Tausend mal durch. Daraus kommt ein schöner AES-256 Schlüssel. Der Würfler (=die Verschlüsselungssoftware) weiß aber wie man durchgewürfelt hat und weiß auch die Anfangszahl nämlich 13. Verschwörungstheoretiker würde jetzt behaupten, dass der Geheimdienst die Zahl 13 festgelegt hat und dem Geheimdienst des eigenen Landes in der die Software entwickelt wurde alle gewürfelten paar Tausend Mutationen der doch nicht so zufälligen Zahl 13 übergeben werden. Damit muss der Geheimdienst nur diese paar Tausend Schlüssel bei einer verschlüsselten Datenkommunikation prüfen, was quasi in Echtzeit funktioniert.

Resümee: Solange man Einfluss auf die Schlüsselerstellung hat, braucht man den Verschlüsselungsalgorithmus nicht zu knacken.

Die Elliptic Curve Cryptography (ECC)

Das Prinzip wurde ca. 1985 von zwei unabhängigen Wissenschaftlern entwickelt und ist nicht mit einer symmetrischen Verschlüsselung vergleichbar, das es sich wie RSA-Verschlüsselung um eine asymmetrische Verschlüsselung handelt. Ein Teil des Schlüsselpaares wird für die Verschlüsselung verwendet, der andere Teil für die Entschlüsselung. Damit entfällt die Speicherung eines kritischen symmetrischen Schlüssels, aber man benötigt zwei Schlüsselpaare, wenn man bidirektional Verschlüsseln möchte. Bei ECC selbst gibt es unterschiedliche Verfahren wie ECDS und ECIES für die Verschlüsselung, andere Verfahren beziehen sich auf die digitale Signatur und den Schlüsselaustausch.

ECC Schlüssel sind deutlich kleiner als die herkömmlichen asymmetrischen RSA Schlüssel, aber verglichen an der Schlüssel-Stärke rd. doppelt so groß wie AES-Schlüssel. D.h. für die selbe Schlüsselstärke eines AES-256 Schlüssel (256 Bit) benötigt man einen 512-Bit ECC Schlüssel oder einen rd. 15.000-Bit RSA Schlüssel. Jeder der denkt, ist doch egal, was sind schon 512 Bit also 64 Byte oder auch 15.000 Bit also 1875 Byte, der soll bitte an den TPM Chip seines Notebooks denken oder an Smartcards und PKI-Token, die haben typischerweise nur 64 bis 72 KByte an Speicher haben. Davon sind oft nur 5 Kilobyte für Schlüssel vorgesehen. Unter dem Aspekt macht es natürlich einen großen Unterschied ob man 1-2 Schlüssel auf der Smartcard speichern kann oder doch über 10 Schlüssel.

ECC – frei oder doch nicht so frei…

Auch wenn ECC in der Theorie frei implementiert werden kann, haben sich einige Firmen auf Methoden die in ECC genutzt werden Patente gesichert, siehe Link. Jeder der nun ECC in der eigenen Lösung einbauen möchte ist mit Lizensierungsfragen konfrontiert, was die Softwaredurchdringung von ECC deutlich erschwert.

Viele Anbieter und Unternehmen sehen sich daher bei den RSA Methoden gefangen und erhöhen regelmäßig die RSA-Schlüssellängen, um kryptographisch mitzuhalten.

NIST ECC – nice try guys!

Sehr interessant ist der Bericht von Daniel Bernstein und Tanja Lange zu lesen, der die Initiative der NIST, einen unsicheren ECC Standard zu etablieren, in der Luft zerreißt.

Aus dem Abstrakt des Berichtes:

NIST’s ECC standards create (1) unnecessary losses of simplicity, security, and speed in ECC implementations and (2) unnecessary
tensions between simplicity, security, and speed in ECC implementations.

Wörtlich übersetzt:

Der NIST ECC Standard erzeugt (1) unnötigen Verlust von Simplizität, Sicherheit und Geschwindigkeit in ECC Implementierungen sowie (2) unnötige Spannungen zwischen Simplizität, Sicherheit und Geschwindigkeit in ECC Implementierungen.
Auch aus anderen Quellen habe ich erkennen können, dass die NIST in dem NIST ECC zertifizierten Verfahren bewusst Backdoors für die amerikanische NSA eingebaut hat. Das mag OK sein für die inneramerikanische Verschlüsselung, damit die NSA bei Bedarf mitlesen kann, aber Europa und andere Kontinente lassen diese durchschaubaren Abhörmethoden heute nicht mehr zu und verzichten gerne auf amerikanische Sicherheitsbevormundung.
ECC ist umfassend untersucht worden und ich sehe ECC als sehr sicher an. Einige der Patente auf ECC Methoden laufen 2017, 2018 und 2020 aus. Spätestens dann gehe ich von einer starken Verbreitung von ECC aus. 🙂

Noch Fragen, oder hast du Tipps im Umgang mit den deiner Meinung nach besten Verschlüsselungs-Algorithmen?
Wie generierst du deine Schlüssel? Schreibt bitte ein Kommentar!

3 thoughts on “Sind Krypto-Algorithmen wie AES knackbar?”

    1. Danke Josef für dein Lob!

      Bei der Recherche zu dem Artikel habe ich erst erkannt wie alt unsere Crypto-Technologien eigentlich sind.

      Rund 40 Jahre sind es bei den RSA Schlüsseln und knapp 20 Jahre sind es beim AES-256. Wo einige Hash-Algorithmen heute errechenbar sind, halten (größere) RSA-Schlüssel und die AES-Schlüssel bisherigen Angriffen stand. Wirklich auf der Suche bin ich noch nach einem passenden Schutz für private (Verschlüsselungs-)Schlüssel die keine Hardware wie Crypto-Token oder Smartcard erfordern. Interessiert lese ich aktuell Informationen zu Intel SGX, sobald die Technologie auch in virtuellen Umgebungen greifbar ist, wäre das meine erste Wahl. Vielleicht schreibe ich dazu meinen nächsten Verschlüsselt.IT Beitrag.

      Sicher Grüße, Andreas

  1. Hier ein kritisches Kommentar zu meinem Beitrag, dass mich per Email erreicht hat:

    Im Post zu Algorithmen geht mir der gaengigste Modus ab: GCM (CTR + GHASH). Durch Carry-less multiplication instructions (PCLMULQDQ, PCLMULLQLQDQ) ab Westmere in Intel Prozessoren (und spaeter AMD) ist der auf x86_64 auch ziemlich schnell. Auch ein Hinweis auf AEAD (Authenticated Encryption with Associated Data) – dabei sparst du dir die HMAC – GCM ist z.B. so ein Modus. Bei allen Modi mit Countern muss man darauf achten Nonces (du sprichst hier von IV – streng genommen ist das was anderes) nicht zu wiederholen. Das passiert idR Herstellern leider tatsaechlich — wir hatten dazu letztes Jahr ein Paper und einen BlackHat Talk (https://github.com/nonce-disrespect/nonce-disrespect). OCB ist mmn. eigentlich der schoenste Modus. In OpenSSL gibts optimized Assembly fuer x86_64 die GCM trotz Hardwarebeschleunigung auf einigen Prozessorgenerationen schlaegt. In Zukunft wird man bestimmt vermehrt NMR (Nonce Misuse Resistant) Modi sehen, in der CAESAR competition sind einige dabei, aber es scheint da nicht besonders viel Wert drauf gelegt zu werden – die competition ist ohnehin halb-tot.
    Das die gaengigen NIST ECC Kurven Backdoored sind ist Unsinn – da sind sich eigentlich alle Experten einig (ganz interessant dazu: Section 3.1 in https://eprint.iacr.org/2015/1018.pdf). djb macht natuerlich gerne Werbung fuer seine eigenen Kurven. Die djb-monokultur find ich allerdings auch bedenklich.

    Die Modis GCM und AEAD werde ich gerne ergänzen, wenn ich mal wieder etwas Zeit finde. Aktuell hält mich das Thema DSGVO & Verschlüsselung ganz schön auf Trab.

    Warum? Die DSGVO schreibt Verschlüsselung in Artikel 32 quasi vor:
    Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; diese Maßnahmen schließen unter anderem Folgendes ein:
    a) die Pseudonymisierung und Verschlüsselung personenbezogener Daten; …

    Sicher Grüße, Andreas

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*