Encryption & cryptography

Wenn eine Datenbank kompromittiert wird, lautet die erste Frage immer gleich: Sind die gehashten Passwörter sicher? Die Antwort hängt vollständig davon ab, wie diese Hashes erzeugt wurden. SHA-256 selbst kann nicht entschlüsselt werden — es ist eine kryptografische Einweg-Hashfunktion, kein Verschlüsselungsalgorithmus. Aber „kann nicht entschlüsselt werden" bedeutet nicht dasselbe wie „kann nicht geknackt werden".

Was ist SHA-256

SHA-256 (Secure Hash Algorithm 256-bit) ist eine kryptografische Hashfunktion aus der SHA-2-Familie, die von der NSA entwickelt und 2001 vom NIST unter FIPS 180-4 veröffentlicht wurde. Sie nimmt eine Eingabe beliebiger Länge und erzeugt eine feste 256-Bit-(32-Byte-)Ausgabe — den Hash oder Digest. Die Ausgabe erscheint immer zufällig, und dieselbe Eingabe erzeugt immer dieselbe Ausgabe.

SHA-256 ist kein Verschlüsselungsalgorithmus. Es gibt keinen Schlüssel, und die Ausgabe kann nicht umgekehrt werden. Seine Aufgabe ist es, einen einzigartigen Fingerabdruck eines Datensatzes zu erzeugen — nicht diese Daten für eine spätere Wiederherstellung zu schützen.

Drei Eigenschaften definieren seine Sicherheit:

• Urbildresistenz. Bei gegebenem Hash kann die ursprüngliche Eingabe nicht gefunden werden.
• Kollisionsresistenz. Es können keine zwei verschiedenen Eingaben gefunden werden, die denselben Hash erzeugen.
• Lawineneffekt. Eine Änderung eines einzelnen Bits in der Eingabe kippt etwa die Hälfte der Ausgabe-Bits, wodurch das Ergebnis völlig unvorhersehbar wird.

SHA-256 wird in TLS-Zertifikaten, Code-Signierung, Git-Commit-Integrität, Bitcoins Proof-of-Work-Mechanismus und (in Kombination mit korrekter Schlüsselableitung) bei der Passwortspeicherung verwendet. Es ist eines der am weitesten verbreiteten kryptografischen Primitive in Produktivsystemen heute.

Hashing vs. Verschlüsselung: Warum SHA-256 nicht entschlüsselt werden kann

SHA-256 ist eine kryptografische Hashfunktion — eine Einweg-Transformation. Verschlüsselung ist eine Zweiwege-Operation: Daten werden mit einem Schlüssel verschlüsselt und mit einem Schlüssel entschlüsselt. Hashing hat keinen Schlüssel und keinen Rückweg. Bei einem gegebenen SHA-256-Digest gibt es keine mathematische Operation, die die ursprüngliche Eingabe wiederherstellt.

Die Eigenschaft, die dies ermöglicht, heißt Urbildresistenz: Es muss rechnerisch unmöglich sein, eine Eingabe m zu finden, sodass SHA256(m) = h für einen gegebenen Hash h gilt. Eine verwandte Eigenschaft, der Lawineneffekt, bedeutet, dass die Änderung eines einzelnen Bits in der Eingabe etwa die Hälfte der Ausgabe-Bits kippt — was es unmöglich macht, durch kleine Anpassungen „rückwärts zu arbeiten".

Die Unterscheidung ist in der Praxis wichtig. Wenn ein Entwickler Passwörter mittels AES-Verschlüsselung statt Hashing speichert, legt ein Verlust des Verschlüsselungsschlüssels jedes Passwort in der Datenbank offen. Ein Hash hat keinen Schlüssel, der gestohlen werden kann.

Wie der SHA-256-Algorithmus funktioniert (Schritt für Schritt)

SHA-256 ist in NIST FIPS 180-4 definiert und gehört zur SHA-2-Familie. Er verarbeitet Eingaben beliebiger Länge und erzeugt eine deterministische 256-Bit-Ausgabe. Die Kernstruktur ist die Merkle-Damgård-Konstruktion: Die Nachricht wird in Blöcke fester Größe aufgeteilt, jeder Block wird durch eine Kompressionsfunktion verarbeitet, und die Ausgaben werden verkettet.

Schritt 1: Vorverarbeitung und Padding

Die Eingabenachricht wird aufgefüllt, sodass ihre Gesamtlänge ein Vielfaches von 512 Bits ist. Das Padding beginnt immer mit einem 1-Bit, gefolgt von genügend 0-Bits, gefolgt von einer 64-Bit-Darstellung der ursprünglichen Nachrichtenlänge. Dieser Schritt ist obligatorisch, auch wenn die Nachricht bereits genau passt — der Algorithmus muss immer wissen, wo die Nachricht endet.

Schritt 2: Nachrichtenplanung

Die aufgefüllte Nachricht wird in 512-Bit-Blöcke zerlegt. Jeder Block wird in sechzehn 32-Bit-Wörter unterteilt. Diese sechzehn Wörter werden dann mithilfe einer Mischung aus bitweisen Rotationen und XOR-Operationen zu einem 64-Wort-Nachrichtenplan erweitert. Diese Erweiterung stellt sicher, dass jedes Bit der ursprünglichen Eingabe den Kompressionsschritt beeinflusst.

Schritt 3: Die Kompressionsfunktion

Hier findet die eigentliche Arbeit statt. SHA-256 verwaltet acht 32-Bit-Arbeitsvariablen (a bis h), die mit Konstanten initialisiert werden, die aus den Nachkommastellen der Quadratwurzeln der ersten acht Primzahlen abgeleitet sind. Über 64 Runden werden diese Variablen mithilfe von bitweisen AND-, OR-, XOR- und NOT-Operationen sowie modularer Addition aktualisiert. Zwei nichtlineare Funktionen — Ch(e, f, g) und Maj(a, b, c) — führen eine Komplexität ein, die die Beziehung zwischen Eingabe und Ausgabe undurchsichtig macht. Nach allen 64 Runden werden die Arbeitsvariablen wieder zu den Anfangswerten für diesen Block addiert.

Schritt 4: Endgültige Ausgabe

Nachdem alle Blöcke verarbeitet wurden, werden die acht Arbeitsvariablen verkettet, um den endgültigen 256-Bit-Digest zu erzeugen. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe. Jede Änderung an der Eingabe — selbst ein einzelnes Zeichen — erzeugt einen völlig anderen Hash.

Wenn SHA-256 nicht entschlüsselt werden kann, wie knacken Hacker es dann?

SHA-256 ist mathematisch solide. Der Algorithmus selbst hat nach mehr als zwei Jahrzehnten Kryptoanalyse keine bekannten praktischen Schwächen. Was versagt, ist nicht der Algorithmus — es ist die Art und Weise, wie Passwörter damit gespeichert werden.

Brute-Force-Angriffe

Ein Brute-Force-Angriff kehrt den Hash nicht um. Er rät. Der Angreifer hasht Passwortkandidaten (Wörterbuchwörter, gängige Muster, Zeichenkombinationen) und vergleicht die Ausgabe mit dem gestohlenen Hash. Wenn die Hashes übereinstimmen, ist das Passwort gefunden. Die Geschwindigkeit von SHA-256 ist hier das Problem: Eine einzelne Nvidia RTX 4090 GPU kann etwa 164 Milliarden SHA-256-Hashes pro Sekunde berechnen (Specops Software, 2025). Bei dieser Rate wird ein achtstelliges Kleinbuchstaben-Passwort in Sekunden geknackt.

Rainbow-Table-Angriffe

Eine Rainbow Table ist eine vorberechnete Datenbank von Hash-zu-Klartext-Zuordnungen. Anstatt spontan zu hashen, schlägt der Angreifer den gestohlenen Hash in der Tabelle nach und liest das ursprüngliche Passwort ab. Tabellen für gängige Passwortformate können im Voraus generiert und für mehrere Datenlecks wiederverwendet werden. Kollisionsresistenz — die Eigenschaft, dass keine zwei Eingaben denselben Hash erzeugen sollten — ist nicht das, was Rainbow Tables ausnutzen. Sie nutzen die Tatsache aus, dass gängige Passwörter vorhersehbare, wiederholbare Hashes erzeugen.

Beide Angriffe haben eine gemeinsame Voraussetzung: Der Hash muss ungesalzen sein. Fügen Sie ein Salt hinzu, und beide Angriffe werden dramatisch teurer.

Warum reines SHA-256 für die Passwortspeicherung ungeeignet ist

SHA-256 wurde für Geschwindigkeit entwickelt. Für seine vorgesehenen Anwendungen — Überprüfung der Dateiintegrität, Signierung von Zertifikaten, Absicherung von Blockchain-Transaktionen — ist Geschwindigkeit ein Vorteil. Für die Passwortspeicherung ist Geschwindigkeit ein Nachteil.

Das Problem: SHA-256 ist zu schnell

Bei 164 Milliarden Hashes pro Sekunde auf Consumer-Hardware kann ein Angreifer den gesamten Raum von achtstelligen Passwörtern mit Groß- und Kleinbuchstaben, Ziffern und Symbolen in weniger als einer Stunde durchprobieren. Das OWASP Password Storage Cheat Sheet ist eindeutig: „Schnelle Hash-Algorithmen wie SHA-256 sind für die Passwortspeicherung nicht geeignet, da sie Angreifern ermöglichen, schnell eine große Anzahl von Versuchen durchzuführen."

Lösung 1: Salting

Ein Salt ist eine eindeutige, zufällig generierte Zeichenkette, die vor dem Hashen an jedes Passwort angehängt wird. SHA256("password") erzeugt immer denselben Hash. SHA256("password" + "x7kQ2mNp") erzeugt einen völlig anderen — und jeder Benutzer erhält ein anderes Salt. Dies macht Rainbow Tables vollständig wirkungslos: Der Angreifer kann keine Hashes für gesalzene Eingaben vorberechnen, ohne das Salt jedes Benutzers zu kennen. Es bedeutet auch, dass zwei Benutzer mit demselben Passwort unterschiedliche Hashes in der Datenbank haben.

Lösung 2: Key Stretching mit PBKDF2

Salting verhindert vorberechnete Lookups, verlangsamt aber keine Brute-Force-Angriffe. Dafür ist Key Stretching erforderlich. PBKDF2 (Password-Based Key Derivation Function 2) wendet eine pseudozufällige Funktion — typischerweise HMAC-SHA-256 — tausende Male nacheinander an. Jede Iteration kostet Zeit. Die 164 Milliarden Hashes pro Sekunde des Angreifers sinken auf einen Bruchteil davon, wenn jeder „Versuch" 600.000 Iterationen erfordert.

OWASP empfiehlt PBKDF2 mit HMAC-SHA-256 und mindestens 600.000 Iterationen für FIPS-140-Konformität. Argon2id ist die bevorzugte Wahl, wenn keine FIPS-Konformität erforderlich ist, da es zusätzlich Speicherhärte bietet.

Reines SHA-256 vs. PBKDF2-HMAC-SHA256: Sicherheitsvergleich bei der Passwortspeicherung

Ist SHA-256 anfällig für Quantencomputer?

Grovers Algorithmus gibt einem Quantencomputer eine quadratische Beschleunigung bei unstrukturierten Suchproblemen. Angewandt auf SHA-256 reduziert er die effektive Sicherheit von 2²⁵⁶ Operationen auf 2¹²⁸ Operationen. Das klingt alarmierend, bis man das Ausmaß berücksichtigt: 2¹²⁸ sind ungefähr 3,4×10³⁸. Ein Quantencomputer, der mit 10 Milliarden Operationen pro Sekunde läuft, würde etwa 3,4×10²⁸ Jahre benötigen, um die Hälfte des Suchraums zu durchsuchen — Größenordnungen länger als das Alter des Universums.

Shors Algorithmus, der RSA und Elliptische-Kurven-Kryptografie durch effizientes Faktorisieren großer ganzer Zahlen bricht, gilt nicht für Hashfunktionen. Die Sicherheit von SHA-256 basiert nicht auf der Faktorisierung ganzer Zahlen.

NIST standardisiert aktiv Post-Quanten-Algorithmen (FIPS 203, 204, 205 wurden 2024 finalisiert), hauptsächlich mit Fokus auf asymmetrische Kryptografie. SHA-256 steht für die absehbare Zukunft nicht auf der Ersatzliste. Die praktische Bedrohung für SHA-256 durch Quantencomputing bleibt theoretisch.

Wie Enterprise-Passwortmanager Kryptografie sicher einsetzen

Enterprise-Passwortmanager, die Zero-Knowledge-Prinzipien befolgen, wenden dieselben kryptografischen Bausteine an, die in diesem Artikel behandelt werden (SHA-256, PBKDF2, HMAC, AES-256), kombinieren sie jedoch zu einer mehrschichtigen Architektur, bei der der Server niemals Klartextdaten oder die Schlüssel zur Entschlüsselung besitzt. Die Sicherheitsgarantie ergibt sich aus dem Design, nicht aus dem Vertrauen in den Server.

Das Passwork-Zwei-Ebenen-Verschlüsselungsmodell

Zu wissen, dass reines SHA-256 für die Passwortspeicherung unzureichend ist, ist eine Sache. Die korrekte Alternative unternehmensweit zu implementieren, ist eine andere. Hier ist die Architektur des Tools genauso wichtig wie der Algorithmus.

Passwork basiert auf einer Zero-Knowledge-Architektur: Der Server besitzt niemals genügend Informationen, um Benutzerdaten zu entschlüsseln. Das Masterpasswort verlässt niemals das Gerät des Benutzers. Alle kryptografischen Schlüssel werden clientseitig generiert. Der Server speichert nur verschlüsselte Daten und verschlüsselte Schlüssel — die Entschlüsselung ist nur auf dem Client möglich.

Die Verschlüsselungskette funktioniert wie folgt, wie in Passworks Kryptografie-Übersicht dokumentiert:

1. Masterpasswort (vom Benutzer eingegeben) → PBKDF2 mit SHA-256, 300.000 Iterationen
2. Masterschlüssel (512 Bits) → AES-256-CBC
3. Privater RSA-Schlüssel (2048 Bits, RSA-OAEP)
4. Tresorschlüssel (256 Bits) → AES-256-CBC
5. Datensatzschlüssel (256 Bits) → AES-256-CBC
6. Datensatzdaten (Passwörter, Geheimnisse, Dateien — verschlüsselt im Ruhezustand)

Auf der Serverseite verschlüsselt eine separate AES-256-CFB-Schicht die Datenbank unabhängig. Jeder Datensatz ist doppelt verschlüsselt: einmal vom Client, bevor er das Gerät verlässt, einmal vom Server, bevor er auf die Festplatte geschrieben wird.

PBKDF2 mit 300.000 clientseitigen Iterationen entspricht den NIST-Empfehlungen (≥310.000 für SHA-256) und übertrifft das OWASP-Minimum für die meisten Einsatzszenarien. Das serverseitige PBKDF2 läuft mit 600.000 Iterationen — und erfüllt damit direkt die FIPS-140-Schwelle.

Diese Architektur bedeutet, dass ein Datenbankleck nichts Verwertbares liefert. Ein Angreifer, der die Datenbank exfiltriert, erhält AES-256-verschlüsselte Blobs, die von Schlüsseln abgeleitet wurden, die niemals auf dem Server gespeichert waren.

Fazit

SHA-256 ist theoretisch unknackbar. Der Algorithmus hat über zwei Jahrzehnte Kryptoanalyse ohne einen praktischen Angriff überstanden. Aber der Algorithmus ist nur so stark wie seine Implementierung. Speichern Sie Passwörter als reine SHA-256-Hashes, und eine einzelne GPU kann Milliarden von Kandidaten pro Sekunde testen. Fügen Sie ein Salt hinzu und wenden Sie PBKDF2 mit ausreichenden Iterationen an, und dieselbe Hardware wird gegen Ihre Datenbank nutzlos.

Die Lücke zwischen „SHA-256 ist sicher" und „unsere Passwörter sind sicher" wird durch korrekte Implementierung gefüllt — Salting, Key Stretching und eine Zero-Knowledge-Architektur, die sicherstellt, dass der Server niemals die Schlüssel besitzt, die zur Entschlüsselung von Benutzerdaten benötigt werden.

Wenn Ihr Team Unternehmensanmeldedaten verwaltet, schützt Passwork diese durch Zero-Knowledge-Architektur, clientseitige AES-256-Verschlüsselung und PBKDF2-Key-Stretching mit 300.000 Iterationen — sodass eine Serverkompromittierung nichts Verwertbares offenlegt. Passwork ist sowohl als selbstgehostete Bereitstellung für Organisationen verfügbar, die vollständige Infrastrukturkontrolle benötigen, als auch als Cloud-Lösung für Teams, die dieselben kryptografischen Garantien ohne eigene Serververwaltung wünschen.

FAQ: SHA-256 erklärt

Kann man SHA-256 entschlüsseln?

Nein. SHA-256 ist eine kryptografische Einweg-Hashfunktion. Es gibt keinen Schlüssel, keinen Umkehralgorithmus und keine mathematische Operation, die die ursprüngliche Eingabe aus einem Hash wiederherstellt. Was Angreifer tun können, ist raten — indem sie Passwortkandidaten hashen und die Ausgabe vergleichen. Das ist Knacken, nicht Entschlüsselung, und es funktioniert nur gegen schwache oder ungesalzene Hashes.

Was ist der Unterschied zwischen SHA-256-Hashing und Verschlüsselung?

Verschlüsselung ist mit dem richtigen Schlüssel umkehrbar. Hashing ist unter keinen Umständen umkehrbar. SHA-256 nimmt eine Eingabe beliebiger Länge und erzeugt eine feste 256-Bit-Ausgabe. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe, aber der Prozess kann nicht rückwärts ausgeführt werden. Verschlüsselung bewahrt die Fähigkeit, die Originaldaten wiederherzustellen; Hashing zerstört sie absichtlich.

Was ist der Lawineneffekt bei SHA-256?

Der Lawineneffekt bedeutet, dass eine Änderung eines einzelnen Bits in der Eingabe etwa die Hälfte der Ausgabe-Bits kippt. Ändern Sie ein Zeichen in einem Passwort, und der resultierende SHA-256-Hash sieht völlig anders aus als der ursprüngliche. Diese Eigenschaft verhindert, dass Angreifer Teilwissen über eine Eingabe nutzen können, um den Hash-Suchraum einzugrenzen.

Was ist PBKDF2 und warum ist es für die Passwortsicherheit wichtig?

PBKDF2 (Password-Based Key Derivation Function 2) wendet eine pseudozufällige Funktion — typischerweise HMAC-SHA-256 — iterativ auf ein Passwort und Salt an. Jede Iteration erhöht den Rechenaufwand. Bei 600.000 Iterationen steigt die benötigte Zeit pro Versuch um den Faktor 600.000 im Vergleich zu einem einzelnen SHA-256-Hash. Dies macht Brute-Force-Angriffe gegen korrekt gespeicherte Passwörter selbst mit GPU-Rechenleistung unpraktikabel.

Ist SHA-256 anfällig für Quantencomputer-Angriffe?

Praktisch nicht. Grovers Algorithmus reduziert die effektive Sicherheit von SHA-256 von 2²⁵⁶ auf 2¹²⁸ Operationen. Bei 2¹²⁸ würde selbst ein hypothetischer Quantencomputer mit 10 Milliarden Operationen pro Sekunde mehr Zeit als das Alter des Universums benötigen, um den Suchraum zu durchsuchen. NISTʼs Post-Quanten-Kryptografie-Standardisierungsinitiative zielt auf asymmetrische Algorithmen ab, nicht auf SHA-256.

Was ist die Merkle-Damgård-Konstruktion?

Die Merkle-Damgård-Konstruktion ist das strukturelle Rahmenwerk, das SHA-256 zugrunde liegt. Die Eingabenachricht wird in 512-Bit-Blöcke unterteilt. Jeder Block wird durch eine Kompressionsfunktion verarbeitet, die den aktuellen Block und die Ausgabe des vorherigen Blocks als Eingaben nimmt. Die Ausgaben werden sequenziell verkettet, sodass der endgültige Hash von jedem Bit der gesamten Eingabenachricht abhängt.

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht nicht den Zugriff. API-Schlüssel, KI-Agenten-Anmeldedaten und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Stunde-Null-Auslösern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Secrets-Rotation-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von Erstellung und Besitz bis zu sicherer Rotation, Notfallwiderruf und Audit-Nachweis.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und Prävention

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Millionen Geräten. Brute Force hat sich skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute umsetzen kann.

Passwork BlogAlex Muntyan

Cuando se produce una brecha en una base de datos, la primera pregunta siempre es la misma: ¿están seguras las contraseñas hasheadas? La respuesta depende completamente de cómo se generaron esos hashes. SHA-256 en sí no se puede descifrar — es una función hash criptográfica unidireccional, no un algoritmo de cifrado. Pero «no se puede descifrar» no es lo mismo que «no se puede crackear».

Qué es SHA-256

SHA-256 (Secure Hash Algorithm de 256 bits) es una función hash criptográfica de la familia SHA-2, desarrollada por la NSA y publicada por el NIST en 2001 bajo FIPS 180-4. Toma una entrada de cualquier longitud y produce una salida fija de 256 bits (32 bytes) — el hash, o resumen. La salida siempre parece aleatoria, y la misma entrada siempre produce la misma salida.

SHA-256 no es un algoritmo de cifrado. No tiene clave, y su salida no puede revertirse. Su función es producir una huella digital única de un dato — no proteger ese dato para su recuperación posterior.

Tres propiedades definen su seguridad:

• Resistencia a la preimagen. Dado un hash, no se puede encontrar la entrada original.
• Resistencia a colisiones. No se pueden encontrar dos entradas diferentes que produzcan el mismo hash.
• Efecto avalancha. Un cambio de un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida, haciendo el resultado completamente impredecible.

SHA-256 se utiliza en certificados TLS, firma de código, integridad de commits en Git, el mecanismo de prueba de trabajo de Bitcoin y (cuando se combina con una derivación de claves adecuada) almacenamiento de contraseñas. Es una de las primitivas criptográficas más ampliamente desplegadas en sistemas de producción actualmente.

Hash vs. cifrado: Por qué SHA-256 no se puede descifrar

SHA-256 es una función hash criptográfica — una transformación unidireccional. El cifrado es una operación bidireccional: se cifran datos con una clave y se descifran con una clave. El hashing no tiene clave ni camino de retorno. Dado un resumen SHA-256, no existe ninguna operación matemática que recupere la entrada original.

La propiedad que hace esto posible se llama resistencia a la preimagen: debe ser computacionalmente inviable encontrar cualquier entrada m tal que SHA256(m) = h para un hash dado h. Una propiedad relacionada, el efecto avalancha, significa que cambiar un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida — haciendo imposible «trabajar hacia atrás» mediante pequeños ajustes.

La distinción es importante en la práctica. Si un desarrollador almacena contraseñas usando cifrado AES en lugar de hashing, una brecha de la clave de cifrado expone todas las contraseñas de la base de datos. Un hash no tiene clave que robar.

Cómo funciona el algoritmo SHA-256 (paso a paso)

SHA-256 está definido en NIST FIPS 180-4 y pertenece a la familia SHA-2. Procesa entradas de cualquier longitud y produce una salida determinista de 256 bits. La estructura central es la construcción Merkle-Damgård: el mensaje se divide en bloques de tamaño fijo, cada bloque se procesa a través de una función de compresión, y las salidas se encadenan.

Paso 1. Preprocesamiento y relleno

El mensaje de entrada se rellena para que su longitud total sea múltiplo de 512 bits. El relleno siempre comienza con un bit 1, seguido de suficientes bits 0, seguidos de una representación de 64 bits de la longitud del mensaje original. Este paso es obligatorio incluso si el mensaje ya encaja perfectamente — el algoritmo siempre debe saber dónde termina el mensaje.

Paso 2. Programación del mensaje

El mensaje rellenado se divide en bloques de 512 bits. Cada bloque se divide en dieciséis palabras de 32 bits. Esas dieciséis palabras se expanden luego en una programación de mensajes de 64 palabras usando una combinación de rotaciones a nivel de bits y operaciones XOR. Esta expansión asegura que cada bit de la entrada original influya en el paso de compresión.

Paso 3. La función de compresión

Aquí es donde ocurre el trabajo. SHA-256 mantiene ocho variables de trabajo de 32 bits (a hasta h), inicializadas con constantes derivadas de las partes fraccionarias de las raíces cuadradas de los primeros ocho números primos. A lo largo de 64 rondas, estas variables se actualizan usando operaciones AND, OR, XOR y NOT a nivel de bits, más suma modular. Dos funciones no lineales — Ch(e, f, g) y Maj(a, b, c) — introducen complejidad que hace opaca la relación entre entrada y salida. Después de las 64 rondas, las variables de trabajo se suman de nuevo a los valores iniciales de ese bloque.

Paso 4. Salida final

Después de procesar todos los bloques, las ocho variables de trabajo se concatenan para producir el resumen final de 256 bits. La misma entrada siempre produce la misma salida. Cualquier cambio en la entrada — incluso un solo carácter — produce un hash completamente diferente.

Si SHA-256 no se puede descifrar, ¿cómo lo crackean los hackers?

SHA-256 es matemáticamente sólido. El algoritmo en sí no tiene debilidades prácticas conocidas después de más de dos décadas de criptoanálisis. Lo que falla no es el algoritmo — es la forma en que se almacenan las contraseñas usándolo.

Ataques de fuerza bruta

Un ataque de fuerza bruta no revierte el hash. Adivina. El atacante hashea contraseñas candidatas (palabras de diccionario, patrones comunes, combinaciones de caracteres) y compara la salida con el hash robado. Si los hashes coinciden, la contraseña está encontrada. La velocidad de SHA-256 es el problema aquí: una sola GPU Nvidia RTX 4090 puede calcular aproximadamente 164 mil millones de hashes SHA-256 por segundo (Specops Software, 2025). A ese ritmo, una contraseña de ocho caracteres en minúsculas se crackea en segundos.

Ataques de tablas rainbow

Una tabla rainbow es una base de datos precalculada de mapeos hash-a-texto-plano. En lugar de hashear sobre la marcha, el atacante busca el hash robado en la tabla y lee la contraseña original. Las tablas para formatos de contraseña comunes pueden generarse con anticipación y reutilizarse en múltiples brechas. La resistencia a colisiones — la propiedad de que ninguna entrada debería producir el mismo hash — no es lo que explotan las tablas rainbow. Explotan el hecho de que las contraseñas comunes producen hashes predecibles y repetibles.

Ambos ataques comparten un único prerrequisito: el hash debe estar sin sal. Añada una sal, y ambos ataques se vuelven dramáticamente más costosos.

Por qué SHA-256 simple es malo para el almacenamiento de contraseñas

SHA-256 fue diseñado para ser rápido. Para sus usos previstos — verificar integridad de archivos, firmar certificados, asegurar transacciones blockchain — la velocidad es una característica. Para el almacenamiento de contraseñas, la velocidad es una vulnerabilidad.

El problema: SHA-256 es demasiado rápido

A 164 mil millones de hashes por segundo en hardware de consumo, un atacante puede agotar todo el espacio de contraseñas de ocho caracteres que contienen mayúsculas, minúsculas, dígitos y símbolos en menos de una hora. La guía de almacenamiento de contraseñas de OWASP es explícita: «Los algoritmos de hash rápidos como SHA-256 no son adecuados para el almacenamiento de contraseñas porque permiten a los atacantes realizar grandes cantidades de intentos rápidamente».

Solución 1: Salting

Una sal es una cadena única generada aleatoriamente que se añade a cada contraseña antes del hashing. SHA256("password") siempre produce el mismo hash. SHA256("password" + "x7kQ2mNp") produce uno completamente diferente — y cada usuario obtiene una sal diferente. Esto anula completamente las tablas rainbow: el atacante no puede precalcular hashes para entradas con sal sin conocer la sal de cada usuario. También significa que dos usuarios con la misma contraseña terminan con hashes diferentes en la base de datos.

Solución 2: Estiramiento de claves con PBKDF2

El salting anula las búsquedas precalculadas, pero no ralentiza los ataques de fuerza bruta. Eso requiere estiramiento de claves. PBKDF2 (Password-Based Key Derivation Function 2) aplica una función pseudoaleatoria — típicamente HMAC-SHA-256 — miles de veces en secuencia. Cada iteración toma tiempo. Los 164 mil millones de hashes por segundo del atacante se reducen a una fracción cuando cada «intento» requiere 600.000 iteraciones.

OWASP recomienda PBKDF2 con HMAC-SHA-256 y al menos 600.000 iteraciones para cumplimiento FIPS-140. Argon2id es la opción preferida donde no se requiere cumplimiento FIPS, ya que también añade resistencia de memoria.

SHA-256 simple vs. PBKDF2-HMAC-SHA256: Comparación de seguridad en almacenamiento de contraseñas

¿Es SHA-256 vulnerable a las computadoras cuánticas?

El algoritmo de Grover proporciona a una computadora cuántica una aceleración cuadrática en problemas de búsqueda no estructurada. Aplicado a SHA-256, reduce la seguridad efectiva de 2²⁵⁶ operaciones a 2¹²⁸ operaciones. Eso suena alarmante hasta que se considera la escala: 2¹²⁸ es aproximadamente 3,4×10³⁸. Una computadora cuántica funcionando a 10 mil millones de operaciones por segundo necesitaría aproximadamente 3,4×10²⁸ años para agotar la mitad del espacio de búsqueda — órdenes de magnitud más que la edad del universo.

El algoritmo de Shor, que rompe RSA y la criptografía de curva elíptica factorizando eficientemente números enteros grandes, no se aplica a las funciones hash. La seguridad de SHA-256 no se basa en la factorización de enteros.

El NIST está estandarizando activamente algoritmos post-cuánticos (FIPS 203, 204, 205 fueron finalizados en 2024), principalmente dirigidos a criptografía asimétrica. SHA-256 no está en la lista de reemplazo para el futuro previsible. La amenaza práctica a SHA-256 por la computación cuántica sigue siendo teórica.

Cómo los gestores de contraseñas empresariales usan la criptografía de forma segura

Los gestores de contraseñas empresariales que siguen principios de conocimiento cero aplican los mismos bloques de construcción criptográficos cubiertos en este artículo (SHA-256, PBKDF2, HMAC, AES-256) pero los combinan en una arquitectura por capas donde el servidor nunca tiene datos en texto plano ni las claves para descifrarlos. La garantía de seguridad proviene del diseño, no de confiar en el servidor.

El modelo de cifrado de dos niveles de Passwork

Saber que SHA-256 simple es insuficiente para el almacenamiento de contraseñas es una cosa. Implementar la alternativa correcta en toda una empresa es otra. Aquí es donde la arquitectura de la herramienta importa tanto como el algoritmo.

Passwork está construido sobre una arquitectura de conocimiento cero: el servidor nunca tiene suficiente información para descifrar los datos del usuario. La contraseña maestra nunca abandona el dispositivo del usuario. Todas las claves criptográficas se generan del lado del cliente. El servidor almacena solo datos cifrados y claves cifradas — el descifrado solo es posible en el cliente.

La cadena de cifrado funciona de la siguiente manera, como se documenta en la descripción general de criptografía de Passwork:

1. Contraseña maestra (introducida por el usuario) → PBKDF2 con SHA-256, 300.000 iteraciones
2. Clave maestra (512 bits) → AES-256-CBC
3. Clave privada RSA (2048 bits, RSA-OAEP)
4. Clave de bóveda (256 bits) → AES-256-CBC
5. Clave de registro (256 bits) → AES-256-CBC
6. Datos de registro (contraseñas, secretos, archivos — cifrados en reposo)

En el lado del servidor, una capa separada AES-256-CFB cifra la base de datos de forma independiente. Cada registro está doblemente cifrado: una vez por el cliente antes de que abandone el dispositivo, una vez por el servidor antes de escribirse en disco.

PBKDF2 a 300.000 iteraciones del lado del cliente se alinea con las recomendaciones del NIST (≥310.000 para SHA-256) y supera el mínimo de OWASP para la mayoría de los contextos de implementación. El PBKDF2 del lado del servidor se ejecuta a 600.000 iteraciones — cumpliendo directamente con el umbral FIPS-140.

Esta arquitectura significa que una brecha de base de datos no produce nada utilizable. Un atacante que exfiltra la base de datos obtiene blobs cifrados con AES-256 derivados de claves que nunca se almacenaron en el servidor.

Conclusión

SHA-256 es teóricamente irrompible. El algoritmo ha sobrevivido más de dos décadas de criptoanálisis sin un ataque práctico. Pero el algoritmo solo es tan fuerte como su implementación. Almacene contraseñas como hashes SHA-256 simples, y una sola GPU puede probar miles de millones de candidatos por segundo. Añada una sal y aplique PBKDF2 con suficientes iteraciones, y el mismo hardware se vuelve inútil contra su base de datos.

La brecha entre «SHA-256 es seguro» y «nuestras contraseñas son seguras» se llena con una implementación correcta — salting, estiramiento de claves y una arquitectura de conocimiento cero que asegure que el servidor nunca tenga las claves necesarias para descifrar los datos del usuario.

Si su equipo gestiona credenciales corporativas, Passwork las protege mediante arquitectura de conocimiento cero, cifrado AES-256 del lado del cliente y estiramiento de claves PBKDF2 a 300.000 iteraciones — de modo que un compromiso del servidor no expone nada utilizable. Passwork está disponible tanto como implementación autoalojada para organizaciones que requieren control total de la infraestructura, como solución en la nube para equipos que desean las mismas garantías criptográficas sin gestionar sus propios servidores.

Preguntas frecuentes: SHA-256 explicado

¿Se puede descifrar SHA-256?

No. SHA-256 es una función hash criptográfica unidireccional. No hay clave, no hay algoritmo inverso, y no hay operación matemática que recupere la entrada original de un hash. Lo que los atacantes pueden hacer es adivinar — hasheando contraseñas candidatas y comparando la salida. Eso es cracking, no descifrado, y solo funciona contra hashes débiles o sin sal.

¿Cuál es la diferencia entre el hashing SHA-256 y el cifrado?

El cifrado es reversible con la clave correcta. El hashing no es reversible bajo ninguna circunstancia. SHA-256 toma una entrada de cualquier longitud y produce una salida fija de 256 bits. La misma entrada siempre produce la misma salida, pero el proceso no puede ejecutarse en reversa. El cifrado preserva la capacidad de recuperar los datos originales; el hashing los destruye deliberadamente.

¿Qué es el efecto avalancha en SHA-256?

El efecto avalancha significa que un cambio de un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida. Cambie un carácter en una contraseña, y el hash SHA-256 resultante parece completamente no relacionado con el original. Esta propiedad impide que los atacantes usen conocimiento parcial de una entrada para reducir el espacio de búsqueda del hash.

¿Qué es PBKDF2 y por qué importa para la seguridad de contraseñas?

PBKDF2 (Password-Based Key Derivation Function 2) aplica una función pseudoaleatoria — típicamente HMAC-SHA-256 — iterativamente a una contraseña y sal. Cada iteración añade coste computacional. A 600.000 iteraciones, el tiempo requerido por intento aumenta por un factor de 600.000 comparado con un solo hash SHA-256. Esto hace que los ataques de fuerza bruta contra contraseñas almacenadas correctamente sean impracticables incluso con hardware a escala de GPU.

¿Es SHA-256 vulnerable a ataques de computación cuántica?

No prácticamente. El algoritmo de Grover reduce la seguridad efectiva de SHA-256 de 2²⁵⁶ a 2¹²⁸ operaciones. A 2¹²⁸, incluso una hipotética computadora cuántica funcionando a 10 mil millones de operaciones por segundo requeriría más tiempo que la edad del universo para agotar el espacio de búsqueda. El esfuerzo de estandarización de criptografía post-cuántica del NIST se dirige a algoritmos asimétricos, no a SHA-256.

¿Qué es la construcción Merkle-Damgård?

La construcción Merkle-Damgård es el marco estructural subyacente a SHA-256. El mensaje de entrada se divide en bloques de 512 bits. Cada bloque se procesa a través de una función de compresión que toma el bloque actual y la salida del bloque anterior como entradas. Las salidas se encadenan secuencialmente, de modo que el hash final depende de cada bit de todo el mensaje de entrada.

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn't revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it's treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

When a database is breached, the first question is always the same: are the hashed passwords safe? The answer depends entirely on how those hashes were generated. SHA-256 itself cannot be decrypted — it is a one-way cryptographic hash function, not an encryption algorithm. But "cannot be decrypted" is not the same as "cannot be cracked."

What is SHA-256

SHA-256 (Secure Hash Algorithm 256-bit) is a cryptographic hash function from the SHA-2 family, developed by the NSA and published by NIST in 2001 under FIPS 180-4. It takes an input of any length and produces a fixed 256-bit (32-byte) output — the hash, or digest. The output always looks random, and the same input always produces the same output.

SHA-256 is not an encryption algorithm. It has no key, and its output cannot be reversed. Its job is to produce a unique fingerprint of a piece of data — not to protect that data for later retrieval.

Three properties define its security:

• Preimage resistance. Given a hash, you cannot find the original input.
• Collision resistance. You cannot find two different inputs that produce the same hash.
• Avalanche effect. A single-bit change in the input flips roughly half the output bits, making the result completely unpredictable.

SHA-256 is used in TLS certificates, code signing, Git commit integrity, Bitcoin's proof-of-work mechanism, and (when combined with proper key derivation) password storage. It is one of the most widely deployed cryptographic primitives in production systems today.

Hashing vs. encryption: Why SHA-256 cannot be decrypted

SHA-256 is a cryptographic hash function — a one-way transformation. Encryption is a two-way operation: you encrypt data with a key, and you decrypt it with a key. Hashing has no key and no reverse path. Given a SHA-256 digest, there is no mathematical operation that recovers the original input.

The property that makes this possible is called preimage resistance: it must be computationally infeasible to find any input m such that SHA256(m) = h for a given hash h. A related property, the avalanche effect, means that changing a single bit in the input flips roughly half of the output bits — making it impossible to "work backwards" by making small adjustments.

The distinction matters in practice. If a developer stores passwords using AES encryption rather than hashing, a breach of the encryption key exposes every password in the database. A hash has no key to steal.

How the SHA-256 algorithm works (step-by-step)

SHA-256 is defined in NIST FIPS 180-4 and belongs to the SHA-2 family. It processes input of any length and produces a deterministic 256-bit output. The core structure is the Merkle-Damgård construction: the message is split into fixed-size blocks, each block is processed through a compression function, and the outputs are chained together.

Step 1. Preprocessing and padding

The input message is padded so its total length is a multiple of 512 bits. Padding always begins with a 1 bit, followed by enough 0 bits, followed by a 64-bit representation of the original message length. This step is mandatory even if the message already fits neatly — the algorithm must always know where the message ends.

Step 2. Message scheduling

The padded message is parsed into 512-bit blocks. Each block is divided into sixteen 32-bit words. Those sixteen words are then expanded into a 64-word message schedule using a mix of bitwise rotations and XOR operations. This expansion ensures that every bit of the original input influences the compression step.

Step 3. The compression function

This is where the work happens. SHA-256 maintains eight 32-bit working variables (a through h), initialized to constants derived from the fractional parts of the square roots of the first eight prime numbers. Over 64 rounds, these variables are updated using bitwise AND, OR, XOR, and NOT operations, plus modular addition. Two non-linear functions — Ch(e, f, g) and Maj(a, b, c) — introduce complexity that makes the relationship between input and output opaque. After all 64 rounds, the working variables are added back to the initial values for that block.

Step 4. Final output

After all blocks are processed, the eight working variables are concatenated to produce the final 256-bit digest. The same input always produces the same output. Any change to the input — even a single character — produces a completely different hash.

If SHA-256 can't be decrypted, how do hackers crack it?

SHA-256 is mathematically sound. The algorithm itself has no known practical weaknesses after more than two decades of cryptanalysis. What fails is not the algorithm — it is the way passwords are stored using it.

Brute-force attacks

A brute-force attack does not reverse the hash. It guesses. The attacker hashes candidate passwords (dictionary words, common patterns, character combinations) and compares the output against the stolen hash. If the hashes match, the password is found. The speed of SHA-256 is the problem here: a single Nvidia RTX 4090 GPU can calculate approximately 164 billion SHA-256 hashes per second (Specops Software, 2025). At that rate, an eight-character lowercase password is cracked in seconds.

Rainbow table attacks

A rainbow table is a precomputed database of hash-to-plaintext mappings. Rather than hashing on the fly, the attacker looks up the stolen hash in the table and reads off the original password. Tables for common password formats can be generated in advance and reused across multiple breaches. Collision resistance — the property that no two inputs should produce the same hash — is not what rainbow tables exploit. They exploit the fact that common passwords produce predictable, repeatable hashes.

Both attacks share a single prerequisite: the hash must be unsalted. Add a salt, and both attacks become dramatically more expensive.

Why plain SHA-256 is bad for password storage

SHA-256 was designed to be fast. For its intended uses — verifying file integrity, signing certificates, securing blockchain transactions — speed is a feature. For password storage, speed is a liability.

The problem: SHA-256 is too fast

At 164 billion hashes per second on consumer hardware, an attacker can exhaust the entire space of eight-character passwords containing uppercase, lowercase, digits, and symbols in under an hour. OWASP's Password Storage Cheat Sheet is explicit: "Fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly."

Solution 1: Salting

A salt is a unique, randomly generated string appended to each password before hashing. SHA256("password") always produces the same hash. SHA256("password" + "x7kQ2mNp") produces a completely different one — and every user gets a different salt. This defeats rainbow tables entirely: the attacker cannot precompute hashes for salted inputs without knowing each user's salt. It also means two users with the same password end up with different hashes in the database.

Solution 2: Key stretching with PBKDF2

Salting defeats precomputed lookups, but it does not slow down brute-force attacks. That requires key stretching. PBKDF2 (Password-Based Key Derivation Function 2) applies a pseudorandom function — typically HMAC-SHA-256 — thousands of times in sequence. Each iteration takes time. The attacker's 164 billion hashes per second drops to a fraction of that when each "guess" requires 600,000 iterations.

OWASP recommends PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations for FIPS-140 compliance. Argon2id is the preferred choice where FIPS compliance is not required, as it also adds memory hardness.

Plain SHA-256 vs. PBKDF2-HMAC-SHA256: password storage security comparison

Is SHA-256 vulnerable to quantum computers?

Grover's algorithm gives a quantum computer a quadratic speedup on unstructured search problems. Applied to SHA-256, it reduces the effective security from 2²⁵⁶ operations to 2¹²⁸ operations. That sounds alarming until you consider the scale: 2¹²⁸ is approximately 3.4×10³⁸. A quantum computer running at 10 billion operations per second would need roughly 3.4×10²⁸ years to exhaust half the search space — orders of magnitude longer than the age of the universe.

Shor's algorithm, which breaks RSA and elliptic-curve cryptography by factoring large integers efficiently, does not apply to hash functions. SHA-256's security is not based on integer factorization.

NIST is actively standardizing post-quantum algorithms (FIPS 203, 204, 205 were finalized in 2024), primarily targeting asymmetric cryptography. SHA-256 is not on the replacement list for the foreseeable future. The practical threat to SHA-256 from quantum computing remains theoretical.

How enterprise password managers use cryptography securely

Enterprise password managers that follow zero-knowledge principles apply the same cryptographic building blocks covered in this article (SHA-256, PBKDF2, HMAC, AES-256) but combine them into a layered architecture where the server never holds plaintext data or the keys to decrypt it. The security guarantee comes from the design, not from trusting the server.

The Passwork two-level encryption model

Knowing that plain SHA-256 is insufficient for password storage is one thing. Implementing the correct alternative across an enterprise is another. This is where the architecture of the tool matters as much as the algorithm.

Passwork is built on a zero-knowledge architecture: the server never holds enough information to decrypt user data. The master password never leaves the user's device. All cryptographic keys are generated client-side. The server stores only encrypted data and encrypted keys — decryption is only possible on the client.

The encryption chain works as follows, as documented in Passwork's cryptography overview:

1. Master password (entered by the user) → PBKDF2 with SHA-256, 300,000 iterations
2. Master key (512 bits) → AES-256-CBC
3. Private RSA key (2048 bits, RSA-OAEP)
4. Vault key (256 bits) → AES-256-CBC
5. Record key (256 bits) → AES-256-CBC
6. Record data (passwords, secrets, files — encrypted at rest)

On the server side, a separate AES-256-CFB layer encrypts the database independently. Every record is double-encrypted: once by the client before it leaves the device, once by the server before it is written to disk.

PBKDF2 at 300,000 client-side iterations aligns with NIST's recommendations (≥310,000 for SHA-256) and exceeds the OWASP minimum for most deployment contexts. The server-side PBKDF2 runs at 600,000 iterations — meeting the FIPS-140 threshold directly.

This architecture means that a database breach yields nothing actionable. An attacker who exfiltrates the database gets AES-256-encrypted blobs derived from keys that were never stored on the server.

Conclusion

SHA-256 is theoretically unbreakable. The algorithm has survived over two decades of cryptanalysis without a practical attack. But the algorithm is only as strong as its implementation. Store passwords as plain SHA-256 hashes, and a single GPU can test billions of candidates per second. Add a salt and apply PBKDF2 with sufficient iterations, and the same hardware becomes useless against your database.

The gap between "SHA-256 is secure" and "our passwords are secure" is filled by correct implementation — salting, key stretching, and a zero-knowledge architecture that ensures the server never holds the keys needed to decrypt user data.

If your team manages corporate credentials, Passwork protects them through zero-knowledge architecture, client-side AES-256 encryption, and PBKDF2 key stretching at 300,000 iterations — so a server compromise exposes nothing actionable. Passwork is available both as a self-hosted deployment for organizations that require full infrastructure control, and as a cloud solution for teams that want the same cryptographic guarantees without managing their own servers.

FAQ: SHA-256 explained

Can you decrypt SHA-256?

No. SHA-256 is a one-way cryptographic hash function. There is no key, no reverse algorithm, and no mathematical operation that recovers the original input from a hash. What attackers can do is guess — by hashing candidate passwords and comparing the output. That is cracking, not decryption, and it only works against weak or unsalted hashes.

What is the difference between SHA-256 hashing and encryption?

Encryption is reversible with the correct key. Hashing is not reversible under any circumstances. SHA-256 takes an input of any length and produces a fixed 256-bit output. The same input always produces the same output, but the process cannot be run in reverse. Encryption preserves the ability to recover the original data; hashing deliberately destroys it.

What is the avalanche effect in SHA-256?

The avalanche effect means that a single-bit change in the input flips approximately half of the output bits. Change one character in a password, and the resulting SHA-256 hash looks completely unrelated to the original. This property prevents attackers from using partial knowledge of an input to narrow down the hash search space.

What is PBKDF2 and why does it matter for password security?

PBKDF2 (Password-Based Key Derivation Function 2) applies a pseudorandom function — typically HMAC-SHA-256 — iteratively to a password and salt. Each iteration adds computational cost. At 600,000 iterations, the time required per guess increases by a factor of 600,000 compared to a single SHA-256 hash. This makes brute-force attacks against properly stored passwords impractical even with GPU-scale hardware.

Is SHA-256 vulnerable to quantum computing attacks?

Not practically. Grover's algorithm reduces SHA-256's effective security from 2²⁵⁶ to 2¹²⁸ operations. At 2¹²⁸, even a hypothetical quantum computer running at 10 billion operations per second would require more time than the age of the universe to exhaust the search space. NIST's post-quantum cryptography standardization effort targets asymmetric algorithms, not SHA-256.

What is the Merkle-Damgård construction?

The Merkle-Damgård construction is the structural framework underlying SHA-256. The input message is divided into 512-bit blocks. Each block is processed through a compression function that takes the current block and the output of the previous block as inputs. The outputs are chained sequentially, so the final hash depends on every bit of the entire input message.

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn’t revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it’s treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

AES-256-Verschlüsselung ist eine symmetrische Blockchiffre, die einen 256-Bit-Schlüssel verwendet, um Daten in 14 Transformationsrunden zu verschlüsseln. Kein klassischer oder Quantencomputer kann sie innerhalb eines praktisch relevanten Zeitrahmens per Brute-Force knacken. Dennoch erleiden Organisationen, die AES-256 verwenden, weiterhin katastrophale Datenschutzverletzungen — weil Angreifer selten versuchen, die Chiffre zu brechen. Sie brechen die Systeme drumherum.

Diese Unterscheidung ist 2026 wichtiger denn je. KI-gesteuerte Angriffe beschleunigen den Diebstahl von Anmeldedaten und die Kompromittierung von Endpunkten. Die „Harvest Now, Decrypt Later"-Strategie bedeutet, dass Gegner heute verschlüsselte Daten horten und auf zukünftige Entschlüsselungsfähigkeiten setzen. Und NIST hat seine ersten Post-Quanten-Kryptografiestandards finalisiert, was berechtigte Fragen aufwirft, ob AES-256 noch in Ihre Sicherheitsarchitektur gehört.

Die kurze Antwort: ja. Die längere Antwort erfordert ein genaues Verständnis dessen, wovor AES-256 schützt, wovor nicht, und wie man es so einsetzt, dass die theoretische Stärke des Algorithmus in tatsächliche Sicherheit übersetzt wird.

Wichtigste Erkenntnisse

• AES-256 hat keine praktische Schwachstelle. Kein klassischer oder Quantencomputer kann einen 256-Bit-Schlüssel innerhalb eines machbaren Zeitrahmens per Brute-Force knacken. Der Algorithmus selbst ist nicht das Risiko.
• Grovers Algorithmus halbiert die Sicherheit von AES-256, eliminiert sie aber nicht. Ein Quanten-Angreifer reduziert die effektive Sicherheit auf 128 Bit — immer noch unknackbar durch jede bekannte oder prognostizierte Hardware.
• Die eigentliche Bedrohung ist Harvest Now, Decrypt Later (HNDL), nicht der Q-Day. Gegner archivieren heute verschlüsselte Daten. Die Migration des asymmetrischen Schlüsselaustauschs zu Post-Quanten-Algorithmen ist eine gegenwärtige Priorität, keine zukünftige.
• AES-256-GCM ist der richtige Modus für neue Implementierungen. CBC bietet nur Vertraulichkeit. GCM fügt integrierte Authentifizierung hinzu und ist in TLS 1.3 obligatorisch.
• 62 % der Datenschutzverletzungen betreffen den menschlichen Faktor. Angreifer umgehen die Verschlüsselung durch gestohlene Anmeldedaten, kompromittierte Endpunkte und schlechtes Schlüsselmanagement — nicht durch das Brechen der Chiffre.
• Schlüsselmanagement ist das schwächste Glied. Hardcodierte Schlüssel, Schlüssel, die neben den zu schützenden Daten gespeichert werden, und Schlüssel, die nie rotiert werden, sind gefährlicher als jeder bekannte kryptoanalytische Angriff.
• Zero-Knowledge-Architektur eliminiert das serverseitige Risiko. Wenn der Server niemals Klartext oder Entschlüsselungsschlüssel besitzt, liefert eine vollständige Serverkompromittierung nur nutzlosen Chiffretext.
• AES-256 erfüllt HIPAA, DSGVO und PCI DSS. Compliance erfordert eine korrekte Implementierung — Verschlüsselung im Ruhezustand, während der Übertragung und dokumentiertes Schlüsselmanagement — nicht nur das Vorhandensein des Algorithmus.

Was ist AES-256?

AES-256 (Advanced Encryption Standard mit einem 256-Bit-Schlüssel) ist eine symmetrische Blockchiffre, die in NIST FIPS 197 standardisiert ist. Sie verschlüsselt Daten in 128-Bit-Blöcken unter Verwendung eines 256-Bit-Schlüssels über 14 Transformationsrunden. Derselbe Schlüssel verschlüsselt und entschlüsselt die Daten. Kein bekannter klassischer oder Quantenangriff kann sie innerhalb eines praktisch relevanten Zeitrahmens brechen.

AES-256 ist der Verschlüsselungsstandard, der in der gesamten US-Bundesregierung (einschließlich NSA-klassifizierter Systeme), TLS 1.3, bei der Festplattenverschlüsselung auf allen großen Betriebssystemen und bei Enterprise-Credential-Management-Tools verwendet wird. Wenn ein Anbieter sagt, sein Produkt verwende „Verschlüsselung auf Militärniveau", meint er fast immer AES-256.

Woher der Name stammt

Der AES-Teil bezieht sich auf den Algorithmus selbst — ein Substitutions-Permutations-Netzwerk, das von Joan Daemen und Vincent Rijmen entworfen wurde (ursprünglich Rijndael genannt) und 2001 von NIST nach einem fünfjährigen öffentlichen Wettbewerb ausgewählt wurde. Die „256" bezieht sich auf die Schlüssellänge in Bit. AES gibt es auch in 128-Bit- und 192-Bit-Varianten; die 256-Bit-Version verwendet 14 Transformationsrunden statt 10 (AES-128) oder 12 (AES-192). Mehr Runden bedeuten eine größere Sicherheitsmarge.

Was der 256-Bit-Schlüssel tatsächlich bedeutet

Ein 256-Bit-Schlüssel hat 2²⁵⁶ mögliche Werte — ungefähr 1,16×10⁷⁷. Um das physisch einzuordnen: Wenn jedes Atom im beobachtbaren Universum ein Computer wäre, der eine Milliarde Milliarden Schlüsselversuche pro Sekunde durchführt, würde das Durchprobieren des AES-256-Schlüsselraums immer noch um viele Größenordnungen länger dauern als das Alter des Universums. Deshalb beschreiben Kryptografen AES-256 als praktisch nicht durch Brute-Force angreifbar.

Die Schlüssellänge bestimmt auch die Quantenresistenz. Grovers Algorithmus — der bekannteste Quantenangriff auf symmetrische Chiffren — bietet eine quadratische Beschleunigung, die die Schlüssellänge effektiv halbiert. Gegen AES-256 reduziert diese Reduzierung die effektive Sicherheit auf 128 Bit. AES-128-Sicherheit ist selbst durch keine bekannte oder prognostizierte Hardware zu brechen. Die eigene Post-Quanten-Kryptografie-Dokumentation des NIST bestätigt, dass AES-256 gegen Quanten-Angreifer sicher bleibt.

AES-256 vs. AES-128: Ist der Unterschied bedeutsam?

Für die meisten Enterprise-Anwendungsfälle sind beide rechnerisch unknackbar. Die praktischen Gründe, AES-256 zu bevorzugen, sind:

• Regulatorische Anforderungen. NSAs CNSA 2.0 (2022, aktualisiert 2025) schreibt AES-256 für alle National Security Systems auf allen Klassifizierungsstufen vor. PCI DSS akzeptiert AES-128 als Minimum, aber AES-256 als empfohlenen Standard.
• Quantenmarge. AES-256 behält nach Grover 128-Bit-Sicherheit; AES-128 fällt auf 64 Bit, was sich der Machbarkeit für einen ausreichend fortgeschrittenen Quanten-Angreifer nähert.
• Langlebige Daten. Wenn die Daten, die Sie heute verschlüsseln, 20+ Jahre vertraulich bleiben müssen, ist AES-256 die konservative Wahl.

Der Leistungsunterschied zwischen AES-128 und AES-256 ist auf moderner Hardware mit AES-NI-Beschleunigung vernachlässigbar — typischerweise unter 20 % Durchsatzunterschied. Es gibt keinen praktischen Grund, AES-128 für neue Implementierungen zu wählen.

Wie AES-256 in eine breitere Sicherheitsarchitektur passt

AES-256 ist eine symmetrische Chiffre. Sie verarbeitet Massendatenverschlüsselung effizient, erfordert jedoch, dass beide Parteien denselben geheimen Schlüssel teilen — was ein Schlüsselverteilungsproblem schafft. In der Praxis wird asymmetrische Kryptografie (RSA, ECC oder Post-Quanten-Algorithmen wie ML-KEM aus FIPS 203) verwendet, um den AES-Schlüssel sicher auszutauschen, wonach AES-256 die eigentlichen Daten verarbeitet. Genau so funktioniert TLS 1.3: asymmetrischer Handshake, symmetrische Datenübertragung.

Die Chiffre ist nur so stark wie das System drumherum. AES-256 schützt Daten im Ruhezustand und während der Übertragung. Es schützt nicht gegen einen gestohlenen Schlüssel, einen kompromittierten Endpunkt oder einen autorisierten Benutzer mit böswilliger Absicht. Das ist keine Schwäche des Algorithmus — es ist die Grenze dessen, was jede Chiffre leisten kann.

Wie AES-256 funktioniert: Die Mathematik hinter der Chiffre

Die Chiffre verarbeitet Daten in festen 128-Bit-Blöcken. Jeder Block durchläuft 14 sequenzielle Transformationsrunden — mehr Runden als AES-128 (10) oder AES-192 (12). Jede Runde wendet vier Operationen an: Substitution, Zeilenverschiebung, Spaltenmischung und Schlüsseladdition. Das Kippen eines einzelnen Eingabebits ändert bis zum Ende der ersten Runde etwa die Hälfte der Ausgabebits.

Die 14 Transformationsrunden

AES-256 wendet 14 Runden von vier Operationen auf jeden 128-Bit-Datenblock an. Jede Runde besteht aus:

1. SubBytes — jedes Byte wird über eine feste Substitutionstabelle (S-Box) ersetzt, was Nichtlinearität einführt
2. ShiftRows — Zeilen der 4×4-Zustandsmatrix werden zyklisch verschoben, was Diffusion bewirkt
3. MixColumns — Spalten werden in einem Galois-Feld multipliziert, was die Daten weiter über Bytes hinweg mischt
4. AddRoundKey — der Rundenschlüssel (abgeleitet vom ursprünglichen 256-Bit-Schlüssel über Schlüsselexpansion) wird mit dem Zustand XOR-verknüpft

Die letzte Runde lässt MixColumns aus. Dieses Substitutions-Permutations-Netzwerk (SPN)-Design bedeutet, dass das Kippen eines einzelnen Eingabebits etwa die Hälfte der Ausgabebits ändert — der Lawineneffekt. Nach 14 Runden ist die Beziehung zwischen Klartext und Chiffretext ohne den Schlüssel rechnerisch nicht umkehrbar.

AES-GCM vs. AES-CBC: Warum der Modus genauso wichtig ist wie die Schlüssellänge

Die Chiffre selbst ist nur ein Teil der Geschichte. Wie Sie sie verwenden — der Betriebsmodus — bestimmt, ob Ihre Implementierung tatsächlich sicher ist.

AES-256-GCM ist ein Authenticated Encryption with Associated Data (AEAD)-Modus. Er verschlüsselt gleichzeitig die Daten und erzeugt einen Message Authentication Code (MAC), der sowohl Vertraulichkeit als auch Integrität in einer einzigen Operation garantiert. Wenn ein Angreifer den Chiffretext manipuliert, schlägt die Entschlüsselung fehl — der MAC wird nicht verifiziert.

AES-256-CBC bietet nur Vertraulichkeit. Ohne einen separaten MAC (zum Beispiel über HMAC-SHA256) ist eine CBC-verschlüsselte Nachricht anfällig für Padding-Oracle-Angriffe und Bit-Flipping. CBC erfordert auch sequenzielle Verarbeitung, was die Leistung auf moderner Multi-Core-Hardware einschränkt.

Für neue Implementierungen im Jahr 2026 ist AES-256-GCM die richtige Wahl. TLS 1.3 hat CBC-Cipher-Suites aus genau diesem Grund vollständig entfernt. Der einzige praktische Vorbehalt: GCM ist katastrophal gebrochen, wenn eine Nonce (Initialisierungsvektor) mit demselben Schlüssel wiederverwendet wird. Ihre Implementierung muss Nonce-Eindeutigkeit garantieren — typischerweise über einen kryptografisch sicheren Zufallszahlengenerator oder einen Zähler.

Quantencomputing und AES-256: Risiko von Rauschen trennen

Die Quantencomputer-Bedrohung für Verschlüsselung ist real, aber sie ist nicht einheitlich. Zu verstehen, welche Algorithmen verwundbar sind und in welchem Maße, ist essenziell für fundierte architektonische Entscheidungen heute.

Quantencomputer bedrohen asymmetrische Kryptografie (RSA, ECC, Diffie-Hellman) durch Shors Algorithmus, der große Zahlen faktorisieren und diskrete Logarithmusprobleme in polynomieller Zeit lösen kann. Ein ausreichend leistungsfähiger Quantencomputer, der Shors Algorithmus ausführt, würde RSA-2048 vollständig brechen. Dies ist die echte Krise, die die Post-Quanten-Kryptografie (PQC)-Standardisierungsarbeit des NIST antreibt, die FIPS 203, 204 und 205 im Jahr 2024 finalisiert hat.

Symmetrische Verschlüsselung steht einem anderen Algorithmus und einer anderen Bedrohungsstufe gegenüber.

Was Grovers Algorithmus tatsächlich mit AES-256 macht

Grovers Algorithmus ist die Quantenbedrohung für symmetrische Verschlüsselung. Er bietet eine quadratische Beschleunigung für unstrukturierte Suchprobleme: Wo ein klassischer Computer N Operationen benötigt, um einen Schlüsselraum zu durchsuchen, benötigt ein Quantencomputer mit Grovers Algorithmus ungefähr die Quadratwurzel von N. Auf AES-256 angewendet, halbiert dies effektiv die Schlüssellänge aus Sicherheitsperspektive — ein 256-Bit-Schlüssel bietet gegen einen Quanten-Angreifer etwa 128 Bit Sicherheit.

128-Bit-Sicherheit ist immer noch unknackbar. Konkret ausgedrückt: Ein klassischer Angriff auf AES-128 erfordert etwa 2¹²⁸ Operationen. Selbst wenn Sie eine Milliarde Milliarden (10¹⁸) Operationen pro Sekunde durchführen könnten, würde das Durchprobieren dieses Schlüsselraums länger dauern als das Alter des Universums. Grovers Algorithmus reduziert AES-256 auf dieses Niveau — er bricht es nicht. Die PQC-FAQ des NIST bestätigt ausdrücklich, dass AES mit 128-, 192- oder 256-Bit-Schlüsseln gegen Quantenangriffe sicher ist.

Die CNSA 2.0-Empfehlung der NSA (2022, aktualisiert 2025) schreibt AES-256 für alle National Security Systems auf allen Klassifizierungsstufen, einschließlich Top Secret, mit einer Übergangsfrist bis 2035 vor. Die Tatsache, dass die NSA AES-256 nicht ersetzt (nur die asymmetrischen Algorithmen), ist das klarste mögliche Signal über seine Quantenresistenz.

Harvest Now, Decrypt Later (HNDL): Die Bedrohung, die heute existiert

Der Q-Day (der Zeitpunkt, an dem ein kryptoanalytisch relevanter Quantencomputer existiert) wird von den meisten Forschern auf 10–20 Jahre geschätzt, obwohl die Zeitpläne wirklich unsicher sind. Die unmittelbarere Bedrohung ist HNDL: Nationalstaatliche Akteure und ausgeklügelte kriminelle Gruppen fangen heute verschlüsselten Datenverkehr ab und archivieren ihn, mit der Absicht, ihn zu entschlüsseln, sobald Quantenhardware ausgereift ist.

Für Daten mit einem langen Sensibilitätshorizont — klassifizierte Regierungskommunikation, geistiges Eigentum, Krankenakten, langfristige Finanzdaten — ist HNDL ein gegenwärtiges operatives Risiko, kein zukünftiges Hypothetisches. Die Reaktion besteht darin, asymmetrische Schlüsselaustauschprotokolle jetzt auf Post-Quanten-Algorithmen zu migrieren, während AES-256 weiterhin für symmetrische Verschlüsselung verwendet wird.

Wenn AES-256 unknackbar ist, warum passieren dann immer noch Datenschutzverletzungen?

AES-256-Verschlüsselung ist mathematisch solide. Die Verletzungen passieren überall sonst. Der 2026 Data Breach Investigations Report von Verizon stellte fest, dass der menschliche Faktor bei 62 % der Verletzungen präsent war — gestohlene Anmeldedaten, Privilegienmissbrauch, Social Engineering. Angreifer brechen nicht die Chiffre. Sie stehlen den Schlüssel, kompromittieren den Endpunkt oder nutzen die Person aus, die das Passwort hält.

Der 2026 DBIR markiert auch einen strukturellen Wandel: Zum ersten Mal in den 19 Jahren der Berichtsveröffentlichung hat die Ausnutzung von Schwachstellen gestohlene Anmeldedaten als Top-Erstzugriffsvektor überholt und macht 31 % aller Verletzungen aus, gegenüber 20 % im Vorjahr. KI beschleunigt dies — Bedrohungsakteure nutzen sie jetzt, um das Fenster zwischen Schwachstellenoffenlegung und aktiver Ausnutzung von Monaten auf Stunden zu verkürzen.

Der 2025 Cost of a Data Breach Report von IBM beziffert die finanziellen Auswirkungen dieser Versäumnisse auf durchschnittlich 4,44 Millionen Dollar pro Vorfall. Organisationen mit hohem Niveau an Shadow AI (Mitarbeiter, die nicht genehmigte KI-Tools auf Firmengeräten nutzen) zahlten zusätzliche 670.000 Dollar pro Verletzung. Der 2026 DBIR fügt Kontext hinzu: Shadow AI ist jetzt die dritthäufigste nicht-böswillige Insider-Datenleckage-Aktivität, wobei die regelmäßige KI-Tool-Nutzung unter Mitarbeitern innerhalb eines Jahres von 15 % auf 45 % gestiegen ist.

Diese Zahlen rahmen das eigentliche Problem: Verschlüsselung schützt Daten im Ruhezustand und während der Übertragung, aber sie kann nicht gegen einen autorisierten Benutzer schützen, der etwas Unautorisiertes tut, eine Schwachstelle, die acht Monate lang ungepatcht bleibt, oder einen Endpunkt, der bereits kompromittiert ist.

Die sechs Lücken, die Verschlüsselung umgehen

Hier ist ein strukturierter Ansatz, um zu verstehen, wo AES-256 in der Praxis versagt — nicht weil der Algorithmus schwach ist, sondern weil die umgebende Architektur es ist.

Das „Verschlüsselung ist nicht genug"-Lückenmodell:

1. Schlüsselmanagement-Versäumnisse. Hardcodierte Verschlüsselungsschlüssel im Quellcode, Schlüssel, die neben den zu schützenden Daten gespeichert werden, Schlüssel, die nie rotiert werden. Wenn der Schlüssel kompromittiert ist, ist die Verschlüsselung wertlos. Hardware Security Modules (HSMs) und Schlüsselableitungsfunktionen wie PBKDF2 existieren genau, um dies zu adressieren. Passwork beispielsweise leitet seinen Masterschlüssel vom Masterpasswort des Benutzers über PBKDF2 mit 300.000 Iterationen und SHA-256 ab — was Brute-Force des Masterpassworts selbst bei extrahierter verschlüsselter Datenbank rechenintensiv macht.
2. Kompromittierte Endpunkte. Malware, die auf einem Endpunkt läuft, liest Daten nach der Entschlüsselung, im RAM. Die Daten waren im Ruhezustand verschlüsselt, wurden zur Nutzung entschlüsselt, die Malware erfasste sie im Klartext. AES-256 bietet hier null Schutz. Deshalb sind Endpoint Detection and Response (EDR) und Privileged Access Workstations (PAWs) keine optionalen Schichten.
3. Insider-Bedrohungen. Autorisierte Benutzer mit legitimem Entschlüsselungszugang können Daten exfiltrieren. Verschlüsselung unterscheidet nicht zwischen einem legitimen Administrator und einem böswilligen. Rollenbasierte Zugriffskontrolle (RBAC), Least-Privilege-Prinzipien und Audit-Protokollierung sind die Kontrollen, die diese Lücke adressieren.
4. Schlechte Zugriffskontrolle. Geteilte Anmeldedaten, zu breite Berechtigungen und veraltete Konten, die nach dem Ausscheiden von Mitarbeitern aktiv bleiben, schaffen Exposition, die Verschlüsselung nicht mindern kann.
5. Metadaten-Exposition. Selbst wenn Inhalte verschlüsselt sind, können Metadaten (wer mit wem kommuniziert hat, wann, wie oft, Dateigrößen, Zugriffsmuster) sensible Informationen offenbaren. Verschlüsselung schützt die Nutzlast, nicht den Umschlag.
6. Kontrollverlust nach dem Teilen. Sobald eine verschlüsselte Datei geteilt und vom Empfänger entschlüsselt wurde, haben Sie keine Kontrolle mehr darüber, was als nächstes passiert. Digital Rights Management (DRM) und Zero-Trust-Dateifreigabe-Architekturen adressieren dies teilweise, aber keine Lösung ist vollständig.

Bekannte kryptoanalytische Angriffe auf AES-256 — und warum sie in der Praxis keine Rolle spielen

Der Vollständigkeit halber: Die bekanntesten Angriffe gegen vollständiges AES-256 sind der Biclique-Angriff (Rechenkomplexität von etwa 2²⁵⁴⋅⁴, knapp unter der Brute-Force-Grenze von 2²⁵⁶) und Related-Key-Angriffe (Komplexität um 2⁹⁹⋅⁵ unter hochspezifischen Bedingungen).

Keiner ist praktisch relevant. Der Biclique-Angriff erfordert mehr Rechenleistung als physisch machbar ist. Related-Key-Angriffe erfordern, dass der Angreifer die Beziehung zwischen mehreren Schlüsseln kontrolliert — eine Bedingung, die in keinem richtig konzipierten System existiert. Seitenkanalangriffe (Leistungsanalyse, Timing-Angriffe, Cache-Timing) sind ein echtes Problem, aber sie zielen auf die Implementierung, nicht auf den Algorithmus. Constant-Time-Implementierungen und Hardware-AES-Beschleunigung (AES-NI) mindern die meisten davon.

Enterprise-Best-Practices für AES-256 im Jahr 2026

AES-256 im Jahr 2026 korrekt einzusetzen bedeutet, in drei Ebenen zu denken: Daten im Ruhezustand, Daten während der Übertragung und Daten in Nutzung. Die meisten Organisationen haben die ersten beiden teilweise abgedeckt. Die dritte ist der Bereich, in dem die nächste Generation von Verletzungen auftreten wird.

Daten im Ruhezustand

Verwenden Sie AES-256-GCM für neue Implementierungen. Stellen Sie sicher, dass Schlüssel getrennt von den zu schützenden Daten verwaltet werden — idealerweise in einem HSM oder einem dedizierten Key-Management-Service. Rotieren Sie Schlüssel nach einem definierten Zeitplan und sofort bei Verdacht auf Kompromittierung. Verwenden Sie PBKDF2, bcrypt oder Argon2, um Verschlüsselungsschlüssel aus Passwörtern abzuleiten. Verwenden Sie niemals das Passwort direkt als Schlüssel.

Festplattenverschlüsselung (BitLocker unter Windows, FileVault unter macOS) bietet eine Baseline für Endpunktschutz, schützt aber nur gegen physischen Diebstahl eines ausgeschalteten Geräts. Sie schützt nicht gegen einen angemeldeten Benutzer oder einen laufenden Malware-Prozess.

Daten während der Übertragung

TLS 1.3 ist der aktuelle Standard. Es schreibt AEAD-Cipher-Suites vor (AES-256-GCM oder ChaCha20-Poly1305), entfernt schwache Cipher-Suites aus TLS 1.2 und bietet standardmäßig Forward Secrecy. Wenn Ihre Infrastruktur noch TLS 1.2 mit CBC-Cipher-Suites unterstützt, ist das eine Konfigurationsschuld, die es jetzt zu beheben gilt.

Daten in Nutzung — das ungelöste Problem

Daten in Nutzung sind Klartext im Speicher während der Verarbeitung. Confidential-Computing-Frameworks — Intel SGX (Software Guard Extensions) und AMD SEV (Secure Encrypted Virtualization) — schaffen hardware-isolierte Ausführungsumgebungen (Trusted Execution Environments oder TEEs), in denen selbst der Hypervisor oder das Betriebssystem die verarbeiteten Daten nicht lesen können. Dies ist die Frontier der Verschlüsselungsarchitektur und wird zunehmend relevant für Cloud-Workloads, die sensible Daten verarbeiten.

Zero-Knowledge-Architektur

Eine Zero-Knowledge-Architektur bedeutet, dass der Dienstanbieter (oder Server) niemals Zugriff auf Klartextdaten oder die Schlüssel zu deren Entschlüsselung hat. Client-seitige Verschlüsselung ist der Mechanismus: Daten werden auf dem Client vor der Übertragung verschlüsselt, und der Server speichert nur Chiffretext. Der Client-seitige Verschlüsselungsmodus von Passwork implementiert dies — der Masterschlüssel wird vom Masterpasswort des Benutzers abgeleitet und nie an den Server übertragen, was bedeutet, dass selbst eine vollständige Serverkompromittierung nur verschlüsselte Daten liefert.

Compliance-Anforderungen

AES-256 ist nicht nur eine technische Best Practice — es ist eine Compliance-Anforderung in mehreren Frameworks:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) bezeichnet AES-256 als gültige Verschlüsselungsmethode für geschützte Gesundheitsinformationen (PHI), wodurch verletzte Daten als „nicht nutzbar, unlesbar oder unentschlüsselbar" gelten.
• DSGVO Artikel 32 verlangt „geeignete technische Maßnahmen" einschließlich Verschlüsselung zum Schutz personenbezogener Daten. AES-256 ist der De-facto-Standard zur Erfüllung dieser Anforderung.
• PCI DSS Anforderung 3 schreibt starke Kryptografie für gespeicherte Karteninhaberdaten vor. AES-256 erfüllt diese Anforderung; AES-128 ist das Minimum.
• NSA CNSA 2.0 schreibt AES-256 (nicht AES-128) für alle National Security Systems auf allen Klassifizierungsstufen vor.

Fazit

AES-256 bleibt 2026 das richtige Fundament für Datenverschlüsselung. Der Algorithmus hat keine praktische Schwachstelle (klassisch oder quantenbasiert) und diese Position wird sich innerhalb jedes für Ihre Organisation heute relevanten Planungshorizonts wahrscheinlich nicht ändern.

Die härtere Wahrheit ist, dass der Algorithmus nie das Problem war. Der 2026 DBIR fand den menschlichen Faktor bei 62 % der Verletzungen. Das ist kein Kryptografie-Versagen. Es ist ein Versagen beim Schlüsselmanagement, der Zugriffskontrolle, der Endpunkthygiene und der operativen Disziplin.

Drei Dinge sind es wert, jetzt priorisiert zu werden:

1. Prüfen Sie, wo Ihre Verschlüsselungsschlüssel liegen. Wenn welche hardcodiert sind oder neben den zu schützenden Daten gespeichert werden, ist das die dringendste Korrektur auf dieser Liste.
2. Migrieren Sie den asymmetrischen Schlüsselaustausch zu Post-Quanten-Algorithmen. HNDL ist ein gegenwärtiges Risiko für alle Daten mit mehrjährigem Sensibilitätshorizont.
3. Verlagern Sie das Credential-Management in einen strukturierten Tresor. Wenn Ihr Team sich immer noch auf Tabellenkalkulationen oder geteilte Dokumente verlässt, ist das Zugriffskontrollproblem dringender als jede kryptografische Frage.

AES-256 erfüllt seinen Zweck. Die Frage ist, ob alles drumherum das auch tut.

Häufig gestellte Fragen zur AES-256-Verschlüsselung

Ist AES-256-Verschlüsselung wirklich unknackbar?

AES-256 hat keinen bekannten praktischen Angriff, der es innerhalb eines machbaren Zeitrahmens bricht. Der beste klassische Angriff (Biclique) erreicht eine Komplexität von etwa 2²⁵⁴⋅⁴ Operationen — geringfügig unter Brute-Force, aber rechnerisch unmöglich auszuführen. Kein heute gebauter oder für das nächste Jahrzehnt prognostizierter klassischer oder Quantencomputer kann AES-256 durch direkten Angriff auf den Algorithmus brechen.

Können Quantencomputer AES-256 brechen?

Nein. Grovers Algorithmus — die relevante Quantenbedrohung für symmetrische Verschlüsselung — reduziert die effektive Sicherheit von AES-256 von 256 Bit auf etwa 128 Bit. 128-Bit-Sicherheit bleibt durch jede bekannte oder prognostizierte Quantenhardware unknackbar. NIST bestätigt ausdrücklich, dass AES mit 128-, 192- oder 256-Bit-Schlüsseln gegen Quantenangriffe sicher ist. Asymmetrische Algorithmen wie RSA sind diejenigen, die einem echten Quantenrisiko ausgesetzt sind.

Was ist der Unterschied zwischen AES-256-GCM und AES-256-CBC?

AES-256-GCM bietet authentifizierte Verschlüsselung (AEAD): Es verschlüsselt Daten und erzeugt einen Message Authentication Code in einem Durchgang, der sowohl Vertraulichkeit als auch Integrität garantiert. AES-256-CBC verschlüsselt nur — ohne separaten MAC ist es anfällig für Padding-Oracle- und Bit-Flipping-Angriffe. TLS 1.3 hat die CBC-Unterstützung vollständig entfernt. Für neue Deployments ist GCM die richtige Wahl.

Was ist „Harvest Now, Decrypt Later" und sollte ich mir Sorgen machen?

HNDL ist eine Strategie, bei der Gegner heute verschlüsselte Daten abfangen und speichern, mit der Absicht, sie zu entschlüsseln, sobald Quantencomputer dazu fähig werden. Für Daten mit einem langen Sensibilitätshorizont — klassifizierte Informationen, Krankenakten, langfristige Finanzdaten — ist dies ein gegenwärtiges Risiko. Die Mitigation besteht darin, asymmetrische Schlüsselaustauschprotokolle jetzt auf Post-Quanten-Algorithmen (FIPS 203/204/205) zu migrieren, während AES-256 weiterhin für symmetrische Verschlüsselung verwendet wird.

Warum werden Organisationen, die AES-256 verwenden, immer noch gehackt?

Weil Angreifer die Verschlüsselung umgehen, anstatt sie zu brechen. Gestohlene Anmeldedaten, kompromittierte Endpunkte, schlechtes Schlüsselmanagement, Insider-Bedrohungen und zu breite Zugriffsberechtigungen exponieren alle Klartextdaten, ohne jemals die Chiffre zu berühren.

Was ist eine Zero-Knowledge-Architektur in einem Passwort-Manager?

Eine Zero-Knowledge-Architektur bedeutet, dass der Server niemals Klartext-Anmeldedaten oder die Schlüssel zu deren Entschlüsselung empfängt oder speichert. Die Verschlüsselung erfolgt auf dem Client (im Browser oder der Anwendung), bevor die Daten übertragen werden. Selbst wenn der Server vollständig kompromittiert wird, erhält der Angreifer nur Chiffretext. Dies ist die Architektur, die für jedes Credential-Management-Tool erforderlich ist, das sensible Unternehmensgeheimnisse verarbeitet.

Erfüllt AES-256 die Anforderungen von HIPAA, DSGVO und PCI DSS?

Ja, für alle drei. HIPAAs Safe-Harbor-Bestimmung (45 CFR §164.312) bezeichnet AES-256 als gültigen Verschlüsselungsstandard für PHI. DSGVO Artikel 32 verlangt geeignete technische Maßnahmen einschließlich Verschlüsselung — AES-256 erfüllt dies. PCI DSS Anforderung 3 schreibt starke Kryptografie für gespeicherte Karteninhaberdaten vor, wobei AES-256 der akzeptierte Standard ist. Compliance erfordert eine korrekte Implementierung, nicht nur das Vorhandensein von Verschlüsselung.

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht keinen Zugriff. API-Schlüssel, KI-Agenten-Anmeldedaten und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko tatsächlich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Secrets-Rotations-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von der Erstellung und Eigentümerschaft bis zur sicheren Rotation, Notfall-Widerruf und Audit-Nachweis.

Passwork BlogAlex Muntyan

El cifrado AES-256 es un cifrado de bloques simétrico que utiliza una clave de 256 bits para cifrar datos en 14 rondas de transformación. Ningún ordenador clásico o cuántico puede descifrarlo por fuerza bruta en un plazo de tiempo práctico. Sin embargo, las organizaciones que utilizan AES-256 siguen sufriendo filtraciones de datos catastróficas — porque los atacantes rara vez intentan romper el cifrado. Atacan los sistemas que lo rodean.

Esa distinción importa más en 2026 que nunca. Los ataques impulsados por IA están acelerando el robo de credenciales y el compromiso de endpoints. La estrategia «Harvest Now, Decrypt Later» (recopilar ahora, descifrar después) significa que los adversarios están almacenando datos cifrados hoy, apostando por futuras capacidades de descifrado. Y NIST ha finalizado sus primeros estándares de criptografía post-cuántica, lo que genera preguntas legítimas sobre si AES-256 todavía tiene lugar en su arquitectura de seguridad.

La respuesta corta: sí. La respuesta más larga requiere entender exactamente contra qué protege AES-256, contra qué no protege, y cómo implementarlo para que la fortaleza teórica del algoritmo se traduzca en seguridad real.

Puntos clave

• AES-256 no tiene debilidad práctica. Ningún ordenador clásico o cuántico puede descifrar por fuerza bruta una clave de 256 bits en un plazo de tiempo viable. El algoritmo en sí no es el riesgo.
• El algoritmo de Grover reduce a la mitad la seguridad de AES-256, no la elimina. Un adversario cuántico reduce la seguridad efectiva a 128 bits — todavía inquebrantable por cualquier hardware conocido o proyectado.
• La amenaza real es Harvest Now, Decrypt Later (HNDL), no el día Q. Los adversarios están archivando datos cifrados hoy. Migrar el intercambio de claves asimétricas a algoritmos post-cuánticos es una prioridad presente, no futura.
• AES-256-GCM es el modo correcto para nuevas implementaciones. CBC proporciona solo confidencialidad. GCM añade autenticación integrada y es obligatorio en TLS 1.3.
• El 62% de las filtraciones involucran el elemento humano. Los atacantes evitan el cifrado a través de credenciales robadas, endpoints comprometidos y mala gestión de claves — no rompiendo el cifrado.
• La gestión de claves es el eslabón más débil. Las claves codificadas de forma fija, las claves almacenadas junto a los datos que protegen y las claves que nunca se rotan son más peligrosas que cualquier ataque criptoanalítico conocido.
• La arquitectura de conocimiento cero elimina el riesgo del lado del servidor. Si el servidor nunca tiene acceso al texto plano ni a las claves de descifrado, un compromiso total del servidor solo produce texto cifrado inútil.
• AES-256 cumple con HIPAA, GDPR y PCI DSS. El cumplimiento requiere una implementación correcta — cifrado en reposo, en tránsito y gestión de claves documentada — no solo la presencia del algoritmo.

¿Qué es AES-256?

AES-256 (Advanced Encryption Standard con una clave de 256 bits) es un cifrado de bloques simétrico estandarizado en NIST FIPS 197. Cifra datos en bloques de 128 bits utilizando una clave de 256 bits a lo largo de 14 rondas de transformación. La misma clave cifra y descifra los datos. Ningún ataque clásico o cuántico conocido puede romperlo en un plazo de tiempo práctico.

AES-256 es el estándar de cifrado utilizado en todo el gobierno federal de EE. UU. (incluidos los sistemas clasificados de la NSA), TLS 1.3, el cifrado de disco completo en todos los sistemas operativos principales y las herramientas empresariales de gestión de credenciales. Cuando un proveedor dice que su producto utiliza «cifrado de grado militar», casi siempre se refiere a AES-256.

De dónde viene el nombre

La parte AES se refiere al algoritmo en sí — una red de sustitución-permutación diseñada por Joan Daemen y Vincent Rijmen (originalmente llamada Rijndael), seleccionada por NIST en 2001 después de una competición pública de cinco años. El «256» se refiere a la longitud de la clave en bits. AES también viene en variantes de 128 bits y 192 bits; la versión de 256 bits utiliza 14 rondas de transformación en lugar de 10 (AES-128) o 12 (AES-192). Más rondas significan un mayor margen de seguridad.

Qué significa realmente la clave de 256 bits

Una clave de 256 bits tiene 2²⁵⁶ valores posibles — aproximadamente 1,16×10⁷⁷. Para ponerlo en términos físicos: si cada átomo del universo observable fuera un ordenador realizando mil millones de miles de millones (10¹⁸) de intentos de clave por segundo, agotar el espacio de claves de AES-256 todavía llevaría más tiempo que la edad del universo por muchos órdenes de magnitud. Por eso los criptógrafos describen AES-256 como sin vulnerabilidad práctica de fuerza bruta.

La longitud de la clave también determina la resiliencia cuántica. El algoritmo de Grover — el mejor ataque cuántico conocido contra cifrados simétricos — proporciona una aceleración cuadrática, reduciendo efectivamente la longitud de la clave a la mitad. Contra AES-256, esa reducción lleva la seguridad efectiva a 128 bits. La seguridad de AES-128 en sí misma es inquebrantable por cualquier hardware conocido o proyectado. La documentación de criptografía post-cuántica del propio NIST confirma que AES-256 sigue siendo seguro contra adversarios cuánticos.

AES-256 vs. AES-128: ¿Es significativa la diferencia?

Para la mayoría de los casos de uso empresarial, ambos son computacionalmente inquebrantables. Las razones prácticas para preferir AES-256 son:

• Requisitos regulatorios. CNSA 2.0 de la NSA (2022, actualizado en 2025) exige AES-256 para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación. PCI DSS acepta AES-128 como mínimo pero AES-256 como el estándar recomendado.
• Margen cuántico. AES-256 retiene 128 bits de seguridad post-Grover; AES-128 cae a 64 bits, lo que se acerca a la viabilidad para un adversario cuántico suficientemente avanzado.
• Datos de larga duración. Si los datos que cifra hoy necesitan permanecer confidenciales durante más de 20 años, AES-256 es la opción conservadora.

La diferencia de rendimiento entre AES-128 y AES-256 es insignificante en hardware moderno con aceleración AES-NI — típicamente menos del 20% de diferencia en rendimiento. No hay razón práctica para elegir AES-128 en nuevas implementaciones.

Cómo encaja AES-256 en una arquitectura de seguridad más amplia

AES-256 es un cifrado simétrico. Maneja el cifrado masivo de datos de manera eficiente, pero requiere que ambas partes compartan la misma clave secreta — lo que crea un problema de distribución de claves. En la práctica, la criptografía asimétrica (RSA, ECC o algoritmos post-cuánticos como ML-KEM de FIPS 203) se utiliza para intercambiar de forma segura la clave AES, después de lo cual AES-256 maneja los datos reales. Así es exactamente como funciona TLS 1.3: handshake asimétrico, transferencia de datos simétrica.

El cifrado es tan fuerte como el sistema que lo rodea. AES-256 protege los datos en reposo y en tránsito. No protege contra una clave robada, un endpoint comprometido o un usuario autorizado con intenciones maliciosas. Eso no es una debilidad del algoritmo — es el límite de lo que cualquier cifrado puede hacer.

Cómo funciona AES-256: Las matemáticas detrás del cifrado

El cifrado procesa datos en bloques fijos de 128 bits. Cada bloque pasa por 14 rondas secuenciales de transformación — más rondas que AES-128 (10) o AES-192 (12). Cada ronda aplica cuatro operaciones: sustitución, desplazamiento de filas, mezcla de columnas y adición de clave. Cambiar un solo bit de entrada cambia aproximadamente la mitad de los bits de salida al final de la primera ronda.

Las 14 rondas de transformación

AES-256 aplica 14 rondas de cuatro operaciones a cada bloque de datos de 128 bits. Cada ronda consiste en:

1. SubBytes — cada byte se reemplaza mediante una tabla de sustitución fija (S-box), introduciendo no linealidad
2. ShiftRows — las filas de la matriz de estado 4×4 se desplazan cíclicamente, proporcionando difusión
3. MixColumns — las columnas se multiplican en un Campo de Galois, mezclando aún más los datos entre bytes
4. AddRoundKey — la clave de ronda (derivada de la clave original de 256 bits mediante expansión de clave) se combina mediante XOR con el estado

La ronda final omite MixColumns. Este diseño de red de sustitución-permutación (SPN) significa que cambiar un solo bit de entrada cambia aproximadamente la mitad de los bits de salida — el efecto avalancha. Después de 14 rondas, la relación entre el texto plano y el texto cifrado es computacionalmente intratable de revertir sin la clave.

AES-GCM vs. AES-CBC: Por qué el modo importa tanto como la longitud de la clave

El cifrado en sí es solo parte de la historia. Cómo se utiliza — el modo de operación — determina si su implementación es realmente segura.

AES-256-GCM es un modo de Cifrado Autenticado con Datos Asociados (AEAD). Cifra simultáneamente los datos y produce un código de autenticación de mensaje (MAC), garantizando tanto confidencialidad como integridad en una sola operación. Si un atacante manipula el texto cifrado, el descifrado falla — el MAC no se verificará.

AES-256-CBC proporciona solo confidencialidad. Sin un MAC separado (mediante HMAC-SHA256, por ejemplo), un mensaje cifrado con CBC es vulnerable a ataques de oráculo de relleno y manipulación de bits. CBC también requiere procesamiento secuencial, lo que limita el rendimiento en hardware moderno multinúcleo.

Para nuevas implementaciones en 2026, AES-256-GCM es la opción correcta. TLS 1.3 eliminó los conjuntos de cifrado CBC por completo por esta razón. La única advertencia práctica: GCM se rompe catastróficamente si un nonce (vector de inicialización) se reutiliza con la misma clave. Su implementación debe garantizar la unicidad del nonce — típicamente mediante un generador de números aleatorios criptográficamente seguro o un contador.

Computación cuántica y AES-256: Separando el riesgo del ruido

La amenaza de la computación cuántica al cifrado es real, pero no es uniforme. Entender qué algoritmos son vulnerables, y en qué medida, es esencial para tomar decisiones arquitectónicas sólidas hoy.

Los ordenadores cuánticos amenazan la criptografía asimétrica (RSA, ECC, Diffie-Hellman) a través del algoritmo de Shor, que puede factorizar grandes enteros y resolver problemas de logaritmo discreto en tiempo polinómico. Un ordenador cuántico suficientemente potente ejecutando el algoritmo de Shor rompería RSA-2048 por completo. Esta es la crisis genuina que impulsa el esfuerzo de estandarización de criptografía post-cuántica (PQC) de NIST, que finalizó FIPS 203, 204 y 205 en 2024.

El cifrado simétrico enfrenta un algoritmo diferente y un nivel de amenaza diferente.

Qué hace realmente el algoritmo de Grover a AES-256

El algoritmo de Grover es la amenaza cuántica al cifrado simétrico. Proporciona una aceleración cuadrática para problemas de búsqueda no estructurada: donde un ordenador clásico necesita N operaciones para buscar en un espacio de claves, un ordenador cuántico ejecutando Grover necesita aproximadamente la raíz cuadrada de N. Aplicado a AES-256, esto reduce efectivamente la longitud de la clave a la mitad desde una perspectiva de seguridad — una clave de 256 bits proporciona aproximadamente 128 bits de seguridad contra un adversario cuántico.

128 bits de seguridad siguen siendo inquebrantables. Para ser concretos: un ataque clásico a AES-128 requiere aproximadamente 2¹²⁸ operaciones. Incluso si pudiera realizar mil millones de miles de millones (10¹⁸) de operaciones por segundo, agotar ese espacio de claves llevaría más tiempo que la edad del universo. El algoritmo de Grover reduce AES-256 a ese nivel — no lo rompe. Las preguntas frecuentes de PQC del propio NIST afirman explícitamente que AES con claves de 128, 192 o 256 bits permanece seguro contra ataques cuánticos.

El aviso CNSA 2.0 de la NSA (2022, actualizado en 2025) exige AES-256 para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación, incluido Alto Secreto, con una fecha límite de transición de 2035. El hecho de que la NSA no esté reemplazando AES-256 (solo los algoritmos asimétricos) es la señal más clara posible sobre su resiliencia cuántica.

Harvest Now, Decrypt Later (HNDL): La amenaza que existe hoy

El día Q (el punto en el que existe un ordenador cuántico criptoanalíticamente relevante) se estima por la mayoría de los investigadores que está a 10-20 años de distancia, aunque los plazos son genuinamente inciertos. La amenaza más inmediata es HNDL: actores estatales y grupos criminales sofisticados están interceptando y archivando tráfico cifrado hoy, con la intención de descifrarlo una vez que el hardware cuántico madure.

Para datos con un horizonte de sensibilidad largo — comunicaciones gubernamentales clasificadas, propiedad intelectual, registros médicos, datos financieros a largo plazo — HNDL es un riesgo operativo presente, no un hipotético futuro. La respuesta es migrar los protocolos de intercambio de claves asimétricas a algoritmos post-cuánticos ahora, mientras se continúa utilizando AES-256 para el cifrado simétrico.

Si AES-256 es inquebrantable, ¿por qué siguen ocurriendo filtraciones de datos?

El cifrado AES-256 es matemáticamente sólido. Las filtraciones ocurren en todas partes menos ahí. El Informe de Investigaciones de Filtraciones de Datos 2026 de Verizon encontró que el elemento humano estuvo presente en el 62% de las filtraciones — credenciales robadas, mal uso de privilegios, ingeniería social. Los atacantes no rompen el cifrado. Roban la clave, comprometen el endpoint o explotan a la persona que tiene la contraseña.

El DBIR 2026 también marca un cambio estructural: por primera vez en 19 años de publicación del informe, la explotación de vulnerabilidades ha superado a las credenciales robadas como el principal vector de acceso inicial, representando el 31% de todas las filtraciones, frente al 20% del año anterior. La IA está acelerando esto — los actores de amenazas ahora la usan para reducir la ventana entre la divulgación de vulnerabilidades y la explotación activa de meses a horas.

El Informe de Costo de una Filtración de Datos 2025 de IBM cuantifica el peso financiero de estos fallos en 4,44 millones de dólares por incidente en promedio. Las organizaciones con altos niveles de shadow AI (empleados usando herramientas de IA no aprobadas en dispositivos corporativos) pagaron 670.000 dólares adicionales por filtración. El DBIR 2026 añade contexto: el shadow AI es ahora la tercera actividad de fuga de datos internos no maliciosa más común, con el uso regular de herramientas de IA entre empleados saltando del 15% al 45% en un solo año.

Estas cifras enmarcan el problema real: el cifrado protege los datos en reposo y en tránsito, pero no puede proteger contra un usuario autorizado haciendo algo no autorizado, una vulnerabilidad sin parchear durante ocho meses, o un endpoint que ya está comprometido.

Las seis brechas que evitan el cifrado

Aquí hay una forma estructurada de pensar sobre dónde falla AES-256 en la práctica — no porque el algoritmo sea débil, sino porque la arquitectura circundante lo es.

El modelo de brechas «El cifrado no es suficiente»:

1. Fallos en la gestión de claves. Claves de cifrado codificadas de forma fija en el código fuente, claves almacenadas junto a los datos que protegen, claves que nunca se rotan. Si la clave está comprometida, el cifrado no vale nada. Los Módulos de Seguridad Hardware (HSM) y las funciones de derivación de claves como PBKDF2 existen precisamente para abordar esto. Passwork, por ejemplo, deriva su clave maestra de la contraseña maestra del usuario mediante PBKDF2 con 300.000 iteraciones y SHA-256 — haciendo que la fuerza bruta de la contraseña maestra sea computacionalmente costosa incluso si la base de datos cifrada es exfiltrada.
2. Endpoints comprometidos. El malware que opera en un endpoint lee los datos después del descifrado, en RAM. Los datos estaban cifrados en reposo, se descifraron para ser utilizados, el malware los capturó en texto plano. AES-256 proporciona cero protección aquí. Por eso la detección y respuesta de endpoints (EDR) y las estaciones de trabajo de acceso privilegiado (PAWs) no son capas opcionales.
3. Amenazas internas. Los usuarios autorizados con acceso legítimo de descifrado pueden exfiltrar datos. El cifrado no distingue entre un administrador legítimo y uno malicioso. El control de acceso basado en roles (RBAC), los principios de mínimo privilegio y el registro de auditoría son los controles que abordan esta brecha.
4. Control de acceso deficiente. Credenciales compartidas, permisos demasiado amplios y cuentas obsoletas que permanecen activas después de la salida de empleados crean exposición que el cifrado no puede mitigar.
5. Exposición de metadatos. Incluso cuando el contenido está cifrado, los metadatos (quién se comunicó con quién, cuándo, con qué frecuencia, tamaños de archivo, patrones de acceso) pueden revelar información sensible. El cifrado protege la carga útil, no el sobre.
6. Pérdida de control post-compartición. Una vez que un archivo cifrado se comparte y el destinatario lo descifra, no tiene control sobre lo que sucede después. La gestión de derechos digitales (DRM) y las arquitecturas de compartición de archivos de confianza cero abordan parcialmente esto, pero ninguna solución es completa.

Ataques criptoanalíticos conocidos contra AES-256 — y por qué no importan en la práctica

Para ser exhaustivos: los mejores ataques conocidos contra AES-256 completo son el ataque biclique (complejidad computacional de aproximadamente 2²⁵⁴⋅⁴, apenas por debajo del límite de fuerza bruta de 2²⁵⁶) y los ataques de clave relacionada (complejidad de alrededor de 2⁹⁹⋅⁵ bajo condiciones muy específicas).

Ninguno es prácticamente relevante. El ataque biclique requiere más computación de la que es físicamente viable. Los ataques de clave relacionada requieren que el atacante controle la relación entre múltiples claves — una condición que no existe en ningún sistema correctamente diseñado. Los ataques de canal lateral (análisis de potencia, ataques de tiempo, temporización de caché) son una preocupación genuina, pero atacan la implementación, no el algoritmo. Las implementaciones de tiempo constante y la aceleración hardware de AES (AES-NI) mitigan la mayoría de estos.

Mejores prácticas empresariales para AES-256 en 2026

Implementar AES-256 correctamente en 2026 significa pensar en tres planos: datos en reposo, datos en tránsito y datos en uso. La mayoría de las organizaciones tienen los dos primeros parcialmente cubiertos. El tercero es donde ocurrirá la próxima generación de filtraciones.

Datos en reposo

Utilice AES-256-GCM para nuevas implementaciones. Asegúrese de que las claves se gestionen por separado de los datos que protegen — idealmente en un HSM o un servicio de gestión de claves dedicado. Rote las claves según un calendario definido e inmediatamente ante sospecha de compromiso. Utilice PBKDF2, bcrypt o Argon2 para derivar claves de cifrado de contraseñas. Nunca use la contraseña directamente como clave.

El cifrado de disco completo (BitLocker en Windows, FileVault en macOS) proporciona una línea base para la protección de endpoints, pero solo protege contra el robo físico de un dispositivo apagado. No protege contra un usuario conectado o un proceso de malware en ejecución.

Datos en tránsito

TLS 1.3 es el estándar actual. Exige conjuntos de cifrado AEAD (AES-256-GCM o ChaCha20-Poly1305), elimina los conjuntos de cifrado débiles presentes en TLS 1.2 y proporciona secreto perfecto hacia adelante por defecto. Si su infraestructura todavía soporta TLS 1.2 con conjuntos de cifrado CBC, esa es una deuda de configuración que vale la pena abordar ahora.

Datos en uso — el problema sin resolver

Los datos en uso son texto plano en memoria mientras se procesan. Los frameworks de computación confidencial — Intel SGX (Software Guard Extensions) y AMD SEV (Secure Encrypted Virtualization) — crean entornos de ejecución aislados por hardware (entornos de ejecución confiable, o TEEs) donde ni siquiera el hipervisor o el sistema operativo pueden leer los datos que se procesan. Esta es la frontera de la arquitectura de cifrado, y es cada vez más relevante para cargas de trabajo en la nube que manejan datos sensibles.

Arquitectura de conocimiento cero

Una arquitectura de conocimiento cero significa que el proveedor del servicio (o servidor) nunca tiene acceso a los datos en texto plano ni a las claves para descifrarlos. El cifrado del lado del cliente es el mecanismo: los datos se cifran en el cliente antes de la transmisión, y el servidor almacena solo texto cifrado. El modo de cifrado del lado del cliente de Passwork implementa esto — la clave maestra se deriva de la contraseña maestra del usuario y nunca se transmite al servidor, lo que significa que incluso un compromiso total del servidor solo produce datos cifrados.

Anclas de cumplimiento

AES-256 no es solo una mejor práctica técnica — es un requisito de cumplimiento en múltiples marcos:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) designa AES-256 como un método de cifrado válido para información de salud protegida (PHI), haciendo que los datos filtrados sean «no utilizables, ilegibles o indescifrables».
• GDPR Artículo 32 requiere «medidas técnicas apropiadas» incluyendo cifrado para proteger datos personales. AES-256 es el estándar de facto para satisfacer este requisito.
• PCI DSS Requisito 3 exige criptografía fuerte para los datos de titulares de tarjetas almacenados. AES-256 cumple este requisito; AES-128 es el mínimo.
• NSA CNSA 2.0 exige AES-256 (no AES-128) para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación.

Conclusión

AES-256 sigue siendo la base correcta para el cifrado de datos en 2026. El algoritmo no tiene debilidad práctica (clásica o cuántica) y esa posición es poco probable que cambie dentro de cualquier horizonte de planificación que importe a su organización hoy.

La verdad más difícil es que el algoritmo nunca fue el problema. El DBIR 2026 encontró el elemento humano en el 62% de las filtraciones. Eso no es un fallo de criptografía. Es un fallo en la gestión de claves, el control de acceso, la higiene de endpoints y la disciplina operativa.

Tres cosas vale la pena priorizar ahora mismo:

1. Audite dónde residen sus claves de cifrado. Si alguna está codificada de forma fija o almacenada junto a los datos que protege, esa es la corrección más urgente de esta lista.
2. Migre el intercambio de claves asimétricas a algoritmos post-cuánticos. HNDL es un riesgo presente para cualquier dato con un horizonte de sensibilidad de varios años.
3. Traslade la gestión de credenciales a una bóveda estructurada. Si su equipo todavía depende de hojas de cálculo o documentos compartidos, el problema de control de acceso es más inmediato que cualquier cuestión criptográfica.

AES-256 hace su trabajo. La pregunta es si todo lo que lo rodea también lo hace.

Preguntas frecuentes sobre el cifrado AES-256

¿Es el cifrado AES-256 verdaderamente inquebrantable?

AES-256 no tiene ningún ataque práctico conocido que lo rompa en un plazo de tiempo viable. El mejor ataque clásico (biclique) logra una complejidad de aproximadamente 2²⁵⁴⋅⁴ operaciones — marginalmente por debajo de la fuerza bruta pero computacionalmente imposible de ejecutar. Ningún ordenador clásico o cuántico construido hoy, o proyectado para la próxima década, puede romper AES-256 atacando directamente el algoritmo.

¿Pueden los ordenadores cuánticos romper AES-256?

No. El algoritmo de Grover — la amenaza cuántica relevante para el cifrado simétrico — reduce la seguridad efectiva de AES-256 de 256 bits a aproximadamente 128 bits. 128 bits de seguridad siguen siendo inquebrantables por cualquier hardware cuántico conocido o proyectado. NIST confirma explícitamente que AES con claves de 128, 192 o 256 bits es seguro contra ataques cuánticos. Los algoritmos asimétricos como RSA son los que enfrentan un riesgo cuántico genuino.

¿Cuál es la diferencia entre AES-256-GCM y AES-256-CBC?

AES-256-GCM proporciona cifrado autenticado (AEAD): cifra los datos y produce un código de autenticación de mensaje en un solo paso, garantizando tanto confidencialidad como integridad. AES-256-CBC solo cifra — sin un MAC separado, es vulnerable a ataques de oráculo de relleno y manipulación de bits. TLS 1.3 eliminó el soporte de CBC por completo. Para nuevas implementaciones, GCM es la opción correcta.

¿Qué es «Harvest Now, Decrypt Later» y debería preocuparme?

HNDL es una estrategia donde los adversarios interceptan y almacenan datos cifrados hoy, con la intención de descifrarlos una vez que los ordenadores cuánticos sean capaces. Para datos con un horizonte de sensibilidad largo — información clasificada, registros médicos, datos financieros a largo plazo — este es un riesgo presente. La mitigación es migrar los protocolos de intercambio de claves asimétricas a algoritmos post-cuánticos (FIPS 203/204/205) ahora, mientras se continúa utilizando AES-256 para el cifrado simétrico.

¿Por qué las organizaciones que usan AES-256 siguen siendo vulneradas?

Porque los atacantes evitan el cifrado en lugar de romperlo. Las credenciales robadas, los endpoints comprometidos, la mala gestión de claves, las amenazas internas y los permisos excesivamente amplios exponen datos en texto plano sin siquiera tocar el cifrado.

¿Qué es una arquitectura de conocimiento cero en un gestor de contraseñas?

Una arquitectura de conocimiento cero significa que el servidor nunca recibe ni almacena credenciales en texto plano ni las claves para descifrarlas. El cifrado ocurre en el cliente (en el navegador o aplicación) antes de que los datos se transmitan. Incluso si el servidor es completamente comprometido, el atacante obtiene solo texto cifrado. Esta es la arquitectura requerida para cualquier herramienta de gestión de credenciales que maneje secretos corporativos sensibles.

¿Cumple AES-256 con los requisitos de HIPAA, GDPR y PCI DSS?

Sí, para los tres. La disposición Safe Harbor de HIPAA (45 CFR §164.312) designa AES-256 como un estándar de cifrado válido para PHI. El Artículo 32 del GDPR requiere medidas técnicas apropiadas incluyendo cifrado — AES-256 satisface esto. El Requisito 3 de PCI DSS exige criptografía fuerte para los datos de titulares de tarjetas almacenados, siendo AES-256 el estándar aceptado. El cumplimiento requiere una implementación correcta, no solo la presencia del cifrado.

Baja de empleados: Guía de revocación segura de accesos 2026

Desactivar una cuenta SSO no revoca el acceso. Las claves API, las credenciales de agentes de IA y las contraseñas compartidas lo sobreviven. Esta guía cubre el manual completo de baja — desde disparadores de hora cero hasta limpieza de NHI.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Así es como realmente se ve el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Ciclo de vida de rotación de secretos: Desde la creación hasta la revocación

La rotación de secretos falla cuando se trata como una tarea programada en lugar de un ciclo de vida. Esta guía cubre las siete etapas — desde la creación y propiedad hasta la rotación segura, revocación de emergencia y evidencia de auditoría.

Passwork BlogAlex Muntyan

AES-256 encryption is a symmetric block cipher that uses a 256-bit key to encrypt data in 14 transformation rounds. No classical or quantum computer can brute-force it within any practical timeframe. Yet organizations using AES-256 still suffer catastrophic data breaches — because attackers rarely try to break the cipher. They break the systems around it.

That distinction matters more in 2026 than it ever has. AI-driven attacks are accelerating credential theft and endpoint compromise. The "Harvest Now, Decrypt Later" strategy means adversaries are stockpiling encrypted data today, betting on future decryption capabilities. And NIST has finalized its first post-quantum cryptography standards, prompting legitimate questions about whether AES-256 still belongs in your security architecture.

The short answer: yes. The longer answer requires understanding exactly what AES-256 protects against, what it doesn't, and how to deploy it so that the algorithm's theoretical strength translates into actual security.

Key takeaways

• AES-256 has no practical weakness. No classical or quantum computer can brute-force a 256-bit key within any feasible timeframe. The algorithm itself is not the risk.
• Grover's algorithm halves AES-256's security, not eliminates it. A quantum adversary reduces effective security to 128 bits — still unbreakable by any known or projected hardware.
• The real threat is Harvest Now, Decrypt Later (HNDL), not Q-Day. Adversaries are archiving encrypted data today. Migrating asymmetric key exchange to post-quantum algorithms is a present priority, not a future one.
• AES-256-GCM is the correct mode for new implementations. CBC provides confidentiality only. GCM adds built-in authentication and is mandatory in TLS 1.3.
• 62% of breaches involve the human element. Attackers bypass encryption through stolen credentials, compromised endpoints, and poor key management — not by breaking the cipher.
• Key management is the weakest link. Hardcoded keys, keys stored next to the data they protect, and keys that never rotate are more dangerous than any known cryptanalytic attack.
• Zero-knowledge architecture eliminates server-side risk. If the server never holds plaintext or decryption keys, a full server compromise yields only useless ciphertext.
• AES-256 satisfies HIPAA, GDPR, and PCI DSS. Compliance requires correct implementation — encryption at rest, in transit, and documented key management — not just the presence of the algorithm.

What is AES-256?

AES-256 (Advanced Encryption Standard with a 256-bit key) is a symmetric block cipher standardized in NIST FIPS 197. It encrypts data in 128-bit blocks using a 256-bit key across 14 transformation rounds. The same key encrypts and decrypts the data. No known classical or quantum attack can break it within any practical timeframe.

AES-256 is the encryption standard used across the U.S. federal government (including NSA-classified systems), TLS 1.3, full-disk encryption on every major OS, and enterprise credential management tools. When a vendor says their product uses "military-grade encryption," they almost always mean AES-256.

Where the name comes from

The AES part refers to the algorithm itself — a substitution-permutation network designed by Joan Daemen and Vincent Rijmen (originally named Rijndael), selected by NIST in 2001 after a five-year public competition. The "256" refers to the key length in bits. AES also comes in 128-bit and 192-bit variants; the 256-bit version uses 14 rounds of transformation instead of 10 (AES-128) or 12 (AES-192). More rounds mean a larger security margin.

What the 256-bit key actually means

A 256-bit key has 2²⁵⁶ possible values — approximately 1.16×10⁷⁷. To put that in physical terms: if every atom in the observable universe were a computer performing a billion billion key guesses per second, exhausting the AES-256 keyspace would still take longer than the age of the universe by many orders of magnitude. This is why cryptographers describe AES-256 as having no practical brute-force vulnerability.

The key length also determines quantum resilience. Grover's algorithm — the best known quantum attack on symmetric ciphers — provides a quadratic speedup, effectively halving the key length. Against AES-256, that reduction brings effective security to 128 bits. AES-128 security is itself unbreakable by any known or projected hardware. NIST's own post-quantum cryptography documentation confirms AES-256 remains secure against quantum adversaries.

AES-256 vs. AES-128: Is the difference meaningful?

For most enterprise use cases, both are computationally unbreakable. The practical reasons to prefer AES-256 are:

• Regulatory requirements. NSA's CNSA 2.0 (2022, updated 2025) mandates AES-256 for all National Security Systems at all classification levels. PCI DSS accepts AES-128 as a minimum but AES-256 as the recommended standard.
• Quantum margin. AES-256 retains 128-bit security post-Grover; AES-128 drops to 64 bits, which approaches feasibility for a sufficiently advanced quantum adversary.
• Long-lived data. If the data you encrypt today needs to remain confidential for 20+ years, AES-256 is the conservative choice.

The performance difference between AES-128 and AES-256 is negligible on modern hardware with AES-NI acceleration — typically under 20% throughput difference. There is no practical reason to choose AES-128 for new implementations.

How AES-256 fits into a broader security architecture

AES-256 is a symmetric cipher. It handles bulk data encryption efficiently, but it requires both parties to share the same secret key — which creates a key distribution problem. In practice, asymmetric cryptography (RSA, ECC, or post-quantum algorithms like ML-KEM from FIPS 203) is used to securely exchange the AES key, after which AES-256 handles the actual data. This is exactly how TLS 1.3 works: asymmetric handshake, symmetric data transfer.

The cipher is only as strong as the system around it. AES-256 protects data at rest and in transit. It does not protect against a stolen key, a compromised endpoint, or an authorized user with malicious intent. That's not a weakness in the algorithm — it's the boundary of what any cipher can do.

How AES-256 works: The math behind the cipher

The cipher processes data in fixed 128-bit blocks. Each block passes through 14 sequential rounds of transformation — more rounds than AES-128 (10) or AES-192 (12). Each round applies four operations: substitution, row shifting, column mixing, and key addition. Flipping a single input bit changes roughly half the output bits by the end of round one.

The 14 rounds of transformation

AES-256 applies 14 rounds of four operations to each 128-bit data block. Each round consists of:

1. SubBytes — each byte is replaced via a fixed substitution table (S-box), introducing non-linearity
2. ShiftRows — rows of the 4×4 state matrix are cyclically shifted, providing diffusion
3. MixColumns — columns are multiplied in a Galois Field, further mixing data across bytes
4. AddRoundKey — the round key (derived from the original 256-bit key via key expansion) is XORed with the state

The final round omits MixColumns. This substitution-permutation network (SPN) design means that flipping a single input bit changes roughly half the output bits — the avalanche effect. After 14 rounds, the relationship between plaintext and ciphertext is computationally intractable to reverse without the key.

AES-GCM vs. AES-CBC: Why the mode matters as much as the key length

The cipher itself is only part of the story. How you use it — the mode of operation — determines whether your implementation is actually secure.

AES-256-GCM is an Authenticated Encryption with Associated Data (AEAD) mode. It simultaneously encrypts the data and produces a message authentication code (MAC), guaranteeing both confidentiality and integrity in a single operation. If an attacker tampers with the ciphertext, decryption fails — the MAC won't verify.

AES-256-CBC provides confidentiality only. Without a separate MAC (via HMAC-SHA256, for example), a CBC-encrypted message is vulnerable to padding oracle attacks and bit-flipping. CBC also requires sequential processing, which limits performance on modern multi-core hardware.

For new implementations in 2026, AES-256-GCM is the correct choice. TLS 1.3 removed CBC cipher suites entirely for this reason. The one practical caveat: GCM is catastrophically broken if a nonce (initialization vector) is reused with the same key. Your implementation must guarantee nonce uniqueness — typically via a cryptographically secure random number generator or a counter.

Quantum computing and AES-256: Separating risk from noise

The quantum computing threat to encryption is real, but it is not uniform. Understanding which algorithms are vulnerable, and by how much, is essential for making sound architectural decisions today.

Quantum computers threaten asymmetric cryptography (RSA, ECC, Diffie-Hellman) through Shor's algorithm, which can factor large integers and solve discrete logarithm problems in polynomial time. A sufficiently powerful quantum computer running Shor's algorithm would break RSA-2048 entirely. This is the genuine crisis driving NIST's post-quantum cryptography (PQC) standardization effort, which finalized FIPS 203, 204, and 205 in 2024.

Symmetric encryption faces a different algorithm and a different threat level.

What Grover's algorithm actually does to AES-256

Grover's algorithm is the quantum threat to symmetric encryption. It provides a quadratic speedup for unstructured search problems: where a classical computer needs N operations to search a keyspace, a quantum computer running Grover's needs roughly the square root of N. Applied to AES-256, this effectively halves the key length from a security perspective — a 256-bit key provides approximately 128 bits of security against a quantum adversary.

128-bit security is still unbreakable. To put it concretely: a classical attack on AES-128 requires roughly 2¹²⁸ operations. Even if you could perform a billion billion (10¹⁸) operations per second, exhausting that keyspace would take longer than the age of the universe. Grover's algorithm reduces AES-256 to that level — it does not break it. NIST's own PQC FAQ explicitly states that AES with 128, 192, or 256-bit keys remains secure against quantum attacks.

The NSA's CNSA 2.0 advisory (2022, updated 2025) mandates AES-256 for all National Security Systems at all classification levels, including Top Secret, with a transition deadline of 2035. The fact that NSA is not replacing AES-256 (only the asymmetric algorithms) is the clearest possible signal about its quantum resilience.

Harvest Now, Decrypt Later (HNDL): The threat that exists today

Q-Day (the point at which a cryptanalytically relevant quantum computer exists) is estimated by most researchers to be 10–20 years away, though timelines are genuinely uncertain. The more immediate threat is HNDL: nation-state actors and sophisticated criminal groups are intercepting and archiving encrypted traffic today, with the intention of decrypting it once quantum hardware matures.

For data with a long sensitivity horizon — classified government communications, intellectual property, medical records, long-term financial data — HNDL is a present operational risk, not a future hypothetical. The response is to migrate asymmetric key exchange to post-quantum algorithms now, while continuing to use AES-256 for symmetric encryption.

If AES-256 is unbreakable, why do data breaches still happen?

AES-256 encryption is mathematically sound. The breaches happen everywhere else. Verizon's 2026 Data Breach Investigations Report found that the human element was present in 62% of breaches — stolen credentials, privilege misuse, social engineering. Attackers don't break the cipher. They steal the key, compromise the endpoint, or exploit the person holding the password.

The 2026 DBIR also marks a structural shift: for the first time in 19 years of the report's publication, vulnerability exploitation has overtaken stolen credentials as the top initial access vector, accounting for 31% of all breaches, up from 20% the prior year. AI is accelerating this — threat actors now use it to shrink the window between vulnerability disclosure and active exploitation from months to hours.

IBM's 2025 Cost of a Data Breach Report puts the financial weight on these failures at $4.44 million per incident on average. Organizations with high levels of shadow AI (employees using unapproved AI tools on corporate devices) paid an additional $670,000 per breach. The 2026 DBIR adds context: shadow AI is now the third most common non-malicious insider data leakage activity, with regular AI tool usage among employees jumping from 15% to 45% in a single year.

These numbers frame the real problem: encryption protects data at rest and in transit, but it cannot protect against an authorized user doing something unauthorized, a vulnerability left unpatched for eight months, or an endpoint that's already compromised.

The six gaps that bypass encryption

Here is a structured way to think about where AES-256 fails in practice — not because the algorithm is weak, but because the surrounding architecture is.

The "Encryption Is Not Enough" gap model:

1. Key management failures. Hardcoded encryption keys in source code, keys stored alongside the data they protect, keys that never rotate. If the key is compromised, the encryption is worthless. Hardware Security Modules (HSMs) and key derivation functions like PBKDF2 exist precisely to address this. Passwork, for example, derives its master key from the user's master password via PBKDF2 with 300,000 iterations and SHA-256 — making brute-force of the master password computationally expensive even if the encrypted database is exfiltrated.
2. Compromised endpoints. Malware operating on an endpoint reads data after decryption, in RAM. The data was encrypted at rest, it was decrypted to be used, the malware captured it in plaintext. AES-256 provides zero protection here. This is why endpoint detection and response (EDR) and privileged access workstations (PAWs) are not optional layers.
3. Insider threats. Authorized users with legitimate decryption access can exfiltrate data. Encryption does not distinguish between a legitimate administrator and a malicious one. Role-based access control (RBAC), least-privilege principles, and audit logging are the controls that address this gap.
4. Poor access control. Shared credentials, overly broad permissions, and stale accounts left active after employee departures all create exposure that encryption cannot mitigate.
5. Metadata exposure. Even when content is encrypted, metadata (who communicated with whom, when, how often, file sizes, access patterns) can reveal sensitive information. Encryption protects the payload, not the envelope.
6. Post-sharing loss of control. Once an encrypted file is shared and the recipient decrypts it, you have no control over what happens next. Digital rights management (DRM) and zero-trust file-sharing architectures partially address this, but no solution is complete.

Known cryptanalytic attacks on AES-256 — and why they don't matter in practice

For completeness: the best known attacks against full AES-256 are the biclique attack (computational complexity of approximately 2²⁵⁴⋅⁴, barely below the brute-force bound of 2²⁵⁶) and related-key attacks (complexity around 2⁹⁹⋅⁵ under highly specific conditions).

Neither is practically relevant. The biclique attack requires more computation than is physically feasible. Related-key attacks require the attacker to control the relationship between multiple keys — a condition that does not exist in any properly designed system. Side-channel attacks (power analysis, timing attacks, cache-timing) are a genuine concern, but they target the implementation, not the algorithm. Constant-time implementations and hardware AES acceleration (AES-NI) mitigate most of these.

Enterprise best practices for AES-256 in 2026

Deploying AES-256 correctly in 2026 means thinking in three planes: data at rest, data in transit, and data in use. Most organizations have the first two partially covered. The third is where the next generation of breaches will occur.

Data at rest

Use AES-256-GCM for new implementations. Ensure keys are managed separately from the data they protect — ideally in an HSM or a dedicated key management service. Rotate keys on a defined schedule and immediately upon suspected compromise. Use PBKDF2, bcrypt, or Argon2 to derive encryption keys from passwords. Never use the password directly as a key.

Full-disk encryption (BitLocker on Windows, FileVault on macOS) provides a baseline for endpoint protection, but it only protects against physical theft of a powered-off device. It does not protect against a logged-in user or a running malware process.

Data in transit

TLS 1.3 is the current standard. It mandates AEAD cipher suites (AES-256-GCM or ChaCha20-Poly1305), removes weak cipher suites present in TLS 1.2, and provides forward secrecy by default. If your infrastructure still supports TLS 1.2 with CBC cipher suites, that is a configuration debt worth addressing now.

Data in use — the unsolved problem

Data in use is plaintext in memory while being processed. Confidential computing frameworks — Intel SGX (Software Guard Extensions) and AMD SEV (Secure Encrypted Virtualization) — create hardware-isolated execution environments (trusted execution environments, or TEEs) where even the hypervisor or operating system cannot read the data being processed. This is the frontier of encryption architecture, and it is increasingly relevant for cloud workloads handling sensitive data.

Zero-knowledge architecture

A zero-knowledge architecture means the service provider (or server) never has access to plaintext data or the keys to decrypt it. Client-side encryption is the mechanism: data is encrypted on the client before transmission, and the server stores only ciphertext. Passwork's client-side encryption mode implements this — the master key is derived from the user's master password and never transmitted to the server, meaning even a full server compromise yields only encrypted data.

Compliance anchors

AES-256 is not just a technical best practice — it is a compliance requirement across multiple frameworks:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) designates AES-256 as a valid encryption method for protected health information (PHI), rendering breached data "not usable, unreadable, or indecipherable."
• GDPR Article 32 requires "appropriate technical measures" including encryption to protect personal data. AES-256 is the de facto standard for satisfying this requirement.
• PCI DSS Requirement 3 mandates strong cryptography for stored cardholder data. AES-256 meets this requirement; AES-128 is the minimum.
• NSA CNSA 2.0 mandates AES-256 (not AES-128) for all National Security Systems at all classification levels.

Conclusion

AES-256 remains the right foundation for data encryption in 2026. The algorithm has no practical weakness (classical or quantum) and that position is unlikely to shift within any planning horizon that matters to your organization today.

The harder truth is that the algorithm was never the problem. The 2026 DBIR found the human element in 62% of breaches. That's not a cryptography failure. It's a failure in key management, access control, endpoint hygiene, and operational discipline.

Three things are worth prioritizing right now:

1. Audit where your encryption keys live. If any are hardcoded or stored adjacent to the data they protect, that is the most urgent fix on this list.
2. Migrate asymmetric key exchange to post-quantum algorithms. HNDL is a present risk for any data with a multi-year sensitivity horizon.
3. Move credential management into a structured vault. If your team still relies on spreadsheets or shared documents, the access control problem is more immediate than any cryptographic question.

AES-256 does its job. The question is whether everything around it does too.

Frequently asked questions about AES-256 encryption

Is AES-256 encryption truly unbreakable?

AES-256 has no known practical attack that breaks it within a feasible timeframe. The best classical attack (biclique) achieves a complexity of approximately 2²⁵⁴⋅⁴ operations — marginally below brute force but computationally impossible to execute. No classical or quantum computer built today, or projected for the next decade, can break AES-256 by attacking the algorithm directly.

Can quantum computers break AES-256?

No. Grover's algorithm — the relevant quantum threat to symmetric encryption — reduces AES-256's effective security from 256 bits to approximately 128 bits. 128-bit security remains unbreakable by any known or projected quantum hardware. NIST explicitly confirms that AES with 128, 192, or 256-bit keys is secure against quantum attacks. Asymmetric algorithms like RSA are the ones facing genuine quantum risk.

What is the difference between AES-256-GCM and AES-256-CBC?

AES-256-GCM provides authenticated encryption (AEAD): it encrypts data and produces a message authentication code in a single pass, guaranteeing both confidentiality and integrity. AES-256-CBC encrypts only — without a separate MAC, it is vulnerable to padding oracle and bit-flipping attacks. TLS 1.3 removed CBC support entirely. For new deployments, GCM is the correct choice.

What is "Harvest Now, Decrypt Later" and should I be worried?

HNDL is a strategy where adversaries intercept and store encrypted data today, intending to decrypt it once quantum computers become capable. For data with a long sensitivity horizon — classified information, medical records, long-term financial data — this is a present risk. The mitigation is migrating asymmetric key exchange protocols to post-quantum algorithms (FIPS 203/204/205) now, while continuing to use AES-256 for symmetric encryption.

Why do organizations using AES-256 still get breached?

Because attackers bypass the encryption rather than breaking it. Stolen credentials, compromised endpoints, poor key management, insider threats, and overly broad access permissions all expose plaintext data without ever touching the cipher.

What is a zero-knowledge architecture in a password manager?

A zero-knowledge architecture means the server never receives or stores plaintext credentials or the keys to decrypt them. Encryption happens on the client (in the browser or application) before data is transmitted. Even if the server is fully compromised, the attacker obtains only ciphertext. This is the architecture required for any credential management tool handling sensitive corporate secrets.

Does AES-256 satisfy HIPAA, GDPR, and PCI DSS requirements?

Yes, for all three. HIPAA's Safe Harbor provision (45 CFR §164.312) designates AES-256 as a valid encryption standard for PHI. GDPR Article 32 requires appropriate technical measures including encryption — AES-256 satisfies this. PCI DSS Requirement 3 mandates strong cryptography for stored cardholder data, with AES-256 as the accepted standard. Compliance requires correct implementation, not just the presence of encryption.

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn’t revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it’s treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

Passwork BlogAlex Muntyan

La criptografía en España no es un asunto técnico que pueda delegarse al equipo de IT. Es una obligación legal con consecuencias directas para el consejo de administración: multas de hasta 10 millones de euros, responsabilidad personal de los directivos y exclusión de la contratación pública. Este artículo cubre cada capa del marco normativo: algoritmos aprobados, leyes aplicables, organismos supervisores, sectores obligados, sanciones reales y en qué se diferencia el modelo español del resto del mundo.

1. La estructura de autoridad criptográfica: quién decide qué es legal

El Centro Criptológico Nacional (CCN)

El CCN es la autoridad criptológica nacional de España, constituido bajo el Real Decreto 421/2004 como división del Centro Nacional de Inteligencia (CNI). Tiene tres poderes que todo directivo debe conocer.

Aprobación de algoritmos. El CCN publica la lista definitiva de mecanismos criptográficos autorizados en la serie de guías CCN-STIC 221. Ningún algoritmo tiene respaldo legal para su uso en el sector público español ni en entornos regulados sin figurar en esta guía. La edición de noviembre de 2025 es la referencia en vigor.

Certificación de productos. El CCN gestiona el Catálogo de Productos de Seguridad TIC (CPSTIC), la lista oficial de productos autorizados para la administración pública. Los productos se clasifican como Cualificados (para ENS Medio/Alto) o Aprobados (para información clasificada nacional). La inclusión requiere superar uno de dos esquemas: LINCE (el esquema ligero español, válido para ENS Medio) o Common Criteria / EUCC bajo el acuerdo de reconocimiento mutuo SOG-IS (obligatorio para ENS Alto). Desde 2024–2025, el CCN exige adicionalmente la MEMeC (CCN-STIC 2100) — Metodología para la Evaluación de Mecanismos Criptográficos — para cualquier producto que solicite inclusión en el CPSTIC cuando el cifrado sea su función principal.

Respuesta a incidentes. El CCN-CERT gestiona los incidentes de ciberseguridad de la administración pública, los sistemas clasificados y las infraestructuras críticas nacionales. El CCN es también la Autoridad Nacional de Certificación de Ciberseguridad de la UE, conforme al Reglamento de Ciberseguridad (2019/881).

Otros organismos reguladores clave

2. El marco legal en detalle

2.1 Derecho de la UE de aplicación directa

2.2 Legislación nacional primaria

Real Decreto 311/2022 — Esquema Nacional de Seguridad (ENS)

El ENS es el marco maestro de seguridad de la información del sector público. Actualizado en mayo de 2022, sustituye al RD 3/2010 y se aplica a todas las administraciones públicas (central, autonómica, local) y a todo proveedor privado de servicios TIC a las mismas. Aspectos clave para el cumplimiento criptográfico:

• Tres categorías de seguridad: Básica, Media, Alta, determinadas por la evaluación de impacto del Anexo I en las dimensiones de confidencialidad, integridad, disponibilidad, autenticidad y trazabilidad.
• Los controles de criptografía del Anexo II escalan significativamente de Básica a Alta.
• Para sistemas ENS Alto: solo se aceptan algoritmos aprobados por el CCN (CCN-STIC 221) y productos del CPSTIC; los módulos criptográficos deben superar evaluación MEMeC/LINCE o CC/SOG-IS.
• Auditorías externas obligatorias cada dos años en categorías Media y Alta.
• La certificación de conformidad es requisito en licitaciones públicas: un proveedor sin certificado ENS queda excluido del proceso, con independencia del precio.

Ley Orgánica 3/2018 — LOPDGDD

La ley española de implementación del RGPD. Añade obligaciones específicas más allá del RGPD: el Título X (Derechos digitales) refuerza los principios de seguridad de datos que sustentan las obligaciones de cifrado. La AEPD ha consolidado mediante su práctica sancionadora que el cifrado de datos personales en reposo y en tránsito es la medida técnica mínima exigida — y que su ausencia, incluso con posterioridad a una brecha, constituye una infracción independiente del artículo 5(1)(f) adicional a la del artículo 32.

Ley 6/2020 sobre servicios de confianza electrónicos

Aprobada en noviembre de 2020, derogó la histórica Ley 59/2003 de Firma Electrónica. Adapta el derecho nacional a la taxonomía eIDAS: firmas simples, avanzadas y cualificadas, sellos, marcas de tiempo y entregas certificadas. En España, las firmas electrónicas cualificadas (QES) tienen el mismo valor legal que las manuscritas y requieren un dispositivo QSCD — en la práctica, el DNIe o un certificado software cualificado emitido por la FNMT-RCM. Los requisitos criptográficos de estos dispositivos los fija ETSI EN 419 241.

Real Decreto-Ley 14/2019 — Soberanía de datos

Exige que los sistemas que procesan datos biométricos y otras categorías especiales en nombre del sector público estén alojados en territorio español o en infraestructura que cumpla estándares de soberanía específicos. Esto prohíbe de facto ciertos modelos de gestión extraterritorial de claves criptográficas para el procesamiento de datos especiales del sector público.

Real Decreto-Ley 12/2018 — Transposición NIS1

Estableció la división de responsabilidades entre CCN-CERT (sector público) e INCIBE-CERT (sector privado) y creó la obligación de notificación de incidentes para operadores de servicios esenciales. Formalmente en vigor, pero en la práctica superado por el anteproyecto NIS2.

Ley 8/2011 + RD 704/2011 — Protección de infraestructuras críticas

Marco legal para los 12 sectores críticos designados (energía, agua, transporte, TIC, sistema financiero, alimentación, salud, nuclear, espacio, investigación, químico, administración pública). Los operadores de infraestructuras críticas (OCI) deben contar con un Plan de Seguridad del Operador (PSO) aprobado por el CNPIC.

Ley 34/2002 (LSSI-CE)

La ley de servicios de la sociedad de la información. La AEPD ha impuesto sanciones bajo esta norma por transmitir parámetros sensibles por canales sin cifrar en servicios web.

2.3 La transposición NIS2 pendiente: lo que viene

Este es el desarrollo normativo más relevante a corto plazo. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad fue aprobado por el Consejo de Ministros el 14 de enero de 2025. A mayo de 2026, sigue pendiente de aprobación parlamentaria — la Comisión Europea emitió un dictamen motivado contra España en mayo de 2025 por no haber transpuesto la NIS2 antes del plazo del 17 de octubre de 2024, y el riesgo de procedimiento ante el Tribunal de Justicia de la UE permanece abierto.

Disposiciones clave del borrador relevantes para la criptografía:

• Ámbito: Las organizaciones con 50 o más empleados y más de 10 millones de euros de facturación anual que operen en sectores de alta criticidad se clasifican como entidades esenciales; las medianas empresas de sectores importantes, como entidades importantes.
• Art. 15 (Medidas generales de gestión de riesgos): Referencia explícita al art. 21(2)(h) de NIS2 — la criptografía y el cifrado son medidas obligatorias, no opcionales.
• Art. 14 (Gobernanza): Los órganos de dirección deben aprobar las estrategias de ciberseguridad y son personalmente responsables de las infracciones; los miembros del consejo responden solidariamente por las infracciones cometidas por la entidad.
• Art. 16 (Responsable de seguridad): Las entidades esenciales e importantes deben designar un Responsable de Seguridad de la Información (equivalente al CISO) con autoridad definida por ley.
• Art. 18 (Notificación de incidentes): Alerta temprana en 24 horas, notificación en 72 horas e informe final en un mes a la autoridad competente.
• Sanciones: Entidades esenciales — hasta 10 millones de euros o el 2 % del volumen de negocios global anual (el mayor de los dos); entidades importantes — hasta 7 millones de euros o el 1,4 %. Las sanciones operativas incluyen la suspensión de certificaciones o autorizaciones ligadas al servicio.

3. Algoritmos aprobados: qué está permitido y qué está prohibido

3.1 La lista CCN-STIC 221 desglosada

La CCN-STIC 221 es la referencia definitiva española. Es un superconjunto de los SOG-IS Agreed Cryptographic Mechanisms (ACM) v1.2, que añade algoritmos poscuánticos y ciertos mecanismos clásicos no incluidos en la lista SOG-IS. A continuación, el desglose por tipo de primitiva.

Cifrado simétrico

Funciones hash

Criptografía asimétrica

• RSA: Claves mínimas de 3.072 bits para nuevos despliegues. El CCN indica explícitamente que los prestadores de servicios de confianza que usan RSA-2048 deben migrar cuanto antes. Se recomienda RSA-4096 para seguridad a largo plazo. Relleno: RSASSA-PSS (PKCS#1 v2.1) obligatorio para nuevas firmas; PKCS#1 v1.5 tolerado solo para verificar firmas heredadas.
• ECDSA / ECDH: Aprobado en curvas NIST P-256, P-384, P-521 y curvas Brainpool brainpoolP256r1, brainpoolP384r1, brainpoolP512r1.
• EdDSA (Ed25519, Ed448): Aprobado; especialmente recomendado para contextos de alto rendimiento.

Derivación de claves (KDF)

• HKDF (RFC 5869): Aprobado.
• PBKDF2 con HMAC-SHA-256 y mínimo 600.000 iteraciones: Aprobado para cifrado basado en contraseña.
• scrypt: Incorporado a CCN-STIC 221 en 2023 como KDF aprobado para contraseñas.
• Argon2id: En revisión; no listado formalmente, pero no está prohibido.

Seguridad en la capa de transporte (TLS)

• TLS 1.3: Obligatorio para nuevas implementaciones.
• TLS 1.2 con suites de cifrado aprobadas (ECDHE + AES-GCM + HMAC-SHA-256/384): Tolerado en sistemas heredados.
• TLS 1.0/1.1: Prohibidos.
• Suites TLS 1.3 aprobadas: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256.

3.2 Criptografía poscuántica (PQC): ya es oficial en España

La actualización de noviembre de 2025 de la CCN-STIC 221 supone un cambio de paradigma: España ha adoptado formalmente los estándares poscuánticos finalizados por el NIST.

Esquemas híbridos — obligatorios durante la transición. El CCN exige la construcción híbrida «CAT-then-KDF» para acuerdo de claves en sistemas críticos: un acuerdo de claves clásico (ECDH) combinado con un KEM poscuántico, cuyos resultados se combinan mediante un KDF aprobado. Así se garantiza que un atacante clásico no pueda debilitar el esquema aunque la primitiva PQC resulte vulnerable en el futuro.

La posición del CCN es inequívoca: los sistemas nacionales críticos y los prestadores de servicios de confianza deben comenzar la planificación de migración híbrida PQC de inmediato, con especial urgencia para datos clasificados de larga vida útil.

4. El ecosistema de certificación CPSTIC

El CPSTIC no es una lista de recomendaciones — para sistemas ENS Alto e información clasificada, el uso de productos que no figuren en él está efectivamente prohibido. Comprender los niveles de certificación es fundamental para el diseño de contratos y la gestión de compras.

Nivel 1 — Productos Aprobados

Productos autorizados para gestionar información clasificada nacional. Requieren evaluación de: requisitos de seguridad funcionales, análisis TEMPEST (emanaciones electromagnéticas) y evaluación criptológica que verifica la conformidad con CCN-STIC 221 mediante MEMeC. El proceso está regulado por CCN-STIC 102/103. Es el nivel más exigente; solo un número reducido de productos — típicamente nacionales o de países aliados — lo alcanzan. La reevaluación es periódica y obligatoria; el proceso es circular, no puntual.

Nivel 2 — Cualificados ENS Alto

Productos válidos para sistemas de categoría ENS Alto. Requieren certificación Common Criteria / EUCC en EAL4+ (o equivalente bajo SOG-IS MRA) más una evaluación STIC complementaria para los requisitos específicos del CCN. La MEMeC (CCN-STIC 2100) es ahora obligatoria para el componente de evaluación del módulo criptográfico. La administración pública debe patrocinar la inclusión del producto; el CCN realiza evaluaciones caso por caso que pueden incluir pruebas de penetración o revisión criptográfica adicional.

Nivel 3 — Cualificados ENS Medio

Productos válidos para sistemas de categoría ENS Medio. Requieren certificación LINCE, que incluye análisis de vulnerabilidades, pruebas de penetración y, opcionalmente, el Módulo de Evaluación Criptográfica (MEC) para productos donde el cifrado es la función principal. LINCE es más rápido y económico que Common Criteria: plazos típicos de 3–6 meses frente a 12–24 meses para CC.

Los grandes proveedores cloud ya están certificados. AWS obtuvo la certificación ENS Alto 311/2022 en 172 servicios; Microsoft Azure y Microsoft 365 también cuentan con certificación ENS Alto (auditados por BDO); AWS ha certificado 25 servicios de seguridad en el CPSTIC. Esto es estratégicamente relevante: las administraciones públicas españolas solo pueden contratar servicios cloud ENS-certificados para sistemas de categoría media y alta.

5. Dónde es obligatorio cifrar: análisis por sectores

5.1 Administración pública (ENS obligatorio)

Todas las administraciones públicas y sus proveedores privados que manejen datos del sector público están sujetos al ENS. Las obligaciones de cifrado por categoría:

ENS Básico — Cifrado recomendado; controles específicos según análisis de riesgos.

ENS Medio — Cifrado del dato en tránsito obligatorio (TLS 1.2+/1.3); cifrado de datos sensibles en reposo requerido; dispositivos móviles y soportes extraíbles deben estar completamente cifrados.

ENS Alto — Cifrado completo de datos en reposo y en tránsito con algoritmos conformes a CCN-STIC 221 y productos del CPSTIC; procedimientos de gestión de claves documentados y auditados; HSMs requeridos para el almacenamiento de claves en muchas configuraciones.

El cumplimiento ENS es un requisito de contratación pública. Sin certificado ENS válido, no es posible participar en licitaciones de categoría media y alta.

5.2 Sector financiero

El sector financiero español opera bajo un régimen de cifrado superpuesto de múltiples normas.

DORA (Reglamento 2022/2554) — en vigor desde enero de 2025. El artículo 9 exige cifrado de datos en reposo y en tránsito; el artículo 6 exige controles criptográficos como parte de la gestión de riesgos TIC; el artículo 10 requiere capacidades de detección que incluyan verificación de integridad. DORA se aplica a bancos, aseguradoras, firmas de inversión, entidades de pago, proveedores de criptoactivos y, de forma crítica, a sus proveedores TIC terceros (nube, centros de datos, proveedores de software).

Banco de España / CNMV. Los sistemas de pago electrónico, la conectividad SWIFT y TARGET2/T2S exigen HSMs certificados con FIPS 140-3 / Common Criteria EAL4+ como mínimo. Los requisitos de autenticación reforzada de clientes (SCA) bajo PSD2 exigen firmas ECDSA o RSA para el dynamic linking.

PCI-DSS v4.0. Obligatorio para procesadores de pagos con tarjeta; exige TLS 1.2+ como mínimo (TLS 1.3 ampliamente recomendado), AES-256 para datos de titulares de tarjetas en reposo, y procedimientos específicos de gestión de claves.

5.3 Sanidad

• HCDSNS (Historia Clínica Digital del SNS): Clasificado ENS Alto en dimensión de confidencialidad; requiere cifrado extremo a extremo con productos del CPSTIC.
• Receta electrónica: Las implementaciones regionales deben cumplir ENS Medio o Alto según la clasificación; se exige integridad y autenticidad criptográfica de los datos de prescripción.
• Datos de salud bajo el RGPD: Los datos de salud son categoría especial según el art. 9 del RGPD; la AEPD trata sistemáticamente la ausencia de cifrado para datos sanitarios como infracción grave.
• RD-Ley 14/2019 (soberanía de datos): El procesamiento de datos especiales de salud del sector público debe realizarse en territorio español o en infraestructura que cumpla los estándares de soberanía del CCN; esto tiene implicaciones directas sobre la jurisdicción de la gestión de claves.

5.4 Telecomunicaciones

• Los operadores bajo la Ley 11/2022 General de Telecomunicaciones deben implementar medidas de seguridad para la integridad de redes y servicios, incluido el cifrado de interfaces de gestión y datos operativos sensibles.
• 5G: GSMA FS.33 y ETSI TS 133 501 rigen los requisitos criptográficos del 5G: protección SUPI/SUCI mediante ECIES, autenticación 5G-AKA (AES-128/256 + ECDH P-256). Los operadores españoles deben cumplir adicionalmente el EU 5G Security Toolbox, que incluye restricciones sobre proveedores de alto riesgo.
• Interceptación legal (LI): Los operadores deben implementar interfaces ETSI normalizadas (ETSI ES 201 158, TS 101 671) que exigen integridad y confidencialidad criptográfica en la entrega del producto interceptado a las fuerzas del orden.
• SIM/eSIM: GSMA SGP.02 y SGP.22 requieren AES-128 para la gestión de perfiles OTA y ECDH P-256 para el acuerdo de claves.

5.5 Infraestructuras críticas (energía, agua, transporte, nuclear)

Los operadores de infraestructuras críticas deben implementar medidas de ciberseguridad conforme a la Ley 8/2011 y la guía del CNPIC. En el sector energético se aplican adicionalmente requisitos análogos al NERC CIP para sistemas de control industrial (SCADA/ICS), donde el cifrado de comunicaciones de tecnología operacional (OT) es una exigencia creciente.

5.6 Administración electrónica: identidad digital y firma

España dispone de una infraestructura criptográfica de identidad digital entre las más avanzadas de Europa.

• DNIe: La tarjeta de identidad electrónica española, emitida por la Dirección General de la Policía, contiene claves RSA-2048 para autenticación y creación de firmas cualificadas; las versiones DNIe 3.x recientes soportan ECC. Funciona como dispositivo QSCD bajo eIDAS.
• Certificados FNMT-RCM: La Casa de la Moneda emite certificados electrónicos cualificados para ciudadanos, organizaciones y empleados públicos. Los algoritmos de certificado están migrando de RSA-2048 a RSA-4096/ECC.
• Plataforma Cl@ve: El sistema unificado de identidad ciudadana. Incluye Cl@ve PIN (OTP), Cl@ve Permanente (usuario/contraseña + OTP) y Cl@ve Firma (servicio de firma cualificada remota en la nube mediante claves protegidas en HSM). Todos los canales interoperan con el nodo eIDAS español para el reconocimiento transfronterizo. El servicio de firma en la nube cumple ETSI EN 419 241-2.
• Plataforma @firma: El servicio de validación de firma electrónica empleado por la mayoría de administraciones públicas. Soporta PAdES (ETSI TS 102 778), XAdES (ETSI TS 101 903) y contenedores ASiC (ETSI TS 102 918).

6. Estándares aplicables: tabla de referencia

7. Sanciones y exposición financiera real

7.1 Aplicación del RGPD/LOPDGDD por la AEPD

La AEPD es uno de los cinco organismos de protección de datos más activos de Europa. La tendencia es claramente alcista: 21.590 reclamaciones en 2023 (+47 % interanual); 367 multas por un total de 29,8 millones de euros en 2023; un récord de 35,5 millones de euros en 2024 (+19,4 %). En 2025, se registraron 2.765 notificaciones de brechas de datos, que afectaron a más de 200 millones de personas — el doble de 2024 — impulsadas por ransomware y exfiltración de datos.

Marco máximo de sanciones bajo el RGPD/LOPDGDD:

• Nivel 1 (infracciones más graves — art. 83(5)): Hasta 20 millones de euros o el 4 % del volumen de negocios global anual, el mayor de los dos. Aplica a violaciones de principios básicos (art. 5), condiciones del consentimiento (art. 7), derechos del interesado (arts. 12–22) o transferencias internacionales (arts. 44–49).
• Nivel 2: Hasta 10 millones de euros o el 2 % del volumen de negocios global anual. Aplica a incumplimientos de seguridad (art. 32), fallos en evaluaciones de impacto (art. 35), etc.

Casos paradigmáticos con dimensión criptográfica o de seguridad:

Principio jurisprudencial crítico. La AEPD ha consolidado — y los tribunales españoles lo han confirmado — que ser víctima de un ciberataque no exime del cumplimiento de las obligaciones de seguridad del RGPD. El análisis relevante es si la organización implementó medidas preventivas proporcionales al riesgo antes del incidente. La remediación posterior al ataque se valora, pero es insuficiente por sí sola.

7.2 Sanciones NIS2 (transposición pendiente)

Bajo el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad:

• Entidades esenciales: Hasta 10 millones de euros o el 2 % del volumen de negocios global anual.
• Entidades importantes: Hasta 7 millones de euros o el 1,4 % del volumen de negocios global anual.
• Infracciones muy graves: Entre 500.001 y 2.000.000 euros para infracciones específicas (texto legislativo final pendiente).
• Sanciones operativas: Suspensión de certificaciones o autorizaciones vinculadas al servicio — para muchas empresas tecnológicas, equivale al cierre de la actividad de contratación pública.
• Responsabilidad personal: Los miembros del consejo de administración responden solidariamente por las infracciones; los directivos individuales pueden recibir sanciones personales y medidas disciplinarias.

El borrador introduce además una obligación de autorregistro: las entidades que cumplan los umbrales de alcance deben registrarse proactivamente ante la autoridad competente dentro de los tres meses siguientes a la entrada en vigor de la ley.

7.3 Sanciones DORA

DORA faculta al Banco de España y la CNMV para imponer:

• Pagos periódicos coercitivos de hasta el 1 % del volumen de negocios diario global por incumplimiento continuado.
• Multas estructurales por fallos sistémicos.
• Suspensión de servicios para proveedores TIC terceros críticos.

7.4 Infracciones en servicios de confianza (Ley 6/2020)

Multas administrativas de hasta 150.000 euros para prestadores cualificados de servicios de confianza; la responsabilidad civil por daños derivados de protecciones criptográficas inadecuadas en firmas o certificados electrónicos es ilimitada.

7.5 Incumplimiento ENS

No existe un marco de sanciones económicas directas por incumplimiento ENS en sí mismo, pero las consecuencias comerciales son graves:

• Exclusión de la contratación pública: Los proveedores no conformes no pueden competir en contratos que requieran certificación ENS Medio/Alto.
• Resolución de contratos: Los contratos públicos vigentes pueden rescindirse si la certificación ENS caduca.
• Daño reputacional: El incumplimiento es visible públicamente a través del registro de conformidad ENS.

8. Práctica sectorial: banca, sanidad, administración y telecomunicaciones

8.1 Banca y servicios financieros

Las entidades financieras españolas son las primeras en adoptar controles criptográficos, impulsadas por mandatos superpuestos (DORA, PCI-DSS, Banco de España, SSM del BCE).

• HSMs (Thales, Utimaco, AWS CloudHSM) certificados con FIPS 140-3 Nivel 3 / CC EAL4+ para gestión de claves. Al menos FIPS 140-3 Nivel 2 para servicios HSM en la nube.
• TLS 1.3 estándar para todos los servicios de cara al cliente; vida de los certificados limitada a 398 días; gestión automatizada de certificados (protocolo ACME).
• PSD2/SCA: ECDSA P-256 o RSA-2048 como mínimo para el dynamic linking; migración a RSA-4096/P-384 en nuevas implementaciones.
• Preparación poscuántica: El BCE y el Banco de España han emitido orientación alentando los programas de inventario de activos criptográficos (Crypto-Agility). Los principales bancos españoles (Santander, BBVA, CaixaBank) tienen grupos de trabajo PQC activos, con pilotos iniciales de TLS 1.3 híbrido + ML-KEM.

8.2 Sanidad y Seguridad Social

• MUFACE, ISFAS, MUGEJU (mutualidades de funcionarios): Historiales sanitarios clasificados ENS Alto; obligatorios productos del CPSTIC.
• Nodo de interoperabilidad del HCDSNS: TLS 1.3 extremo a extremo con autenticación mutua de cliente mediante certificados cualificados; integridad de la historia clínica protegida por firmas digitales.
• Seudonimización para investigación: Los datos clínicos de investigación deben seudonimizarse (no solo anonimizarse) conforme al art. 9 de la LOPDGDD; claves de seudonimización en HSMs del CPSTIC cifradas con AES-256.
• Datos biométricos en sanidad: La AEPD exige EIPDs y protección criptográfica de las plantillas biométricas para el reconocimiento facial de pacientes.

8.3 Administración electrónica

• Cl@ve Firma procesa millones de firmas cualificadas anuales; claves en HSMs aprobados por el CCN operados por la FNMT-RCM bajo ETSI EN 419 241-2.
• Notific@: El sistema nacional de notificaciones electrónicas usa marcas de tiempo cualificadas CAdES/XAdES (ETSI) como prueba legal de entrega.
• Contratación pública (PLACE/ROLECE): Requiere firmas electrónicas cualificadas para la presentación de ofertas; los funcionarios deben usar el DNIe o certificados cualificados de la FNMT-RCM.
• Agencia Tributaria: Las declaraciones fiscales en línea se tramitan a través de Cl@ve; los sistemas de respaldo procesan datos tributarios clasificados bajo ENS Alto con cifrado completo en reposo y en tránsito.

8.4 Telecomunicaciones

Telefónica (Movistar), Vodafone España y Orange/MásMóvil/Masorange:

• 5G: Elementos de red cifrados conforme a GSMA FS.33 / ETSI TS 133 501; protección SUPI/SUCI mediante ECIES, autenticación 5G-AKA (AES-128/256 + ECDH P-256).
• Core IP: IPsec ESP (AES-GCM-128/256) para backhaul e interfaces entre operadores; MACsec (IEEE 802.1AE con AES-128/GCM) para transporte óptico en la capa 2.
• Interceptación legal: Los operadores están sujetos a los requisitos de la Ley 11/2022; las interfaces ETSI LI deben garantizar la confidencialidad e integridad criptográfica del producto interceptado entregado a las fuerzas del orden bajo autorización judicial.

9. España frente al mundo: diferencias con EE. UU. y Reino Unido

España/UE frente a Estados Unidos

España/UE frente al Reino Unido (post-Brexit)

La salida del Reino Unido de la UE ha creado divergencia real:

• Firmas electrónicas: El eIDAS del Reino Unido fue incorporado al derecho nacional tal como estaba el 31 de diciembre de 2020. El Reino Unido mantiene su propia lista de confianza y no reconoce mutuamente de forma automática los certificados o firmas cualificados de la UE.
• Certificación de productos: El NCSC del Reino Unido opera CAPS y Foundation Grade; estos esquemas no son reconocidos mutuamente con CPSTIC ni con SOG-IS MRA.
• Transferencias de datos: El Reino Unido es actualmente considerado adecuado bajo la decisión de adecuación de la UE (vigente hasta junio de 2027 salvo renovación); las entidades que operen en ambos mercados deben monitorizar activamente una posible divergencia.

El diferenciador único del modelo español: el CPSTIC

La característica más distintiva del régimen español frente a la mayoría de los países de la OCDE es el requisito prescriptivo de certificación de producto para las compras del sector público — el CPSTIC. La mayoría de los países, incluso en la UE, no disponen de un catálogo obligatorio equivalente; se apoyan en el reconocimiento de Common Criteria y la contratación de mercado. Este requisito español genera:

• Una barrera de entrada estructural para proveedores extranjeros que no hayan superado la evaluación del CCN.
• Un incentivo estratégico para que los grandes proveedores cloud (AWS, Microsoft, Google, Oracle) obtengan la certificación española — y lo han hecho.
• Una ventaja de mercado para las empresas de productos de seguridad de ámbito español y europeo.

10. Hoja de ruta para la dirección: acciones inmediatas y a medio plazo

Acciones inmediatas (0–6 meses)

1. Realizar un inventario de activos criptográficos (evaluación de Crypto-Agility).
Mapee cada implementación de cifrado de su patrimonio tecnológico: algoritmos, longitudes de clave, bibliotecas, vidas útiles de certificados, certificaciones de HSM. Es el requisito previo para el cumplimiento ENS, la gestión de riesgos TIC bajo DORA y el futuro registro NIS2.

2. Clasificar su exposición ENS.
Si presta servicios TIC a algún organismo público español, determine la categoría ENS requerida (Básica, Media, Alta) e inicie el proceso de certificación. Los plazos habituales son 2–3 meses para Básica, 3–6 meses para Media y 6–18+ meses para Alta. Las brechas de certificación suponen un riesgo comercial inmediato.

3. Revisar la exposición ante la AEPD.
Audite los controles de cifrado para el tratamiento de datos personales. La trayectoria sancionadora de la AEPD (récord de 35,5 millones de euros en multas en 2024; 200 millones de afectados notificados en 2025) convierte esto en el riesgo de cumplimiento de mayor probabilidad. Verifique que todos los datos personales están cifrados en reposo y en tránsito con algoritmos conformes a CCN-STIC 221, y que no existan soportes extraíbles sin cifrar con datos personales en su organización.

4. Análisis de brechas DORA (sector financiero).
Si está en el ámbito de aplicación, la norma lleva en vigor desde enero de 2025. Mapee los controles de gestión de riesgos TIC respecto a los requisitos de cifrado del artículo 9 de DORA; revise los contratos con terceros TIC para incluir obligaciones de cifrado; y verifique que las certificaciones de los HSMs estén vigentes.

Acciones a medio plazo (6–18 meses)

5. Prepararse para la transposición NIS2.
Incluso sin promulgación formal, alinee su postura de seguridad con el borrador de ley. Identifique si es una entidad esencial o importante. Designe un Responsable de Seguridad de la Información. Documente los controles criptográficos para su aprobación formal por el órgano de dirección. Establezca una capacidad de notificación de incidentes en 24/72 horas.

6. Planificación de migración poscuántica.
Encargue una evaluación de riesgos PQC. Identifique datos y claves con requisitos de seguridad superiores a 10 años (documentos clasificados, contratos a largo plazo, historiales de pacientes). Priorice la migración a esquemas híbridos para esos activos. Consulte a sus proveedores de HSM y PKI sobre sus hojas de ruta PQC — la mayoría de los proveedores de primer nivel ya tienen soporte ML-KEM en beta o producción.

7. Diligencia debida criptográfica en la cadena de suministro.
Bajo NIS2 y DORA, la seguridad de la cadena de suministro es una obligación legal, no una buena práctica. Mapee las prácticas de cifrado de sus proveedores clave e imponga contractualmente la alineación con CCN-STIC 221 o estándares aprobados equivalentes.

Compromisos de gobernanza para el consejo de administración

8. La responsabilidad personal de los directivos es real.
Bajo la transposición NIS2 pendiente, los miembros del consejo responden solidariamente por las infracciones de ciberseguridad. Esto significa que los controles criptográficos inadecuados son un riesgo fiduciario del consejero, no solo un problema operativo. El consejo debe aprobar formalmente la política criptográfica de la organización, recibir informes periódicos sobre el estado de cumplimiento y asegurarse de que el seguro de D&O cubra adecuadamente la responsabilidad regulatoria cibernética.

9. Ciclos de auditoría y certificación.
ENS Medio/Alto exige auditorías externas cada dos años. Planifique los presupuestos de certificación y asigne recursos internos — un programa típico de certificación ENS Alto para un proveedor tecnológico mediano cuesta entre 150.000 y 400.000 euros, incluidos honorarios de consultoría, adaptación del producto y costes de auditoría.

10. Relacionarse proactivamente con el CCN e INCIBE.
Ambos organismos ofrecen orientación, asistencia técnica y servicios de preevaluación. Para las organizaciones que buscan la certificación de productos en el CPSTIC, el contacto temprano con el departamento CCN-PYTEC reduce significativamente los plazos de certificación. INCIBE ofrece herramientas gratuitas de ciberseguridad y guías sectoriales a través de su portal.

Conclusión

El panorama de cumplimiento criptográfico en España atraviesa su fase más exigente simultáneamente en tres frentes: la tendencia sancionadora récord de la AEPD bajo el RGPD/LOPDGDD, la inminente aprobación de la NIS2 con su responsabilidad personal para los directivos y la transición poscuántica global para la que el CCN ya ha publicado orientación formal.

Para las organizaciones con operaciones en España, la pregunta no es si hay que invertir en cumplimiento criptográfico, sino con qué rapidez. Las que saldrán mejor paradas son aquellas que traten la CCN-STIC 221 no como un formulario burocrático sino como el suelo técnico real que representa, integren la agilidad criptográfica en sus arquitecturas ahora para reducir los costes de migración futuros, y eleven la gobernanza del cifrado a la agenda del consejo antes de que los eventos regulatorios fuercen la cuestión.

El coste del incumplimiento — medido en multas de la AEPD, sanciones NIS2, exclusión de la contratación pública y responsabilidad personal de los directivos — supera con creces el coste del cumplimiento proactivo.

Every time you connect to a Wi-Fi network, send a message through an encrypted app, or access your bank account online, you're relying on encryption to keep your data safe. At the heart of this digital security infrastructure stands the Advanced Encryption Standard (AES) — the encryption algorithm trusted by everyone from individual users to intelligence agencies protecting classified information.

AES is a symmetric-key encryption algorithm that transforms readable data (plaintext) into an unreadable format (ciphertext) using a secret key. Since its adoption by the National Institute of Standards and Technology (NIST) in 2001, AES has become the global standard for data encryption, trusted by governments, financial institutions, and technology companies worldwide.

This guide will walk you through everything you need to know about AES: from its fundamental principles to advanced implementation strategies, regulatory compliance, and its resilience against emerging quantum computing threats.

What is the Advanced Encryption Standard (AES)?

The Advanced Encryption Standard (AES) is a symmetric-key block cipher that encrypts data in fixed-size blocks of 128 bits using keys of 128, 192, or 256 bits. Originally known as the Rijndael cipher, AES was developed by Belgian cryptographers Vincent Rijmen and Joan Daemen and selected by NIST in 2001 to replace the aging Data Encryption Standard (DES).

Unlike asymmetric encryption algorithms such as RSA, which use different keys for encryption and decryption, AES uses the same secret key for both operations. This symmetric approach makes AES exceptionally fast and efficient, particularly for encrypting large volumes of data.

The U.S. National Security Agency (NSA) approved AES-256 for protecting information classified as TOP SECRET, cementing its status as a military-grade encryption standard. Today, AES is mandated by the Federal Information Processing Standard (FIPS 197) and has been adopted globally as the de facto encryption standard for both commercial and government applications.

From DES to AES: A brief history

By the mid-1990s, the Data Encryption Standard (DES), which had served as the primary encryption standard since 1977, was showing its age. With a key length of only 56 bits, DES had become vulnerable to brute-force attacks as computing power increased. In 1997, NIST launched a public competition to select a new encryption standard that would be secure, efficient, and flexible enough to meet the needs of the 21st century.

The AES competition attracted 15 submissions from cryptographers around the world. After three years of rigorous analysis, testing, and public scrutiny, the Rijndael cipher emerged as the winner. NIST officially adopted AES as a federal standard in November 2001, and it was published as FIPS 197 in December of that year.

The selection of Rijndael was based on its superior combination of security, performance, and versatility. Unlike many competing algorithms, Rijndael could efficiently operate on various hardware platforms — from high-performance servers to resource-constrained embedded systems — while maintaining strong cryptographic properties.

How AES encryption works?

AES operates as a substitution-permutation network, performing multiple rounds of transformations on the data. The number of rounds depends on the key size: 10 rounds for AES-128, 12 rounds for AES-192, and 14 rounds for AES-256.

Before encryption begins, the algorithm expands the original key into a series of round keys through a process called key expansion. Each round then applies four distinct operations to scramble the data:

• SubBytes: This step provides non-linear substitution by replacing each byte in the data block with a corresponding value from a fixed substitution table called the S-box. This operation is crucial for AES's resistance to cryptanalysis, as it introduces confusion into the encryption process.
• ShiftRows: The bytes in each row of the data matrix are cyclically shifted by different offsets. The first row remains unchanged, the second row shifts one position to the left, the third row shifts two positions, and the fourth row shifts three positions. This operation provides diffusion by spreading the data across the entire block.
• MixColumns: Each column of the data matrix is transformed using a mathematical operation in the Galois Field GF(2^8). This step combines the bytes within each column, ensuring that changes to a single input byte affect multiple output bytes. The MixColumns operation is skipped in the final round.
• AddRoundKey: The round key is combined with the data block using a bitwise XOR operation. This step incorporates the secret key material into the encrypted data, ensuring that without the correct key, the ciphertext cannot be decrypted.

After all rounds are complete, the output is the encrypted ciphertext. Decryption reverses this process using inverse operations in the opposite order.

AES key sizes: 128, 192, or 256 Bits?

AES supports three key lengths, each offering different levels of security and performance characteristics:

• AES-128 uses a 128-bit key and performs 10 encryption rounds. It provides 128 bits of security, which translates to 2^128 possible key combinations — approximately 340 undecillion possibilities. For context, testing one billion keys per second would require billions of years to exhaust all possibilities. AES-128 is suitable for most commercial applications and offers the best performance of the three variants.
• AES-192 uses a 192-bit key and performs 12 rounds. While less commonly implemented than AES-128 or AES-256, it offers an intermediate security level for organizations that want additional protection without the performance overhead of AES-256.
• AES-256 uses a 256-bit key and performs 14 rounds. Often referred to as "military-grade encryption," AES-256 is approved by the NSA for protecting TOP SECRET information. The 256-bit key space provides 2^256 possible combinations, making it computationally infeasible to break through brute-force attacks, even with future advances in computing technology.

For most applications, AES-128 provides more than adequate security. However, organizations handling highly sensitive data, operating in regulated industries, or concerned about long-term data protection often choose AES-256. The performance difference between AES-128 and AES-256 is minimal on modern hardware, particularly on processors with AES-NI (AES New Instructions) hardware acceleration.

Understanding AES modes of operation

While AES encrypts data in 128-bit blocks, real-world applications typically need to encrypt data that's much larger than a single block. Modes of operation define how AES processes multiple blocks of data and how it handles data that doesn't fit evenly into 128-bit blocks.

• ECB (Electronic Codebook) is the simplest mode, encrypting each block independently with the same key. However, ECB has a critical weakness: identical plaintext blocks produce identical ciphertext blocks, revealing patterns in the encrypted data. ECB should never be used for encrypting anything beyond single blocks of random data.
• CBC (Cipher Block Chaining) addresses ECB's weakness by XORing each plaintext block with the previous ciphertext block before encryption. This creates a chain effect where each block depends on all previous blocks. CBC requires an initialization vector (IV) — a random value used to encrypt the first block. While CBC is widely used and secure when implemented correctly, it cannot be parallelized and is vulnerable to padding oracle attacks if not properly implemented.
• GCM (Galois/Counter Mode) is the recommended mode for most modern applications. GCM combines the counter mode of encryption with Galois field multiplication to provide both confidentiality and authentication. Unlike CBC, GCM can be parallelized for better performance and produces an authentication tag that verifies data integrity. This authenticated encryption approach protects against tampering and certain types of attacks that can compromise CBC implementations.
• CTR (Counter Mode) turns AES into a stream cipher by encrypting a counter value and XORing the result with the plaintext. CTR mode is parallelizable and doesn't require padding, making it efficient for high-performance applications. However, CTR alone doesn't provide authentication, so it's often combined with a separate authentication mechanism.

For new implementations, security experts recommend using AES-GCM. Its combination of encryption and authentication in a single operation, along with its performance characteristics, makes it the preferred choice for protocols like TLS 1.3, IPsec, and modern VPN implementations.

Why AES remains the global standard

More than two decades after its adoption, AES continues to dominate the encryption landscape for several compelling reasons:

• Unbroken Security: Despite extensive cryptanalysis by researchers worldwide, no practical attack has been found that can break properly implemented AES encryption. The best known attacks against AES-256 are theoretical and require computational resources far beyond anything currently available.
• Exceptional Performance: AES is designed for efficiency on both hardware and software implementations. Modern processors include dedicated AES-NI instructions that accelerate AES operations by up to 10 times compared to software-only implementations. The hardware encryption market, which includes AES-accelerated processors, is projected to grow from $359.5 million in 2025 to $698.7 million by 2032.
• Widespread Adoption: According to a 2025 survey, 46.2% of U.S. Managed Service Providers favor AES as their primary encryption method. This widespread adoption creates a virtuous cycle: more implementations lead to better-tested code, more hardware support, and increased interoperability.
• Regulatory Compliance: AES is mandated or recommended by numerous regulatory frameworks, including FIPS 197, GDPR, HIPAA, and PCI DSS. This regulatory acceptance makes AES the safe choice for organizations operating in regulated industries.

Real-world applications of AES

AES encryption protects data across virtually every digital domain:

• Network Security: AES secures internet communications through HTTPS (using TLS/SSL protocols), protects VPN connections, and encrypts Wi-Fi networks through WPA2 and WPA3 standards. Every time you see a padlock icon in your browser, AES is likely protecting your data in transit.
• Data Storage: Operating systems use AES for full-disk encryption (BitLocker on Windows, FileVault on macOS, LUKS on Linux). Cloud storage providers encrypt data at rest using AES-256, with the cloud encryption market holding a 69% share in 2024.
• Mobile Devices: Smartphones use AES to encrypt stored data, secure messaging applications, and protect mobile payment transactions. The encryption happens transparently in the background, with dedicated hardware accelerators ensuring minimal impact on battery life.
• Financial Services: Banks and payment processors rely on AES to protect financial transactions, secure ATM communications, and encrypt sensitive customer data. The Payment Card Industry Data Security Standard (PCI DSS) specifically requires strong encryption for cardholder data.
• Healthcare: Medical institutions use AES-256 to protect electronic Protected Health Information (ePHI) as required by HIPAA regulations. The 2025 HIPAA updates mandate encryption for ePHI, with AES as the de facto standard and requirements for Hardware Security Modules (HSMs) for key management.
• Password Managers: Modern password managers like Passwork rely on AES-256 encryption to protect your stored credentials, ensuring that even if someone gains access to your password vault file, they cannot read its contents without your master password.
• Government and Military: AES-256 is approved for protecting classified information up to the TOP SECRET level, making it the encryption standard for government communications, military operations, and intelligence agencies.

AES and regulatory compliance

For organizations operating in regulated industries, AES encryption is often a compliance requirement:

• FIPS 197 is the official NIST standard that defines AES. Organizations working with the U.S. federal government must use FIPS 197-validated cryptographic modules, ensuring that their AES implementations meet rigorous security standards.
• GDPR requires organizations to implement "appropriate technical and organizational measures" to protect personal data. While GDPR doesn't mandate specific encryption algorithms, AES-256 is widely recognized as meeting the regulation's requirements for strong encryption.
• HIPAA mandates encryption for electronic Protected Health Information (ePHI). The 2025 HIPAA updates specifically require encryption both in transit and at rest, with AES-256 recommended as the standard and HSMs required for secure key management.
• PCI DSS requires merchants and service providers to encrypt cardholder data during transmission and storage. AES is explicitly mentioned as an acceptable encryption algorithm for meeting PCI DSS

The future of AES: Quantum computing and beyond

The emergence of quantum computing has raised questions about the future of encryption. Quantum computers leverage quantum mechanical phenomena to perform certain calculations exponentially faster than classical computers. Shor's algorithm, running on a sufficiently powerful quantum computer, could break RSA and other asymmetric encryption schemes that rely on the difficulty of factoring large numbers.

However, symmetric encryption algorithms like AES are significantly more resistant to quantum attacks. The primary quantum threat to AES comes from Grover's algorithm, which can search through possible keys faster than classical brute-force attacks. Grover's algorithm effectively halves the security level of symmetric encryption — meaning AES-256 would provide 128 bits of security against quantum attacks, and AES-128 would provide 64 bits.

This is why security experts recommend AES-256 for data that needs long-term protection. Even in a post-quantum world, AES-256 will remain secure, providing the equivalent of 128-bit security — still far beyond the reach of any conceivable quantum computer.

In August 2024, NIST released the first three finalized Post-Quantum Cryptography (PQC) standards: FIPS 203, 204, and 205. These standards focus on quantum-resistant asymmetric algorithms for key exchange and digital signatures. The recommended approach for the quantum era is hybrid encryption: using post-quantum algorithms to securely exchange keys, then using AES to encrypt the actual data.

Frequently Asked Questions

Conclusion

The Advanced Encryption Standard has proven to be one of the most successful cryptographic standards in history. More than two decades after its adoption, AES remains unbroken, widely implemented, and continues to protect the vast majority of encrypted data worldwide.

As we move into an era of quantum computing and increasingly sophisticated cyber threats, AES-256 stands ready to continue its role as the workhorse of data encryption. Its combination of strong security, excellent performance, and regulatory acceptance ensures that AES will remain the encryption standard of choice for years to come.

Whether you're a developer implementing encryption in your applications, a business leader ensuring compliance, or simply someone who wants to understand how your data is protected, AES represents the gold standard in modern cryptography. By using strong encryption, maintaining secure key management practices, and staying informed about emerging threats, you can leverage AES to protect your most sensitive data in an increasingly connected world.

The 2025 small business cybersecurity checklist: A complete guide | Passwork

Passwork’s 2025 cybersecurity checklist, based on the NIST framework, provides actionable steps to prevent data breaches and financial loss.

Passwork BlogEirik Salmi

HIPAA requirements for password management

Introduction In the complex ecosystem of modern healthcare, patient data is essential for secure management. In 2024, the U.S. healthcare sector experienced over 700 large-scale data breaches, marking the third consecutive year with such a high volume of incidents. This surge compromised over 275 million patient records, a significant

Passwork BlogAna Moore

Passwork 7.1: Vault types

Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a key challenge for administrators: controlling data access and delegating vault management across large organizations. Previously, the choice was limited to two types. Now, you can create

Passwork BlogEirik Salmi

Introducción

Las filtraciones de datos se han vuelto rutinarias: millones de usuarios en todo el mundo enfrentan las consecuencias de contraseñas comprometidas. La escala es asombrosa: miles de millones de credenciales quedan expuestas, alimentando ataques automatizados y credential stuffing a escala masiva. Servicios como «Have I Been Pwned» ahora rastrean más de 12 mil millones de cuentas filtradas, y ese número sigue creciendo.

Los profesionales de seguridad y los usuarios enfrentan un desafío directo: ¿cómo podemos verificar si una contraseña ha sido comprometida en una filtración de datos sin revelar la contraseña al servicio de verificación? La tarea suena simple, pero en realidad requiere un delicado equilibrio entre privacidad, seguridad y rendimiento.

Los enfoques tradicionales imponen un compromiso. Las búsquedas directas de hash son rápidas pero inseguras: exponen el hash completo, arriesgando filtraciones de contraseñas. Los protocolos criptográficos más sofisticados ofrecen fuertes garantías de privacidad, pero conllevan una sobrecarga computacional significativa y una complejidad de implementación que los hace poco prácticos para muchas aplicaciones del mundo real.

Presentamos una solución que cierra esta brecha: Verificación privada de filtraciones de contraseñas usando índices de filtros Bloom deterministas ofuscados. Este enfoque innovador proporciona fuertes garantías de privacidad mientras mantiene la eficiencia necesaria para el despliegue práctico en gestores de contraseñas, sistemas de autenticación e infraestructura de seguridad empresarial.

Soluciones existentes y sus compromisos

Para comprender la importancia de nuestro nuevo enfoque, es importante examinar los métodos actuales para la verificación de filtraciones de contraseñas y sus limitaciones inherentes.

Búsqueda directa de hash: Simple pero insegura

Los primeros servicios de verificación de filtraciones de contraseñas, como LeakedSource, empleaban un enfoque directo: los usuarios enviaban el hash SHA-1 de su contraseña, y el servicio verificaba si ese hash exacto aparecía en su base de datos de filtraciones. Aunque es simple de implementar y muy rápido de aplicar, este método es inseguro y propenso a ataques potenciales.

Cuando un usuario envía su hash de contraseña directamente, esencialmente está entregando una huella criptográfica de su contraseña al servicio. Esto crea varios vectores de ataque: actores maliciosos podrían realizar ataques de tablas rainbow contra el hash enviado, lanzar ataques de diccionario enfocados en ese hash específico, o correlacionar la misma contraseña en múltiples servicios. El problema fundamental es que el hash mismo se convierte en una pieza valiosa de información que puede ser explotada.

K-anonimato: Un paso adelante con vulnerabilidades restantes

Reconociendo los problemas de seguridad con el envío directo de hash, Troy Hunt introdujo el enfoque de k-anonimato para el servicio «Have I Been Pwned», que desde entonces ha sido adoptado por grandes empresas incluyendo Cloudflare y Microsoft. Este método representa una mejora significativa en la protección de la privacidad mientras mantiene características de rendimiento razonables.

En el enfoque de k-anonimato, en lugar de enviar el hash completo de la contraseña, el cliente calcula el hash SHA-1 de su contraseña y envía solo los primeros 5 caracteres hexadecimales (representando 20 bits) al servidor. El servidor entonces devuelve todos los hashes en su base de datos que comienzan con ese prefijo, típicamente entre 400 y 800 hashes. El cliente luego verifica localmente si su hash completo aparece en la lista devuelta.

Este enfoque ofrece varias ventajas: es simple de implementar, proporciona protección de privacidad razonable y utiliza el ancho de banda eficientemente. Sin embargo, análisis de seguridad recientes han revelado vulnerabilidades significativas. El método todavía filtra 20 bits de entropía sobre la contraseña, y la investigación ha demostrado que esta información parcial puede aumentar las tasas de éxito de descifrado de contraseñas en un orden de magnitud cuando los atacantes tienen acceso a los prefijos filtrados. El enfoque es particularmente vulnerable a ataques dirigidos contra cuentas de alto valor, donde incluso la información parcial puede ser valiosa para adversarios sofisticados.

Protocolos criptográficos: Fuerte privacidad a un alto costo

En el otro extremo del espectro, los protocolos criptográficos avanzados ofrecen garantías de privacidad robustas pero conllevan costos sustanciales de implementación y rendimiento. Dos enfoques principales han surgido en esta categoría: Funciones Pseudoaleatorias Oblivias (OPRF) e Intersección de Conjuntos Privados (PSI).

El enfoque OPRF, utilizado en el servicio Password Checkup de Google y el llavero de iCloud de Apple, emplea una danza criptográfica sofisticada. El cliente primero «ciega» el hash de su contraseña usando un valor aleatorio, creando una versión enmascarada que no revela nada sobre la contraseña original. El servidor luego aplica una función pseudoaleatoria a este valor cegado sin aprender nada sobre la contraseña subyacente. Finalmente, el cliente «desciega» el resultado y verifica si el valor final existe en un conjunto pre-descargado de identificadores filtrados.

Los protocolos de Intersección de Conjuntos Privados adoptan un enfoque diferente, utilizando técnicas criptográficas avanzadas como cifrado homomórfico o circuitos garbled. Estos protocolos permiten que un cliente aprenda la intersección de su conjunto de contraseñas y la base de datos de filtraciones del servidor sin que ninguna de las partes revele su conjunto completo a la otra.

Aunque estos enfoques criptográficos proporcionan excelentes garantías de privacidad sin filtración de información, vienen con inconvenientes significativos. Requieren implementaciones complejas que involucran criptografía de curva elíptica, imponen altos costos computacionales que pueden ser de 100 a 1000 veces más lentos que las operaciones de hash simples, y en algunos protocolos PSI, requieren un ancho de banda sustancial para grandes conjuntos de filtraciones. Estos factores los hacen poco prácticos para muchas aplicaciones del mundo real, particularmente aquellas que requieren validación de contraseñas en tiempo real o despliegue en dispositivos con recursos limitados.

Enfoques locales y sin conexión: Privacidad perfecta con limitaciones prácticas

Algunas organizaciones han optado por enfoques locales o sin conexión para lograr privacidad perfecta. Existen servicios como «Have I Been Pwned» que ofrecen listas de contraseñas descargables, permitiendo a las organizaciones descargar toda la base de datos de filtraciones (aproximadamente 25GB sin comprimir, 11GB comprimidos) y realizar búsquedas localmente. Las organizaciones también pueden construir filtros Bloom locales a partir de estos conjuntos de datos, reduciendo los requisitos de almacenamiento a alrededor de 860MB para 500 millones de contraseñas con una tasa de falsos positivos del 0,1%.

Aunque los enfoques locales proporcionan privacidad perfecta ya que no se requiere comunicación de red, presentan sus propios desafíos. Los requisitos de almacenamiento pueden ser prohibitivos, especialmente para aplicaciones móviles. Mantener la base de datos local sincronizada con nuevas filtraciones requiere actualizaciones regulares, y el enfoque es generalmente poco práctico para la mayoría de las aplicaciones de usuario final, particularmente en dispositivos móviles con capacidad de almacenamiento limitada.

Nuestra innovación: Índices de filtros Bloom deterministas ofuscados

Nuestro nuevo algoritmo representa un avance fundamental en la verificación de filtraciones de contraseñas al introducir un nuevo enfoque que combina la eficiencia de los filtros Bloom con técnicas de ofuscación sofisticadas. El resultado es un sistema que proporciona fuertes garantías de privacidad mientras mantiene las características de rendimiento necesarias para el despliegue en el mundo real.

Comprendiendo los filtros Bloom: La base

Para entender nuestro enfoque, es útil primero comprender el concepto de un filtro Bloom. Un filtro Bloom es una estructura de datos probabilística eficiente en espacio diseñada para probar si un elemento es miembro de un conjunto. Piense en él como una representación altamente comprimida de un gran conjunto de datos que puede responder rápidamente a la pregunta «¿Este elemento definitivamente no está en el conjunto?» o «Este elemento podría estar en el conjunto».

La belleza de los filtros Bloom radica en su eficiencia. En lugar de almacenar los hashes de contraseñas reales, un filtro Bloom representa la base de datos de filtraciones como un gran array de bits. Cuando un hash de contraseña se añade al filtro, se aplican múltiples funciones hash para generar varias posiciones de índice en el array de bits, y esas posiciones se establecen en 1. Para verificar si una contraseña podría estar comprometida, se aplican las mismas funciones hash para generar las mismas posiciones de índice, y si todas esas posiciones contienen 1, la contraseña podría estar en la base de datos de filtraciones.

La naturaleza probabilística de los filtros Bloom significa que pueden producir falsos positivos (indicando que una contraseña podría estar filtrada cuando en realidad no lo está) pero nunca falsos negativos (nunca pasarán por alto una contraseña que realmente está filtrada). Esta característica los hace perfectos para aplicaciones de seguridad donde es mejor errar por el lado de la precaución.

La innovación central: Ofuscación determinista

La idea clave detrás de nuestro algoritmo es que, aunque los filtros Bloom son eficientes, consultar directamente posiciones de bits específicas todavía revelaría información sobre la contraseña que se está verificando. Nuestra solución introduce un mecanismo de ofuscación sofisticado que oculta la consulta real entre ruido cuidadosamente elaborado.

El algoritmo opera sobre un principio simple pero poderoso: al verificar una contraseña, en lugar de solicitar solo las posiciones de bits que corresponden a esa contraseña, el cliente también solicita posiciones de «ruido» adicionales que se generan de manera determinista pero que parecen aleatorias para el servidor. Esto crea una situación donde el servidor no puede distinguir entre las posiciones de consulta reales y las falsas, ocultando efectivamente la contraseña que se está verificando.

Lo que hace este enfoque particularmente elegante es el uso de generación de ruido determinista. A diferencia del ruido aleatorio, que crearía diferentes patrones de consulta cada vez que se verifica la misma contraseña, nuestro enfoque determinista asegura que verificar la misma contraseña siempre genera el mismo conjunto de posiciones de ruido. Esta consistencia es crucial tanto por razones de seguridad como de eficiencia.

Cómo funciona el algoritmo: Un proceso de tres fases

Nuestro algoritmo opera a través de tres fases distintas, cada una diseñada para mantener la privacidad mientras asegura una operación eficiente.

Fase 1: Configuración del servidor
El servidor comienza tomando un conjunto completo de hashes de contraseñas comprometidas de filtraciones de datos conocidas. Estos hashes se utilizan luego para poblar un gran array de bits de filtro Bloom. Para cada hash de contraseña comprometida, se aplican múltiples funciones hash para generar varias posiciones de índice en el array de bits, y esas posiciones se marcan como 1. El resultado es una representación compacta de millones o miles de millones de contraseñas comprometidas que puede ser consultada eficientemente.

Fase 2: Generación de consulta del cliente
Cuando un cliente quiere verificar una contraseña, el proceso comienza calculando un hash criptográfico de la contraseña. El cliente luego genera dos conjuntos de índices: los «índices verdaderos» que corresponden a la contraseña que se está verificando, y los «índices de ruido» que sirven como señuelos.

Los índices verdaderos se generan aplicando las mismas funciones hash utilizadas por el servidor al hash de la contraseña. Estas son las posiciones en el filtro Bloom que necesitarían verificarse para determinar si la contraseña está comprometida.

Los índices de ruido se generan usando una función pseudoaleatoria con una clave secreta que solo el cliente conoce. Este secreto asegura que el ruido parezca aleatorio para el servidor pero sea determinista para el cliente. El número de índices de ruido se elige cuidadosamente para proporcionar fuertes garantías de privacidad mientras mantiene la eficiencia.

Una vez que ambos conjuntos de índices se generan, se combinan y mezclan de manera determinista pero impredecible. Esta mezcla asegura que el servidor no pueda distinguir entre índices reales y falsos basándose en su posición en la consulta.

Fase 3: Procesamiento de consulta y respuesta
El cliente envía el conjunto mezclado de índices al servidor, que responde con los valores de bit en cada posición solicitada. El servidor no tiene forma de determinar qué índices corresponden a la contraseña real que se está verificando y cuáles son ruido.

Al recibir la respuesta, el cliente examina solo los valores de bit correspondientes a los índices verdaderos. Si alguna de estas posiciones contiene un 0, la contraseña definitivamente no está comprometida. Si todas las posiciones de índices verdaderos contienen 1, la contraseña puede estar comprometida, aunque hay una pequeña posibilidad de un falso positivo debido a la naturaleza probabilística de los filtros Bloom.

El poder del ruido determinista

La naturaleza determinista de nuestra generación de ruido proporciona varias ventajas cruciales sobre enfoques alternativos. Cuando la misma contraseña se verifica múltiples veces, exactamente la misma consulta se envía al servidor cada vez. Esta consistencia previene ataques de correlación donde un adversario podría intentar identificar patrones a través de múltiples consultas para la misma contraseña.

En contraste, si se usara ruido aleatorio, consultas repetidas para la misma contraseña generarían diferentes patrones de ruido cada vez. Un adversario sofisticado podría potencialmente analizar múltiples consultas e identificar los elementos comunes, reduciendo gradualmente los índices verdaderos. Nuestro enfoque determinista elimina esta vulnerabilidad por completo.

El ruido determinista también proporciona beneficios de eficiencia computacional. Dado que la misma contraseña siempre genera la misma consulta, los clientes pueden almacenar resultados en caché, y el sistema puede optimizar para consultas repetidas sin comprometer la seguridad.

Beneficios clave: Cerrando la brecha entre privacidad y rendimiento

Nuestro algoritmo ofrece una combinación única de beneficios que abordan los desafíos fundamentales en la verificación de filtraciones de contraseñas, ofreciendo una solución práctica que no obliga a los usuarios a elegir entre privacidad y rendimiento.

Fuertes garantías de privacidad

El algoritmo proporciona protección de privacidad robusta a través de varios mecanismos. La ofuscación determinista asegura que las consultas para diferentes contraseñas sean computacionalmente indistinguibles para el servidor. Incluso con acceso a vastos recursos computacionales y conocimiento de contraseñas comunes, un servidor adversario no puede determinar qué contraseña se está verificando basándose únicamente en el patrón de consulta.

El sistema está específicamente diseñado para resistir ataques de correlación, donde un adversario intenta obtener información analizando múltiples consultas a lo largo del tiempo. Debido a que la misma contraseña siempre genera el mismo patrón de consulta, las verificaciones repetidas no proporcionan información adicional que pueda comprometer la privacidad. Esto contrasta marcadamente con sistemas que usan ruido aleatorio, donde múltiples consultas para la misma contraseña eventualmente revelarían el verdadero patrón de consulta.

Operando bajo un modelo de amenaza honesto-pero-curioso, el algoritmo asume que el servidor seguirá el protocolo pero puede intentar extraer información de las consultas observadas. Nuestro enfoque asegura que incluso un adversario sofisticado con acceso a bases de datos públicas de filtraciones y la capacidad de almacenar y analizar todas las consultas a lo largo del tiempo no pueda extraer información significativa sobre las contraseñas que se están verificando.

Características de rendimiento excepcionales

Uno de los aspectos más convincentes de nuestro algoritmo es su perfil de rendimiento. La evaluación experimental demuestra que el sistema logra tiempos de consulta inferiores al milisegundo, haciéndolo adecuado para escenarios de validación de contraseñas en tiempo real. Este rendimiento se logra a través de la naturaleza eficiente de las operaciones de filtros Bloom y el proceso de consulta optimizado.

La sobrecarga de ancho de banda es mínima, típicamente requiriendo menos de 1KB por consulta. Esta eficiencia hace que el algoritmo sea práctico para aplicaciones móviles y entornos con conectividad de red limitada. Los bajos requisitos de ancho de banda también reducen los costos del servidor y mejoran la escalabilidad para los proveedores de servicios.

La sobrecarga computacional tanto en el lado del cliente como del servidor es mínima. Los clientes solo necesitan realizar operaciones básicas de hash criptográfico y manipulaciones simples de bits. Los servidores pueden responder a consultas con búsquedas directas en arrays de bits. Esta simplicidad contrasta marcadamente con los protocolos criptográficos que requieren operaciones complejas de curvas elípticas o cálculos de cifrado homomórfico.

Escalabilidad y despliegue práctico

Construido para el despliegue en el mundo real, el algoritmo asegura que la infraestructura del lado del servidor pueda procesar eficientemente millones de consultas concurrentes mientras mantiene tiempos de respuesta consistentes. La representación del filtro Bloom permite el almacenamiento compacto de bases de datos masivas de filtraciones, haciéndolo económicamente viable para mantener servicios completos de verificación de filtraciones.

El sistema admite actualizaciones fáciles a medida que se descubren nuevas filtraciones. Las nuevas contraseñas comprometidas pueden añadirse al filtro Bloom sin requerir cambios en la implementación del lado del cliente o forzar a los usuarios a actualizar su software. Esta flexibilidad es crucial para mantener protección actualizada contra amenazas emergentes.

La resistencia robusta a ataques de denegación de servicio es otra ventaja. La naturaleza ligera del procesamiento de consultas significa que los servidores pueden manejar altos volúmenes de consultas sin un consumo significativo de recursos. Debido a que las consultas son deterministas, el almacenamiento en caché efectivo puede mejorar aún más el rendimiento y reducir la carga del servidor.

Compatibilidad e integración

Nuestro enfoque está diseñado para integrarse perfectamente con la infraestructura de seguridad existente. El algoritmo puede implementarse como un reemplazo directo para los mecanismos existentes de verificación de filtraciones de contraseñas sin requerir cambios significativos en las aplicaciones cliente. Los gestores de contraseñas, sistemas de autenticación y herramientas de seguridad empresarial pueden adoptar el algoritmo con modificaciones mínimas a sus bases de código existentes.

El sistema es compatible con varios modelos de despliegue, desde servicios basados en la nube hasta instalaciones en las propias instalaciones. Las organizaciones pueden elegir operar su propia infraestructura de verificación de filtraciones usando nuestro algoritmo mientras mantienen los mismos beneficios de privacidad y rendimiento.

El algoritmo también admite varias opciones de personalización para cumplir con requisitos de seguridad específicos. Las organizaciones pueden ajustar los niveles de ruido, parámetros del filtro Bloom y otras opciones de configuración para equilibrar la privacidad, el rendimiento y los requisitos de almacenamiento según sus necesidades específicas.

Aplicaciones en el mundo real: Transformando la seguridad de contraseñas

Los beneficios prácticos de nuestro algoritmo se traducen en mejoras significativas en una amplia gama de aplicaciones de seguridad y casos de uso. La combinación de fuertes garantías de privacidad y alto rendimiento abre nuevas posibilidades para la seguridad de contraseñas que anteriormente eran poco prácticas o imposibles.

Gestores de contraseñas: Seguridad mejorada sin compromisos

Los gestores de contraseñas representan una de las aplicaciones más convincentes para nuestro algoritmo. Estas herramientas son responsables de generar, almacenar y gestionar contraseñas para millones de usuarios, convirtiéndolas en un componente crítico de la seguridad digital moderna. Sin embargo, los gestores de contraseñas tradicionales han enfrentado desafíos para implementar una verificación completa de filtraciones debido a las limitaciones de privacidad y rendimiento.

Con nuestro algoritmo, los gestores de contraseñas ahora pueden ofrecer verificación de filtraciones en tiempo real para todas las contraseñas almacenadas sin comprometer la privacidad del usuario. Cuando los usuarios guardan una nueva contraseña o durante auditorías de seguridad periódicas, el gestor de contraseñas puede verificar instantáneamente si la contraseña ha aparecido en filtraciones de datos conocidas. Esta capacidad permite a los gestores de contraseñas proporcionar retroalimentación inmediata a los usuarios, animándoles a cambiar las contraseñas comprometidas antes de que puedan ser explotadas.

Los bajos requisitos de latencia y ancho de banda mínimo hacen práctico verificar contraseñas en tiempo real mientras los usuarios las escriben durante la creación de contraseñas. Esta retroalimentación inmediata puede guiar a los usuarios hacia contraseñas más fuertes y no comprometidas sin crear fricción en la experiencia del usuario. Las garantías de privacidad aseguran que incluso el proveedor del servicio de gestión de contraseñas no pueda conocer las contraseñas específicas que se están verificando, manteniendo la confianza que es esencial para estas herramientas de seguridad.

Sistemas de autenticación: Medidas de seguridad proactivas

Los sistemas de autenticación modernos pueden aprovechar nuestro algoritmo para implementar medidas de seguridad proactivas que protejan a los usuarios de ataques basados en credenciales. Durante los intentos de inicio de sesión, los sistemas de autenticación pueden verificar las contraseñas enviadas contra bases de datos de filtraciones en tiempo real, identificando credenciales potencialmente comprometidas antes de que puedan ser utilizadas maliciosamente.

Esta capacidad permite a los sistemas de autenticación implementar políticas de seguridad adaptativas. Por ejemplo, si un usuario intenta iniciar sesión con una contraseña que se ha encontrado en una filtración de datos, el sistema puede requerir factores de autenticación adicionales, solicitar un cambio de contraseña o restringir temporalmente el acceso a la cuenta hasta que el usuario actualice sus credenciales. Estas medidas pueden reducir significativamente la tasa de éxito de los ataques de credential stuffing y otras amenazas basadas en contraseñas.

Las características de rendimiento del algoritmo lo hacen adecuado para escenarios de autenticación de alto volumen, como sistemas de inicio de sesión empresariales o servicios web de consumo con millones de usuarios. Los tiempos de consulta inferiores al milisegundo aseguran que la verificación de filtraciones no introduzca retrasos perceptibles en el proceso de autenticación, manteniendo una experiencia de usuario fluida mientras mejora la seguridad.

Infraestructura de seguridad empresarial: Protección integral

Las grandes organizaciones enfrentan desafíos únicos en la seguridad de contraseñas debido a la escala y complejidad de sus entornos de TI. Nuestro algoritmo proporciona a los equipos de seguridad empresarial herramientas poderosas para implementar políticas integrales de seguridad de contraseñas en toda su organización.

Los sistemas de seguridad empresarial pueden usar el algoritmo para monitorear continuamente las contraseñas de los empleados contra bases de datos de filtraciones, identificando credenciales comprometidas antes de que puedan ser explotadas por atacantes. Este monitoreo puede integrarse con sistemas existentes de gestión de identidades y accesos, activando automáticamente requisitos de restablecimiento de contraseñas cuando se detectan credenciales comprometidas.

El algoritmo también apoya los requisitos de cumplimiento al proporcionar a las organizaciones la capacidad de demostrar que están monitoreando activamente las credenciales comprometidas. Muchos marcos regulatorios y estándares de seguridad requieren que las organizaciones implementen medidas para detectar y responder al compromiso de credenciales, y nuestro algoritmo proporciona una solución práctica que preserva la privacidad para cumplir con estos requisitos. Para organizaciones con estrictos requisitos de privacidad de datos, las garantías de privacidad del algoritmo aseguran que la información sensible de contraseñas nunca salga del control de la organización. Esta capacidad es particularmente importante para organizaciones en industrias reguladas o aquellas que manejan información personal sensible.

Aplicaciones de consumo: Democratizando la seguridad

La eficiencia y simplicidad de nuestro algoritmo lo hacen práctico de implementar en aplicaciones de consumo que anteriormente no podían permitirse la sobrecarga de una verificación completa de filtraciones. Las aplicaciones móviles, navegadores web y otro software de consumo ahora pueden ofrecer características de seguridad de contraseñas de nivel empresarial sin requerir recursos computacionales significativos o implementaciones criptográficas complejas.

Los navegadores web pueden integrar el algoritmo para proporcionar retroalimentación en tiempo real cuando los usuarios crean o actualizan contraseñas en sitios web. Esta integración puede ayudar a los usuarios a evitar reutilizar contraseñas comprometidas en múltiples sitios, reduciendo su exposición a ataques de credential stuffing. Los bajos requisitos de ancho de banda hacen esto práctico incluso en redes móviles con conectividad limitada.

Las aplicaciones de consumo también pueden usar el algoritmo para implementar paneles de seguridad que ayuden a los usuarios a comprender y mejorar su postura general de seguridad de contraseñas. Al verificar todas las contraseñas de un usuario contra bases de datos de filtraciones, estas aplicaciones pueden proporcionar recomendaciones personalizadas para mejorar la seguridad sin comprometer la privacidad de las contraseñas individuales.

Proveedores de servicios: Habilitando servicios de seguridad que preservan la privacidad

Nuestro algoritmo crea nuevas oportunidades para que los proveedores de servicios ofrezcan servicios de seguridad que preservan la privacidad. Las empresas pueden construir servicios de verificación de filtraciones que proporcionen fuertes garantías de privacidad a sus clientes, habilitando nuevos modelos de negocio y ofertas de servicios que anteriormente eran poco prácticos debido a preocupaciones de privacidad.

La eficiencia del algoritmo lo hace económicamente viable para operar servicios de verificación de filtraciones a gran escala. Los bajos requisitos computacionales y de ancho de banda reducen los costos operativos, haciendo posible ofrecer estos servicios a escala mientras se mantienen precios razonables. La capacidad de manejar altos volúmenes de consultas también permite a los proveedores de servicios atender a grandes bases de clientes sin inversiones significativas en infraestructura.

Los proveedores de servicios también pueden ofrecer el algoritmo como componente de plataformas de seguridad más amplias, integrando la verificación de filtraciones con otros servicios de seguridad como inteligencia de amenazas, gestión de vulnerabilidades y monitoreo de seguridad. Esta integración puede proporcionar a los clientes soluciones de seguridad integrales que aborden múltiples aspectos de la ciberseguridad mientras mantienen fuertes protecciones de privacidad.

Conclusión: Una nueva era en la seguridad de contraseñas

La introducción de nuestro algoritmo de verificación privada de filtraciones de contraseñas usando índices de filtros Bloom deterministas ofuscados representa un avance significativo en el campo de la seguridad de contraseñas. Al cerrar exitosamente la brecha entre privacidad y rendimiento, hemos creado una solución que hace práctica la verificación completa de filtraciones de contraseñas para una amplia gama de aplicaciones y casos de uso.

Las innovaciones clave del algoritmo — generación de ruido determinista, operaciones eficientes de filtros Bloom y técnicas de ofuscación sofisticadas — se combinan para ofrecer un sistema que proporciona fuertes garantías de privacidad mientras mantiene las características de rendimiento necesarias para el despliegue en el mundo real. Con tiempos de consulta inferiores al milisegundo y una sobrecarga de ancho de banda mínima, el algoritmo hace posible implementar verificación de filtraciones de contraseñas en tiempo real en aplicaciones que van desde gestores de contraseñas de consumo hasta sistemas de autenticación empresarial.

Las garantías de privacidad proporcionadas por nuestro algoritmo son particularmente significativas en el entorno regulatorio actual, donde la protección de datos y la privacidad del usuario son consideraciones cada vez más importantes. Al asegurar que la información de contraseñas nunca necesite ser revelada a los servicios de verificación, nuestro algoritmo permite a las organizaciones implementar medidas de seguridad integrales mientras mantienen el cumplimiento con las regulaciones de privacidad y las expectativas de los usuarios.

El impacto práctico de esta tecnología se extiende mucho más allá de las mejoras técnicas. Al hacer accesible y eficiente la verificación de filtraciones de contraseñas que preserva la privacidad, estamos habilitando una nueva generación de herramientas y servicios de seguridad que pueden proteger mejor a los usuarios de la creciente amenaza de ataques basados en credenciales. La compatibilidad del algoritmo con la infraestructura existente y la facilidad de implementación significan que estos beneficios pueden realizarse rápida y ampliamente en todo el ecosistema de seguridad.

A medida que las amenazas cibernéticas continúan evolucionando y las filtraciones de datos se vuelven cada vez más comunes, la necesidad de medidas efectivas de seguridad de contraseñas solo crecerá. Nuestro algoritmo proporciona una base para construir sistemas más seguros que preservan la privacidad y que pueden adaptarse para enfrentar estos desafíos mientras mantienen la usabilidad y el rendimiento que los usuarios esperan.

El desarrollo de este algoritmo representa solo el comienzo de nuestro trabajo en tecnologías de seguridad que preservan la privacidad. Estamos comprometidos a continuar la investigación y el desarrollo en esta área, explorando nuevas aplicaciones y mejoras que puedan mejorar aún más la seguridad y privacidad de los sistemas digitales.

Creemos que el futuro de la ciberseguridad radica en soluciones que no obliguen a los usuarios a elegir entre seguridad y privacidad. Nuestro algoritmo de verificación privada de filtraciones de contraseñas demuestra que es posible lograr ambos objetivos simultáneamente, proporcionando un modelo para futuras innovaciones en tecnología de seguridad.

Para organizaciones y desarrolladores interesados en implementar esta tecnología, les animamos a explorar las especificaciones técnicas detalladas y la guía de implementación proporcionada en nuestro documento de investigación completo. El documento incluye análisis de seguridad formal, recomendaciones de implementación detalladas y evaluaciones de rendimiento integrales que proporcionan la base para el despliegue exitoso de este algoritmo en entornos de producción.

Passwork 7.1: Tipos de bóvedas

Tipos de bóvedas Passwork 7.1 introduce una arquitectura robusta de tipos de bóvedas, proporcionando control de acceso de nivel empresarial para una seguridad y gestión mejoradas. Los tipos de bóvedas abordan un desafío clave para los administradores: controlar el acceso a los datos y delegar la gestión de bóvedas en grandes organizaciones. Anteriormente, la elección estaba limitada a dos tipos. Ahora, puede crear

Passwork BlogEirik Salmi

Lanzamiento de la extensión de navegador 2.0.26

Versión 2.0.27 * Protección contra clickjacking mejorada: se añadió el bloqueo de clics en elementos ocultos y verificación de superposición de elementos y transformaciones CSS * Se corrigió un problema al seguir un enlace desde una notificación a una bóveda o contraseña eliminada * Se corrigió un problema que podía causar que la extensión cerrara sesión

Passwork BlogEirik Salmi

Conector Python 0.1.5: Gestión automatizada de secretos

La nueva versión del conector Python 0.1.5 amplía las capacidades de la utilidad CLI. Hemos añadido comandos que resuelven tareas críticas para ingenieros DevOps y desarrolladores — recuperación y actualización segura de secretos en pipelines automatizados. Qué resuelve Los secretos hardcodeados, claves API, tokens y credenciales de bases de datos crean vulnerabilidades de seguridad y cuellos de botella operativos.

Passwork BlogEirik Salmi

Introduction

Data breaches have become routine: millions of users worldwide face the consequences of compromised passwords. The scale is staggering: billions of credentials are exposed, fueling automated attacks and credential stuffing on a massive scale. Services like "Have I Been Pwned" now track over 12 billion breached accounts, and that number keeps growing.

Security professionals and users face a direct challenge: how can we check if a password has been compromised in a data breach without revealing the password itself to the checking service? The task sounds simple, but in reality, it requires a delicate balance between privacy, security, and performance.

Traditional approaches force a trade-off. Direct hash lookups are fast but unsafe: they expose the full hash, risking password leaks. More sophisticated cryptographic protocols offer strong privacy guarantees but come with significant computational overhead and implementation complexity that makes them impractical for many real-world applications.

We’re introducing a solution that bridges this gap: Private password breach checking using obfuscated deterministic bloom filter indices. This innovative approach provides strong privacy guarantees while maintaining the efficiency needed for practical deployment in password managers, authentication systems, and enterprise security infrastructure.

Existing solutions and their tradeoffs

To understand the significance of our new approach, it's important to examine the current methods for password breach checking and their inherent limitations.

Direct hash lookup: Simple but insecure

The earliest password breach checking services, such as LeakedSource, employed a straightforward approach: users would submit the SHA-1 hash of their password, and the service would check if that exact hash appeared in their breach database. Although simple to deploy and very fast to apply, this method is insecure and prone to potential attacks.

When a user submits their password hash directly, they're essentially handing over a cryptographic fingerprint of their password to the service. This creates several attack vectors: malicious actors could perform rainbow table attacks against the submitted hash, launch focused dictionary attacks targeting that specific hash, or correlate the same password across multiple services. The fundamental problem is that the hash itself becomes a valuable piece of information that can be exploited.

K-anonymity: A step forward with remaining vulnerabilities

Recognizing the security issues with direct hash submission, Troy Hunt introduced the k-anonymity approach for the "Have I Been Pwned" service, which has since been adopted by major companies including Cloudflare and Microsoft. This method represents a significant improvement in privacy protection while maintaining reasonable performance characteristics.

In the k-anonymity approach, instead of sending the full password hash, the client computes the SHA-1 hash of their password and sends only the first 5 hexadecimal characters (representing 20 bits) to the server. The server then returns all hashes in its database that begin with that prefix, typically between 400 and 800 hashes. The client then checks locally whether their full hash appears in the returned list.

This approach offers several advantages: it's simple to implement, provides reasonable privacy protection, and uses bandwidth efficiently. However, recent security analysis has revealed significant vulnerabilities. The method still leaks 20 bits of entropy about the password, and research has demonstrated that this partial information can increase password cracking success rates by an order of magnitude when attackers have access to the leaked prefixes. The approach is particularly vulnerable to targeted attacks against highvalue accounts, where even partial information can be valuable to sophisticated adversaries.

Cryptographic protocols: Strong privacy at a high cost

At the other end of the spectrum, advanced cryptographic protocols offer robust privacy guarantees but come with substantial implementation and performance costs. Two primary approaches have emerged in this category: Oblivious Pseudorandom Functions (OPRF) and Private Set Intersection (PSI).

The OPRF approach, used in Google's Password Checkup service and Apple's iCloud Keychain, employs a sophisticated cryptographic dance. The client first "blinds" its password hash using a random value, creating a masked version that reveals nothing about the original password. The server then applies a pseudorandom function to this blinded value without learning anything about the underlying password. Finally, the client "unblinds" the result and checks if the final value exists in a pre-downloaded set of breached identifiers.

Private Set Intersection protocols take a different approach, using advanced cryptographic techniques like homomorphic encryption or garbled circuits. These protocols allow a client to learn the intersection of its password set and the server's breach database without either party revealing their complete set to the other.

While these cryptographic approaches provide excellent privacy guarantees with no information leakage, they come with significant drawbacks. They require complex implementations involving elliptic curve cryptography, impose high computational costs that can be 100 to 1000 times slower than simple hash operations, and in some PSI protocols, require substantial bandwidth for large breach sets. These factors make them impractical for many real-world applications, particularly those requiring real-time password validation or deployment on resource-constrained devices.

Local and offline approaches: Perfect privacy with practical limitations

Some organizations have opted for local or offline approaches to achieve perfect privacy. There are services like "Have I Been Pwned" that offer downloadable password lists, allowing organizations to download the entire breach database (approximately 25GB uncompressed, 11GB compressed) and perform searches locally. Organizations can also build local Bloom filters from these datasets, reducing storage requirements to around 860MB for 500 million passwords with a 0.1% false positive rate.

While local approaches provide perfect privacy since no network communication is required, they present their own challenges. Storage requirements can be prohibitive, especially for mobile applications. Keeping the local database synchronized with new breaches requires regular updates, and the approach is generally impractical for most enduser applications, particularly on mobile devices with limited storage capacity.

Our innovation: Obfuscated deterministic bloom filter indices

Our new algorithm represents a fundamental breakthrough in password breach checking by introducing a new approach that combines the efficiency of Bloom filters with sophisticated obfuscation techniques. The result is a system that provides strong privacy guarantees while maintaining the performance characteristics needed for real-world deployment.

Understanding bloom filters: The foundation

To understand our approach, it's helpful to first grasp the concept of a Bloom filter. A Bloom filter is a space-efficient probabilistic data structure designed to test whether an element is a member of a set. Think of it as a highly compressed representation of a large dataset that can quickly answer the question "Is this item definitely not in the set?" or "This item might be in the set."

The beauty of Bloom filters lies in their efficiency. Instead of storing the actual password hashes, a Bloom filter represents the breach database as a large array of bits. When a password hash is added to the filter, multiple hash functions are applied to generate several index positions in the bit array, and those positions are set to 1. To check if a password might be compromised, the same hash functions are applied to generate the same index positions, and if all those positions contain 1, the password might be in the breach database.

The probabilistic nature of Bloom filters means they can produce false positives (indicating a password might be breached when it actually isn't) but never false negatives (they will never miss a password that is actually breached). This characteristic makes them perfect for security applications where it's better to err on the side of caution.

The core innovation: Deterministic obfuscation

The key insight behind our algorithm is that while Bloom filters are efficient, directly querying specific bit positions would still reveal information about the password being checked. Our solution introduces a sophisticated obfuscation mechanism that hides the real query among carefully crafted noise.

The algorithm operates on a simple but powerful principle: when checking a password, instead of requesting only the bit positions that correspond to that password, the client also requests additional "noise" positions that are generated deterministically but appear random to the server. This creates a situation where the server cannot distinguish between the real query positions and the fake ones, effectively hiding the password being checked.

What makes this approach particularly elegant is the use of deterministic noise generation. Unlike random noise, which would create different query patterns each time the same password is checked, our deterministic approach ensures that checking the same password always generates the same set of noise positions. This consistency is crucial for both security and efficiency reasons.

How the algorithm works: A three-phase process

Our algorithm operates through three distinct phases, each designed to maintain privacy while ensuring efficient operation.

Phase 1: Server setup
The server begins by taking a comprehensive set of compromised password hashes from known data breaches. These hashes are then used to populate a large Bloom filter bit array. For each compromised password hash, multiple hash functions are applied to generate several index positions in the bit array, and those positions are marked as 1. The result is a compact representation of millions or billions of compromised passwords that can be queried efficiently.

Phase 2: Client query generation
When a client wants to check a password, the process begins by computing a cryptographic hash of the password. The client then generates two sets of indices: the "true indices" that correspond to the password being checked, and "noise indices" that serve as decoys.

The true indices are generated by applying the same hash functions used by the server to the password hash. These are the positions in the Bloom filter that would need to be checked to determine if the password is compromised.

The noise indices are generated using a pseudorandom function keyed with a secret that only the client knows. This secret ensures that the noise appears random to the server but is deterministic for the client. The number of noise indices is carefully chosen to provide strong privacy guarantees while maintaining efficiency.

Once both sets of indices are generated, they are combined and shuffled in a deterministic but unpredictable manner. This shuffling ensures that the server cannot distinguish between real and fake indices based on their position in the query.

Phase 3: Query processing and response
The client sends the shuffled set of indices to the server, which responds with the bit values at each requested position. The server has no way to determine which indices correspond to the actual password being checked and which are noise.

Upon receiving the response, the client examines only the bit values corresponding to the true indices. If any of these positions contains a 0, the password is definitively not compromised. If all true index positions contain 1, the password may be compromised, though there's a small possibility of a false positive due to the probabilistic nature of Bloom filters.

The power of deterministic noise

The deterministic nature of our noise generation provides several crucial advantages over alternative approaches. When the same password is checked multiple times, the exact same query is sent to the server each time. This consistency prevents correlation attacks where an adversary might try to identify patterns across multiple queries for the same password.

In contrast, if random noise were used, repeated queries for the same password would generate different noise patterns each time. A sophisticated adversary could potentially analyze multiple queries and identify the common elements, gradually narrowing down the true indices. Our deterministic approach eliminates this vulnerability entirely.

The deterministic noise also provides computational efficiency benefits. Since the same password always generates the same query, clients can cache results, and the system can optimize for repeated queries without compromising security.

Key benefits: Bridging the privacy-performance gap

Our algorithm delivers a unique combination of benefits that address the fundamental challenges in password breach checking, offering a practical solution that doesn't force users to choose between privacy and performance.

Strong privacy guarantees

The algorithm provides robust privacy protection through several mechanisms. The deterministic obfuscation ensures that queries for different passwords are computationally indistinguishable to the server. Even with access to vast computational resources and knowledge of common passwords, an adversarial server cannot determine which password is being checked based solely on the query pattern.

The system is specifically designed to resist correlation attacks, where an adversary attempts to learn information by analyzing multiple queries over time. Because the same password always generates the same query pattern, repeated checks don't provide additional information that could compromise privacy. This stands in stark contrast to systems using random noise, where multiple queries for the same password would eventually reveal the true query pattern.

Operating under an honest-but-curious threat model, the algorithm assumes the server will follow the protocol yet may attempt to extract information from observed queries. Our approach ensures that even a sophisticated adversary with access to public breach databases and the ability to store and analyze all queries over time cannot extract meaningful information about the passwords being checked.

Exceptional performance characteristics

One of the most compelling aspects of our algorithm is its performance profile. Experimental evaluation demonstrates that the system achieves sub-millisecond query times, making it suitable for real-time password validation scenarios. This performance is achieved through the efficient nature of Bloom filter operations and the streamlined query process.

The bandwidth overhead is minimal, typically requiring less than 1KB per query. This efficiency makes the algorithm practical for mobile applications and environments with limited network connectivity. The low bandwidth requirements also reduce server costs and improve scalability for service providers.

The computational overhead on both client and server sides is minimal. Clients need only perform basic cryptographic hash operations and simple bit manipulations. Servers can respond to queries with straightforward bit array lookups. This simplicity stands in stark contrast to cryptographic protocols that require complex elliptic curve operations or homomorphic encryption computations.

Scalability and practical deployment

Built for real-world deployment, the algorithm ensures that server-side infrastructure can efficiently process millions of concurrent queries while keeping response times consistent. The Bloom filter representation allows for compact storage of massive breach databases, making it economically feasible to maintain comprehensive breach checking services.

The system supports easy updates as new breaches are discovered. New compromised passwords can be added to the Bloom filter without requiring changes to the client-side implementation or forcing users to update their software. This flexibility is crucial for maintaining up-to-date protection against emerging threats.

Robust resistance to denial-of-service attacks is another advantage. The lightweight nature of query processing means that servers can handle high query volumes without significant resource consumption. Because queries are deterministic, effective caching can further boost performance and reduce server load.

Compatibility and integration

Our approach is designed to integrate seamlessly with existing security infrastructure. The algorithm can be implemented as a drop-in replacement for existing password breach checking mechanisms without requiring significant changes to client applications. Password managers, authentication systems, and enterprise security tools can adopt the algorithm with minimal modification to their existing codebases.

The system is compatible with various deployment models, from cloud-based services to on-premises installations. Organizations can choose to operate their own breach checking infrastructure using our algorithm while maintaining the same privacy and performance benefits.

The algorithm also supports various customization options to meet specific security requirements. Organizations can adjust the noise levels, Bloom filter parameters, and other configuration options to balance privacy, performance, and storage requirements according to their specific needs.

Real-world applications: Transforming password security

The practical benefits of our algorithm translate into significant improvements across a wide range of security applications and use cases. The combination of strong privacy guarantees and high performance opens up new possibilities for password security that were previously impractical or impossible.

Password managers: Enhanced security without compromise

Password managers represent one of the most compelling applications for our algorithm. These tools are responsible for generating, storing, and managing passwords for millions of users, making them a critical component of modern digital security. However, traditional password managers have faced challenges in implementing comprehensive breach checking due to privacy and performance constraints.

With our algorithm, password managers can now offer real-time breach checking for all stored passwords without compromising user privacy. When users save a new password or during periodic security audits, the password manager can instantly verify whether the password has appeared in known data breaches. This capability enables password managers to provide immediate feedback to users, encouraging them to change compromised passwords before they can be exploited.

The low latency and minimal bandwidth requirements make it practical to check passwords in real-time as users type them during password creation. This immediate feedback can guide users toward stronger, uncompromised passwords without creating friction in the user experience. The privacy guarantees ensure that even the password manager service provider cannot learn about the specific passwords being checked, maintaining the trust that is essential for these security tools.

Authentication systems: Proactive security measures

Modern authentication systems can leverage our algorithm to implement proactive security measures that protect users from credential-based attacks. During login attempts, authentication systems can check submitted passwords against breach databases in real time, identifying potentially compromised credentials before they can be used maliciously.

This capability enables authentication systems to implement adaptive security policies. For example, if a user attempts to log in with a password that has been found in a data breach, the system can require additional authentication factors, prompt for a password change, or temporarily restrict account access until the user updates their credentials. These measures can significantly reduce the success rate of credential stuffing attacks and other password-based threats.

The algorithm's performance characteristics make it suitable for high-volume authentication scenarios, such as enterprise login systems or consumer web services with millions of users. The sub-millisecond query times ensure that breach checking doesn't introduce noticeable delays in the authentication process, maintaining a smooth user experience while enhancing security.

Enterprise security infrastructure: Comprehensive protection

Large organizations face unique challenges in password security due to the scale and complexity of their IT environments. Our algorithm provides enterprise security teams with powerful tools for implementing comprehensive password security policies across their organizations.

Enterprise security systems can use the algorithm to continuously monitor employee passwords against breach databases, identifying compromised credentials before they can be exploited by attackers. This monitoring can be integrated with existing identity and access management systems, automatically triggering password reset requirements when compromised credentials are detected.

The algorithm also supports compliance requirements by providing organizations with the ability to demonstrate that they are actively monitoring for compromised credentials. Many regulatory frameworks and security standards require organizations to implement measures for detecting and responding to credential compromise, and our algorithm provides a practical, privacy-preserving solution for meeting these requirements. For organizations with strict data privacy requirements, the algorithm's privacy guarantees ensure that sensitive password information never leaves the organization's control. This capability is particularly important for organizations in regulated industries or those handling sensitive personal information.

Consumer applications: Democratizing security

The efficiency and simplicity of our algorithm make it practical to implement in consumer applications that previously couldn't afford the overhead of comprehensive breach checking. Mobile applications, web browsers, and other consumer software can now offer enterprise-grade password security features without requiring significant computational resources or complex cryptographic implementations.

Web browsers can integrate the algorithm to provide real-time feedback when users create or update passwords on websites. This integration can help users avoid reusing compromised passwords across multiple sites, reducing their exposure to credential stuffing attacks. The low bandwidth requirements make this practical even on mobile networks with limited connectivity.

Consumer applications can also use the algorithm to implement security dashboards that help users understand and improve their overall password security posture. By checking all of a user's passwords against breach databases, these applications can provide personalized recommendations for improving security without compromising the privacy of individual passwords.

Service providers: Enabling privacy-preserving security services

Our algorithm creates new opportunities for service providers to offer privacy-preserving security services. Companies can build breach checking services that provide strong privacy guarantees to their customers, enabling new business models and service offerings that were previously impractical due to privacy concerns.

The algorithm's efficiency makes it economically viable to operate large-scale breach checking services. The low computational and bandwidth requirements reduce operational costs, making it possible to offer these services at scale while maintaining reasonable pricing. The ability to handle high query volumes also enables service providers to serve large customer bases without significant infrastructure investments.

Service providers can also offer the algorithm as a component of broader security platforms, integrating breach checking with other security services such as threat intelligence, vulnerability management, and security monitoring. This integration can provide customers with comprehensive security solutions that address multiple aspects of cybersecurity while maintaining strong privacy protections.

Conclusion: A new era in password security

The introduction of our Private password breach checking algorithm using obfuscated deterministic bloom filter indices represents a significant advancement in the field of password security. By successfully bridging the gap between privacy and performance, we have created a solution that makes comprehensive password breach checking practical for a wide range of applications and use cases.

The algorithm's key innovations — deterministic noise generation, efficient Bloom filter operations, and sophisticated obfuscation techniques — combine to deliver a system that provides strong privacy guarantees while maintaining the performance characteristics needed for real-world deployment. With sub-millisecond query times and minimal bandwidth overhead, the algorithm makes it possible to implement real-time password breach checking in applications ranging from consumer password managers to enterprise authentication systems.

The privacy guarantees provided by our algorithm are particularly significant in today's regulatory environment, where data protection and user privacy are increasingly important considerations. By ensuring that password information never needs to be revealed to checking services, our algorithm enables organizations to implement comprehensive security measures while maintaining compliance with privacy regulations and user expectations.

The practical impact of this technology extends far beyond technical improvements. By making privacy-preserving password breach checking accessible and efficient, we are enabling a new generation of security tools and services that can better protect users from the growing threat of credential-based attacks. The algorithm's compatibility with existing infrastructure and ease of implementation mean that these benefits can be realized quickly and broadly across the security ecosystem.

As cyber threats continue to evolve and data breaches become increasingly common, the need for effective password security measures will only grow. Our algorithm provides a foundation for building more secure, privacy-preserving systems that can adapt to meet these challenges while maintaining the usability and performance that users expect.

The development of this algorithm represents just the beginning of our work in privacy-preserving security technologies. We are committed to continuing research and development in this area, exploring new applications and improvements that can further enhance the security and privacy of digital systems.

We believe that the future of cybersecurity lies in solutions that don't force users to choose between security and privacy. Our Private password breach checking algorithm demonstrates that it is possible to achieve both goals simultaneously, providing a model for future innovations in security technology.

For organizations and developers interested in implementing this technology, we encourage you to explore the detailed technical specifications and implementation guidance provided in our comprehensive research paper. The paper includes formal security analysis, detailed implementation recommendations, and comprehensive performance evaluations that provide the foundation for successful deployment of this algorithm in production environments.

Passwork 7.1: Vault types

Vault types Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a key challenge for administrators: controlling data access and delegating vault management across large organizations. Previously, the choice was limited to two types. Now, you can create

Passwork BlogEirik Salmi

Browser extension 2.0.26 release

Version 2.0.27 * Further improved clickjacking protection: added blocking of clicks on hidden elements and checking for element overlap and CSS transformations * Fixed an issue when following a link from a notification to a deleted vault or password * Fixed an issue that could cause the extension to log out

Passwork BlogEirik Salmi

Python connector 0.1.5: Automated secrets management

The new Python connector version 0.1.5 expands CLI utility capabilities. We’ve added commands that solve critical tasks for DevOps engineers and developers — secure retrieval and updating of secrets in automated pipelines. What this solves Hardcoded secrets, API keys, tokens, and database credentials create security vulnerabilities and operational bottlenecks.

Passwork BlogEirik Salmi

Symmetric encryption is the workhorse of modern data security. AES-256 protects everything from database records to TLS sessions, and it does so faster than any alternative at scale. The cipher itself is not the problem. The problem is the key — who holds it, how it's stored, and what happens when it's stolen. Understanding both sides of that equation is what separates a sound encryption strategy from a false sense of security.

What is symmetric encryption?

Symmetric encryption uses a single shared key to both encrypt and decrypt data. The sender and receiver must possess the same key. If either party loses it or an attacker obtains it, the protection collapses entirely. This contrasts with asymmetric encryption (public-key cryptography), where a public key encrypts data and a mathematically linked private key decrypts it.

The distinction matters in practice. Symmetric algorithms are fast and computationally cheap, making them the right tool for bulk data encryption. Asymmetric algorithms are slower but solve a problem symmetric encryption cannot: securely exchanging a key over an untrusted channel. Modern systems use both, and understanding when to use which (and how to combine them) is the core of practical cryptographic architecture.

The pros of symmetric algorithms

Symmetric encryption offers three concrete advantages that explain why it remains the dominant choice for protecting data at rest and in transit.

Unmatched speed and efficiency

Symmetric algorithms process data faster and at lower computational cost than asymmetric alternatives. A single shared key eliminates the need for complex operations like prime factorization or modular arithmetic, which means less CPU overhead and lower latency. That efficiency scales well: secure communication channels, VPNs, cloud storage, and real-time data transfers all benefit from ciphers that can sustain high throughput without taxing the underlying hardware.

Asymmetric operations, by comparison, involve computationally expensive modular exponentiation or elliptic curve math. RSA-2048 encryption is roughly 1,000 times slower than AES-256 for equivalent data volumes. This is why TLS 1.3 uses asymmetric cryptography only for the handshake — to exchange a session key — then switches immediately to AES for the actual data transfer.

Ideal for large-scale data encryption at rest

Symmetric encryption is the default choice for protecting stored data at scale. Encrypting a multi-terabyte database with an asymmetric algorithm is not practical — the computational cost makes it a non-starter. AES-256-GCM handles the same job routinely, which is why every major cloud provider uses it as the default for storage volumes, database snapshots, and object storage.

Once both parties share a key through a secure initial exchange, symmetric encryption requires no further cryptographic overhead per session. There is no per-message public-key operation, no certificate validation, no asymmetric handshake on every connection. For large organizations where many parties need to communicate securely, this reduces operational complexity significantly — the hard part is the initial key exchange, not the ongoing communication.

Computational simplicity

Symmetric algorithms are straightforward to implement correctly, which matters as much as raw performance. Without complex mathematical operations underlying the design, they run efficiently on resource-constrained hardware — embedded systems, IoT devices, and microcontrollers where CPU cycles and memory are tight. That simplicity also makes implementations easier to audit and maintain, reducing the surface area for the kind of subtle coding errors that quietly undermine security.

Quantum resistance

Quantum computing threatens asymmetric cryptography far more than symmetric. Shor's algorithm, running on a sufficiently powerful quantum computer, can break RSA and elliptic curve cryptography by solving the underlying mathematical problems efficiently. This is why NIST's Post-Quantum Cryptography (PQC) standardization effort, finalized in 2024, focuses almost entirely on replacing asymmetric algorithms.

Symmetric encryption faces a different and more manageable threat. Grover's algorithm can theoretically search an unsorted key space in the square root of the time a classical computer requires. Applied to AES-256, this halves the effective key length — from 256 bits to 128 bits of security. AES-128 bits of security remains computationally unbreakable by any known or projected hardware. AES-128 would be more concerning; AES-256 is not.

The 2025 Thales Data Threat Report found that 62% of critical infrastructure organizations are concerned about future encryption compromise, and 60% specifically worry about the "Harvest Now, Decrypt Later" (HNDL) threat — where adversaries exfiltrate encrypted data today to decrypt it once quantum hardware matures. For data protected with AES-256, HNDL is a much lower risk than for data protected with RSA or ECDH. Organizations using symmetric encryption for long-lived sensitive data are in a stronger position than those relying on asymmetric-only approaches.

The cons of symmetric algorithms

The cipher is sound. The operational challenges around it are not.

The key distribution problem

Two parties who have never communicated cannot securely share a symmetric key over an untrusted channel without help from a third mechanism. This is the key distribution problem, and it is the fundamental limitation of symmetric cryptography.

If you encrypt a file with AES-256 and email it to a colleague, you still need to send them the key. If you send the key in the same email, you've negated the encryption. If you call them on the phone, you've introduced a different channel with its own security assumptions. At small scale, this is manageable. Across thousands of services, APIs, and automated systems, it becomes an architectural problem.

The practical solution (hybrid encryption) is covered in the section on enterprise best practices below.

Scalability challenges

Symmetric encryption requires a unique key for every pair of communicating parties. The number of keys required grows as n(n-1)/2, where n is the number of participants. Ten users need 45 keys. One hundred users need 4,950. A thousand users need nearly half a million.

In enterprise environments with hundreds of services, microservices, and automated pipelines, key proliferation becomes a real operational burden. Without centralized key management, teams default to reusing keys across contexts — which eliminates the isolation that per-pair keys are supposed to provide.

Lack of non-repudiation

Because both parties share the same key, symmetric encryption cannot prove who created a ciphertext. Either party could have encrypted the data. This makes symmetric encryption unsuitable for digital signatures, legal agreements, or any scenario where you need cryptographic proof of origin.

Non-repudiation requires asymmetric cryptography — specifically, a private key that only one party holds. This is why code signing, email signing (S/MIME), and document authentication use RSA or ECDSA rather than AES.

Common symmetric algorithms in 2026

AES (Advanced Encryption Standard)

AES is the NIST-standardized block cipher defined in FIPS 197 (2001, revised 2023). It operates on 128-bit blocks with key sizes of 128, 192, or 256 bits. AES-256 is the enterprise default for high-assurance environments.

The mode of operation matters as much as the algorithm. AES-GCM (Galois/Counter Mode) provides authenticated encryption — it simultaneously encrypts data and produces a message authentication code (MAC) that detects tampering. Using AES without authentication (AES-CBC without a separate HMAC, for example) leaves ciphertext vulnerable to padding oracle attacks and bit-flipping. Always use AES-256-GCM or AES-256-CCM for new implementations.

AES-NI hardware instructions, available on virtually all modern Intel and AMD server CPUs since 2010, make AES-256-GCM the fastest authenticated encryption option available on standard server hardware.

ChaCha20

ChaCha20-Poly1305 is a stream cipher designed by Daniel Bernstein. It provides strong security with a 256-bit key and is the preferred alternative to AES in environments without hardware acceleration — primarily mobile devices and older embedded systems. TLS 1.3 includes ChaCha20-Poly1305 as a mandatory cipher suite alongside AES-256-GCM.

On servers with AES-NI, AES-256-GCM is faster. On hardware without it, ChaCha20-Poly1305 is the better choice. The decision is architectural, not cryptographic — both algorithms provide equivalent security margins.

Overcoming the cons: Enterprise best practices

The key distribution problem and scalability challenges are real, but they are solved problems. Modern enterprise architectures address both systematically.

Hybrid encryption: The TLS 1.3 model

Hybrid encryption combines asymmetric and symmetric cryptography to get the benefits of both. The asymmetric algorithm handles key exchange. The symmetric algorithm handles data encryption.

TLS 1.3 is the clearest example. During the handshake, the client and server use Diffie-Hellman key exchange (an asymmetric operation) to derive a shared session key without ever transmitting it over the network. Once both sides hold the same session key, all subsequent data is encrypted with AES-256-GCM. The asymmetric step solves the distribution problem; the symmetric step provides the throughput.

The same pattern applies to file encryption, secure email, and encrypted storage systems. The symmetric key that protects the data is itself encrypted with a public key and stored alongside the ciphertext. Only the holder of the corresponding private key can recover the symmetric key and decrypt the data.

Robust key management: KMS and HSMs

The 2023 Storm-0558 breach is the clearest recent example of what happens when key management fails. A Chinese threat actor obtained a Microsoft MSA signing key and used it to forge authentication tokens for Exchange Online and Outlook.com, accessing email accounts across multiple U.S. government agencies. The Cyber Safety Review Board's subsequent investigation found that Microsoft could not definitively determine how the key was stolen — a finding that reflects inadequate key lifecycle controls, not a weakness in the underlying cipher.

Attackers rarely try to break AES-256. They steal the key. According to Verizon's 2025 DBIR, 68% of data breaches involve a human element — stolen credentials, phishing, or misuse. The cipher is not the attack surface. The key is.

This is why Key Management Systems (KMS) and Hardware Security Modules (HSMs) exist. A KMS centralizes key generation, storage, rotation, and revocation. An HSM is a tamper-resistant hardware device that performs cryptographic operations without ever exposing the raw key material to software. Keys generated inside an HSM cannot be extracted — even by the administrator who configured it.

Effective key management requires four operational controls:

1. Rotation schedules. Keys should be rotated on a defined schedule and immediately upon any suspected compromise. NIST SP 800-57 Part 1 provides guidance on cryptoperiods by algorithm and use case.
2. Separation of duties. The team that manages encryption keys should not be the same team that manages the data those keys protect.
3. Access logging. Every key access event should be logged with timestamp, identity, and purpose. This is a prerequisite for SOC 2 CC6.1 and ISO 27001 Annex A.10 compliance.
4. Automated rotation. Manual key rotation at scale is error-prone. Automation reduces the window of exposure and eliminates the human errors that create incidents like Storm-0558.

IBM's 2025 Cost of a Data Breach Report puts the global average breach cost at $4.44 million — a 9% decrease from 2024, driven largely by faster detection and containment. Organizations with mature key management practices detect breaches faster because they have the audit trails to trace anomalous access.

Symmetric encryption and compliance requirements

Compliance frameworks don't prescribe specific algorithms in most cases, but they do require demonstrably strong encryption — and AES-256 is the benchmark auditors expect to see.

GDPR Article 32 requires "appropriate technical and organisational measures" to protect personal data, explicitly citing encryption as an example. PCI DSS v4.0 Requirement 3.5.1 mandates strong cryptography for stored primary account numbers, with AES-256 as the accepted standard. HIPAA's Security Rule (45 CFR § 164.312(a)(2)(iv)) treats encryption of data at rest as an addressable implementation specification — meaning organizations must implement it or document why an equivalent alternative is in place.

For organizations subject to NIS2, the directive requires "state of the art" cryptographic measures for critical infrastructure. AES-256-GCM satisfies that requirement today. Weaker algorithms — 3DES, DES, or AES-128 in unauthenticated modes — do not.

The connection between encryption choices and compliance outcomes is direct. Using a deprecated algorithm like 3DES (which NIST deprecated in SP 800-131A Rev. 2) in a PCI DSS audit is a finding. Using AES-256-GCM with documented key management is not.

Conclusion

Symmetric algorithms occupy a pivotal place in the realm of cryptography. Their efficiency and speed make them an invaluable asset for many applications, especially those involving large-scale data encryption. However, the limitations inherent in symmetric algorithms, including key management complexities, lack of authentication, and absence of perfect forward secrecy, necessitate meticulous implementation and the incorporation of additional security measures.

Therefore, the decision to utilize symmetric algorithms should be made based on a thorough understanding of these pros and cons, as well as the specific requirements of the system in question.

FAQ: Symmetric algorithms for data security

What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses one shared key for both encryption and decryption. Asymmetric encryption uses a mathematically linked key pair: a public key to encrypt and a private key to decrypt. Symmetric algorithms are faster and suited for bulk data; asymmetric algorithms solve the key distribution problem and enable digital signatures. Modern systems use both in combination.

Is AES-256 quantum-resistant?

AES-256 is considered quantum-resistant under current projections. Grover's algorithm reduces the effective security of AES-256 from 256 bits to 128 bits on a quantum computer — a level that remains computationally infeasible to attack with any known or projected hardware. Asymmetric algorithms like RSA and ECDH are far more vulnerable to quantum attacks via Shor's algorithm and are the primary focus of NIST's Post-Quantum Cryptography standardization effort.

What is the key distribution problem in symmetric encryption?

The key distribution problem is the challenge of securely sharing a symmetric key between two parties over an untrusted channel. If the key is transmitted insecurely, an attacker who intercepts it can decrypt all protected data. The standard solution is hybrid encryption: an asymmetric key exchange (such as Diffie-Hellman) establishes the shared symmetric key without transmitting it directly, eliminating the exposure.

Why do enterprises use AES-256-GCM instead of AES-256-CBC?

AES-256-GCM provides authenticated encryption — it encrypts data and generates a message authentication code in a single operation, detecting any tampering with the ciphertext. AES-256-CBC encrypts data but provides no integrity verification on its own. Without a separate HMAC, CBC-mode ciphertext is vulnerable to padding oracle attacks and bit-flipping. GCM mode is the current best practice for new implementations.

What is a Hardware Security Module (HSM) and why does it matter for key management?

An HSM is a tamper-resistant hardware device that generates, stores, and uses cryptographic keys without ever exposing the raw key material to the host system's software or memory. Keys created inside an HSM cannot be extracted, even by administrators. HSMs are used to protect root keys, signing keys, and master encryption keys in high-assurance environments. They are required by PCI DSS for protecting key-encrypting keys and are a best practice for any organization managing long-lived cryptographic material.

How does the "Harvest Now, Decrypt Later" threat affect symmetric encryption?

HNDL is an attack strategy where adversaries collect encrypted data today and store it until quantum hardware capable of breaking the encryption becomes available. Symmetric encryption protected with AES-256 is significantly more resistant to this threat than asymmetric encryption: Grover's algorithm reduces AES-256 to 128 bits of effective security, which remains infeasible to attack. Data protected only with RSA or ECDH is at higher risk, since Shor's algorithm could break those algorithms on a sufficiently powerful quantum computer.

What symmetric algorithms should organizations avoid in 2026?

DES (56-bit key) has been broken since the late 1990s and should never be used. 3DES was deprecated by NIST in SP 800-131A Rev. 2 (2019) and is disallowed in new systems. Blowfish is a legacy algorithm superseded by AES. RC4 is broken and prohibited in TLS. Any AES implementation without authenticated encryption (GCM or CCM mode) should be treated as incomplete. The current standard for new implementations is AES-256-GCM or ChaCha20-Poly1305.

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Insecure password sharing: 2026 risks and secure solutions

Every time a credential moves through Slack or email, you lose accountability, audit trail, and compliance posture in one step. This guide covers the real risks of insecure password sharing in 2026, why employees do it anyway, and how to migrate to vault-mediated access without disrupting your team.

Passwork BlogAlex Muntyan

How SHA-256 works: Can you decrypt it?

SHA-256 is mathematically sound — but that doesn’t make your passwords safe. How the algorithm works, where implementations fail, and what correct password storage actually looks like.

Passwork BlogPasswork Team

If you've heard of ‘SHA’ in various forms but aren't sure what it stands for or why it's essential — you’re in luck! We'll attempt to shed some light on the family of cryptographic hash algorithms today.

But, before we get into SHA, let's go over what a hash function is and how it works. Before you can comprehend what SHA-1 and SHA-2 are, you must first grasp these principles.

Let's get started.

What Is a hash function?

A hash function relates to a set of characters (known as a key) of a certain length. The hash value is a representation of the original string of characters, however, it is usually smaller.

Because the shorter hash value is simpler to search for than the lengthier text, hashing is used for indexing and finding things in databases. Encryption employs hashing as well.

SHA-1, SHA-2, SHA-256… What’s this all about?

There are three types of secure hash algorithms: SHA-1, SHA-2, and SHA-256. The initial iteration of the algorithm was SHA-1, which was followed by SHA-2, an updated and better version of the first. The SHA-2 method produces a plethora of bit-length variables, which are referred to as SHA-256. Simply put, if you see “SHA-2,” “SHA-256” or “SHA-256 bit,” those names are referring to the same thing.

The NIST's Formal Acceptance

FIPS 180-4, published by the National Institute of Standards and Technology, officially defines the SHA-256 standard. Moreover, a set of test vectors is included with standardization and formalization to confirm that developers have correctly implemented the method.

Let’s break down the algorithm and how it works:

1. Append padding bits

The first step in our hashing process is to add bits to our original message to make it the same length as the standard length needed for the hash function. To accomplish so, we begin by adding a few details to the message we already have. The amount of bits we add is determined so that the message's length is precisely 64 bits less than a multiple of 512 after these bits are added. This can be expressed mathematically in the following way:

n x 512 = M + P + 64

M is the original message's length.
P stands for padded bits.

2. Append length bits

Now that we've added our padding bits to the original message, we can go ahead and add our length bits, which are equal to 64 bits, to make the whole message an exact multiple of 512.

We know we need to add 64 extra bits, so we'll compute them by multiplying the modulo of the original message (the one without the padding) by 232. We add those lengths to the padded bits in the message and get the complete message block, which must be a multiple of 512.

3. Initialize the buffers

We now have our message block, on which we will begin our calculations in order to determine the final hash. Before we get started, I want to point out that we'll need certain default settings to get started with the steps we'll be taking.

a = 0x6a09e667
b = 0xbb67ae85
c = 0x3c6ef372
d = 0xa54ff53a
e = 0x510e527f
f = 0x9b05688c
g = 0x1f83d9ab
h = 0x5be0cd19

Keep these principles in the back of your mind for now; all will fit together in the following phase. There are a further 64 variables to remember, which will operate as keys and are symbolized by the letter 'k.'

Let's go on to the portion where we calculate the hash using these data.

4. Compression Function

As a result, here is where the majority of the hashing algorithm is found. The whole message block, which is 'n x 512' bits long, is broken into 'n' chunks of 512 bits, each of which is then put through 64 rounds of operations, with the result being provided as input for the next round of operations.

The 64 rounds of operation conducted on a 512-bit message are plainly visible in the figure above. We can see that we send in two inputs: W(i) and K(i). During the first 16 rounds, we further break down the 512-bit message into 16 pieces, each consisting of 32 bits. Indeed, we must compute the value for W(i) at each step.

W(i) = Wⁱ⁻¹⁶ + σ⁰ + Wⁱ⁻⁷ + σ¹
where,
σ⁰ = (Wⁱ⁻¹⁵ ROTR⁷(x)) XOR (Wⁱ⁻¹⁵ ROTR¹⁸(x)) XOR (Wⁱ⁻¹⁵ SHR³(x))
σ¹ = (Wⁱ⁻² ROTR¹⁷(x)) XOR (Wⁱ⁻² ROTR¹⁹(x)) XOR (Wⁱ⁻² SHR¹⁰(x))
ROTRⁿ(x) = Circular right rotation of 'x' by 'n' bits
SHRⁿ(x) = Circular right shift of 'x' by 'n' bits

5. Output

Every round's output is used as an input for the next round, and so on until just the final bits of the message are left, at which point the result of the last round for the nth portion of the message block will give us the result, i.e. the hash for the whole message. The output has a length of 256 bits.

Conclusion

In a nutshell, the whole principle behind SHA would sound something like this:

We determine the length of the message to be hashed, then add a few bits to it, beginning with '1' and continuing with '0' and then ‘1’ again until the message length is precisely 64 bits less than a multiple of 512. By multiplying the modulo of the original message by 232, we may add the remaining 64 bits. The complete message block may be represented as 'n x 512' bits after the remaining bits are added. Now, we split each of these 512 bits into 16 pieces, each of 32 bits, using the compression function, which consists of 64 rounds of operations. For the first 16 rounds, these 16 sections, each of 32 bits, operate as input, and for the next 48 rounds, we have a technique to compute the W(i). We also include preset buffer settings and 'k' values for each of the 64 rounds. We can now begin computing hashes since we have all of the necessary numbers and formulae. The hashing procedure is then repeated 64 times, with the result of the i round serving as the input for the i+1 round. As a result, the output of the 64th operation of the nth round will be the output, which is the hash of the whole message.

The SHA-256 hashing algorithm is now one of the most extensively used hashing algorithms since it has yet to be cracked and the hashes are generated rapidly when compared to other safe hashes such as the SHA-512. It is well-established, but the industry is working to gradually transition to SHA-512, which is more secure, since experts believe SHA-256 may become susceptible to hacking in the near future.

What is quantum cryptography?

If the concept of ‘quantum cryptography’ sounds complicated to you, you’re right. That’s why this ‘encryption tutorial for dummies’ shall demystify the concept and provide an explanation in layman’s terms. Quantum cryptography, which has been around for a few decades, is becoming more and more important to our

Passwork BlogIliya Garakh, CTO

Passwork: Secrets management and automation for DevOps

Introduction In corporate environment, the number of passwords, keys, and digital certificates is rapidly increasing, and secrets management is becoming one of the critical tasks for IT teams. Secrets management addresses the complete lifecycle of sensitive data: from secure generation and encrypted storage to automated rotation and audit trails. As

Passwork BlogEirik Salmi

Passwork vs 1Password: Best Password Manager for EU

GDPR, NIS2, ANSSI 2027 — the regulatory pressure keeps building. We compare Passwork and 1Password on the criteria that matter to European businesses: data sovereignty, audit readiness, deployment model, and real total cost of ownership.

Passwork BlogPasswork Team

If the concept of ‘quantum cryptography' sounds complicated to you, you're right. That’s why this ‘encryption tutorial for dummies’ shall demystify the concept and provide an explanation in layman’s terms.

Quantum cryptography, which has been around for a few decades, is becoming more and more important to our daily lives because of its ability to protect essential data in a manner that conventional encryption techniques cannot.

What is it?

Cryptography, as we all know, is a technique that aims to encrypt data by scrambling plain text so that only those with the appropriate ‘key’ can read it. By extension, quantum cryptography encrypts data and transmits it in an unhackable manner using the principles of quantum mechanics.

While such a concept seems straightforward, the intricacy resides in the quantum mechanics that underpin quantum cryptography. For example:

• The particles that make up the cosmos are fundamentally unpredictable, and they may exist in several places or states of existence at the same time;
• A quantum attribute cannot be measured without causing it to change or be disturbed;
• Some quantum attributes of a particle can be cloned, but not the whole particle.

How does it work?

Theoretically, quantum cryptography operates by following a model that was first published in 1984.

Assume there are two people called Alice and Bob who want to communicate a message in a safe manner, according to the model of quantum cryptography. Alice sends Bob a key, which serves as the signal for the communication to begin. One of the most important components is a stream of photons that go in just one direction. Each photon corresponds to a single bit of data — either a 0 or a 1 — in the computer's memory. However, in addition to traveling in a straight path, these photons are oscillating, or vibrating, in a certain fashion as they move.

The photons pass via a polarizer before reaching Alice, the sender, who then commences the transmission. When some photons pass through a polarizer with the same vibrations as before, and when others pass through with different vibrations, the filter is said to be ‘polarized’. There are many polarization states to choose from, including vertical (1 bit), horizontal (0 bit), 45 degrees right (1 bit) and 45 degrees left (0 bit). In whatever system she employs, the broadcast has one of two polarizations, each encoding a single bit, which is either 0 or 1.

From the polarizer to the receiver, the photons are now traveling via optical fiber to Bob. Each photon is analyzed using a beam splitter, which determines the polarization of each photon. After receiving the photon key, Bob does not recognize the right polarization of the photons, so he chooses one polarization at random from a pool of available options. Alice now compares the polarizers Bob used to polarize the key and informs Bob of the polarizer she used to deliver each photon to the receiver. Bob checks to see whether he used the right polarizer at this point. The photons that were read with the incorrect splitter are then eliminated, and the sequence that is left is deemed the key sequence.

Let's pretend there is an eavesdropper present, who goes by the name of Eve. Eve seeks to listen in and has the same tools as Bob in order to do so successfully. However, Bob has the benefit of being able to converse with Alice in order to check which polarizer type was used for each photon, but Eve does not. Eve is ultimately responsible for rendering the final key.

Alice and Bob would also be aware if Eve was listening in on their conversation. After Eve observes the flow of photons, the photon locations that Alice and Bob anticipate to see will be altered as a result of her observations.

Well, that’s all pretty mind-blowing, but for us, the general public, the biggest question is…

Is it really used?

Although the model described above has not yet been fully developed, there have been successful implementations of it, including the following:

• The University of Cambridge and the Toshiba Corporation collaborated to develop a high-bit-rate quantum key distribution system based on the BB84 quantum cryptography protocol;
• DARPA's Quantum Network, which operated from 2002 to 2007, was a 10-node QKD (Quantum Key Distribution) network constructed by Boston University, Harvard University, and IBM Research. It was operated by the Defense Advanced Research Projects Agency;
• Quantum Xchange created the first quantum network in the United States, which is comprised of over 1,000 kilometers of optical fiber;
• The development of commercial QKD systems was also carried out by commercial businesses such as ID Quantique, Toshiba, Quintessence Labs, and MagiQ Technologies Inc.

As you can see, these rare implementations are pretty far from what you’d expect to use every day. But hopefully, that will change in the near future.

The pros and cons of quantum cryptography

As with any developing technology, the state of it now (2022), may be very different to its state in the future. Thus, the following table may change dramatically. We do believe, however, that we’ll see fewer points in the ‘Limitations’ column as the years go on.

The need for unbreakable encryption is right there staring us down. The development of quantum computers is on the horizon, and the security of encrypted data is now in jeopardy due to the threat of quantum computing. We are fortunate in that quantum cryptography, in the form of QKD, provides us with the answer we need to protect our information long into the future — all while adhering to the difficult laws of quantum physics.

Python connector 0.1.5: Automated secrets management

The new Python connector version 0.1.5 expands CLI utility capabilities. We’ve added commands that solve critical tasks for DevOps engineers and developers — secure retrieval and updating of secrets in automated pipelines. What this solves Hardcoded secrets, API keys, tokens, and database credentials create security vulnerabilities and operational bottlenecks.

Passwork BlogEirik Salmi

What is password hashing and salting?

Cryptography is both beautiful and terrifying. Perhaps a bit like your ex-wife. Despite this, it represents a vital component of day-to-day internet security; without it, our secrets kept in the digital world would be exposed to everyone, even your employer. I doubt you’d want information regarding your sexual preferences

Passwork BlogIliya Garakh, CTO

Passwork: Secrets management and automation for DevOps

Introduction In corporate environment, the number of passwords, keys, and digital certificates is rapidly increasing, and secrets management is becoming one of the critical tasks for IT teams. Secrets management addresses the complete lifecycle of sensitive data: from secure generation and encrypted storage to automated rotation and audit trails. As

Passwork BlogEirik Salmi

End-to-end encryption has been introduced by many communication providers in recent years, notably WhatsApp and Zoom. Although those companies have tried to explain the concept to their user base several times, we believe they failed. Whilst it's clear that these platforms have increased security, most don’t know how or why. Well, encryption is a rather simple concept to understand: It converts data into an unreadable format. But what exactly does "end-to-end" imply? What are the advantages and disadvantages of this added layer of security? We'll explain this as simply as possible without diving too much into the underlying math and technical terminology.

What is end-to-end encryption?

End-to-end encryption (E2EE) is a state-of-the-art protocol for communication security. Only the sender and the intended recipient(s) have access to the data in an end-to-end encrypted system. The encrypted data on the server is inaccessible to both hackers and undesirable third parties.

End-to-end encryption is best understood when compared to the encryption-in-transit approach, so let’s perform a quick recap. If a service employs encryption-in-transit, it is usually encrypted on your device before being delivered to the server. It’s then decrypted for processing on the server before it’s re-encrypted and routed to its final destination. When the data is in transit, it’s encrypted, but when it’s ‘at rest’, it’s decrypted. This safeguards the data during the most dangerous stage of the journey, transit — when it’s most exposed to hackers, interception, and theft.

End-to-end encryption, on the other hand, is the process of encrypting data on your device and not decrypting it until it reaches its destination. When your message travels through the server, not even the service that is delivering the data can view the content of your message.

In practice, this means that messengers using 'real' end-to-end encryption, like Signal, know only your phone number and the date of your last login – nothing more.

This is important for users that want to be sure their communication is kept secure from prying eyes. There are also some real-life examples that utilize end-to-end encryption for financial transactions and commercial communication.

How does it work?

The generation of a public-private key pair ensures the security of end-to-end encryption. This method, also known as asymmetric cryptography, encrypts and decrypts the message using distinct cryptographic keys. Public keys are widely distributed and are used to encrypt or ‘lock’ messages. Only the owner has access to the private keys, which are needed to unlock or decrypt the communication.

Whenever the user takes part in any end-to-end encrypted communication, the system automatically generates dedicated public and private keys.

If this sounds too complicated, here is a very simple metaphor:

You just bought a new Rolex for your buddy, who lives in Australia. Now, it’s already in a fancy green leather box, so you decide to put the stamp directly on it and send it. There is nothing wrong with that approach as long as you trust that the postal workers won’t steal it.

However, if you decide to put the Rolex box inside another box, hiding the nature of the gift from all interacting parties along the way, then you’ve effectively ensured (for all intents and purposes) that the Rolex is only visible to the intended recipient; when your mate from down under gets a hold of the box, he takes his pair of scissors and ‘decrypts’ the present. Indeed, you’ve ensured ‘end-to-end’ encryption.

You’re already using end-to-end encryption, daily

As we mentioned before, during an E2EE interaction, the server that delivers encrypted data between one "end" and the other "end" is unable to decode and read the data it sends. Even the servers' owners are unable to access the information since it is not saved on the servers themselves, only the "endpoints" (or the devices) of the discussion can decode the data.

If you’re daily using messengers like WhatsApp, iMessage, and Signal (where E2EE is enabled by default) or Telegram, Allo, and Facebook's ‘Secret Conversation’ function (where E2EE can be manually activated) – you’re already using end-to-end encryption.

What's more fascinating is that E2EE communication providers don't require you to trust them. And that’s great!

The fact that their systems can be hacked makes no difference to you because the transported data is encrypted and can only be read by the sender and receiver, which has enraged several organizations. There are known cases when such agencies asked for special ‘backdoors’ that would allow them to decrypt messages.

Why isn’t everything end-to-end encrypted?

End-to-end encryption is theoretically sound, but it lacks flexibility, thus it can't be utilized when the "two ends" that communicate data don't exist, such as with cloud storage.

This is why Zero-Knowledge Encryption was created, a solution that overcomes the problem by hiding the encryption key, even from the storage provider, resulting in an authentication request without the requirement for password exchange.

Moreover, end-to-end encryption does not hide information about the message, such as the date and time it was sent or the people who participated in the conversation. This metadata might provide indications on where the 'end-point' might be – not great if you are the target of a hacker.

The biggest problem, however, is that in reality, we never know whether the communication is end-to-end encrypted. Providers may claim to provide end-to-end encryption when what they truly deliver is encryption-in-transit. The information might be kept on a third-party server that can be accessed by anybody who has access to the server.

Conclusion

While it’s obvious that you shouldn’t be shipping Dave’s Rolex in its fancy green box, the reality is, if you’ve nothing to hide and you’re not transporting something incredibly valuable, encryption-in-transit is up to the job.

End-to-end encryption is a wonderful technology that enables a high level of security when properly implemented. But it doesn't really tackle the main issue – the end-user, still, to this day, needs to trust the system that they’re using to communicate. We hope that the next generation of encryption technologies such as ZKP will be able to change that.

Password-cracking techniques used by hackers

Which words pop into your head when creating a password for your new account on a website or on a social network? Safety? Privacy? Well, there’s some bad news for you here — in our digital world, hackers are clued-up on hacking any kind of password that you can think

Passwork BlogIliya Garakh, CTO

Passwork 7: Security verified by HackerOne

Passwork has successfully completed the penetration testing, carried out by HackerOne — the world’s largest platform for coordinating bug bounty programs and security assessments. This independent evaluation confirmed Passwork’s highest level of data protection and strong resilience against modern cyber threats. What the pentest covered Security architecture and data

Passwork BlogEirik Salmi

Passwork: Secrets management and automation for DevOps

Introduction In corporate environment, the number of passwords, keys, and digital certificates is rapidly increasing, and secrets management is becoming one of the critical tasks for IT teams. Secrets management addresses the complete lifecycle of sensitive data: from secure generation and encrypted storage to automated rotation and audit trails. As

Passwork BlogEirik Salmi

In this year of our lord, 2022, the term ‘Zero-Knowledge Encryption’ equates to best-in-class data insurance. We’ve already written an article named “What is Zero-Knowledge Proof?”, so we’re not going to look at definitions here, but rather, we’re going to explore the pros and cons of Zero-Knowledge proof encryption when compared to other technologies.

But for those who don’t want to dive deep into technical details, here’s an explanation of what Zero-Knowledge Encryption means:

It simply implies that no one else (not even the service provider) has access to your password-protected data.

This is important because even if your files are completely encrypted, if the server has access to the keys, a centralized hacker attack can result in a data breach.

In order to gain a better understanding of the factors that led to the development of Zero-Knowledge Encryption, we've decided to present a succinct, yet comprehensive, assessment of the advantages and disadvantages of three existing options:

Encryption-in-transit

Data in-transit, also known as data in motion, is data that is actively flowing from one point to another, such as that over the internet or over a private network. Data protection in transit refers to the security of data while it is being transferred from one network to another or from a local storage device to a cloud storage device. Effective data protection measures for in-transit data are critical because data is often considered less secure while in transit. Think of it like hiring security guards to accompany your cash-in-transit vehicle’s trip to the bank.

This means that, while using this approach, stored docs are 100% decryptable, so vulnerable.

As for our everyday life, the following technologies use the ‘encryption-in-transit’ approach:

• Transport Layer Security (TLS), which is aimed at ensuring your security on the web;
• Secure/Multipurpose Internet Mail Extensions (S/MIME), which are often used for email message security.

Encryption-at-rest

Any data encryption is the process of converting one type of data into another that cannot be decrypted by unauthorized users. For example, you may have saved a copy of your passport. You obviously don't want this data to be easily accessed. If you store encrypted data on your server, it’s effectively "resting" there (which is why it’s called encryption-at-rest). This is usually accomplished by the use of an algorithm that is incomprehensible to a user who does not have access to the encryption key needed to decode it. Only an authorized person will be able to access the file, ensuring that your data is kept safe.

The Advanced Encryption Standard (AES) is often used to encrypt data at rest.

But, in order to access the data, you need a key — and that’s where the potential vulnerability lies.

Encryption-at-rest is like storing your data in a secret vault, encryption-in-transit is like putting it in an armored vehicle with security guards for transport.

End-to-end encryption

End-to-end encryption is the act of applying encryption to messages on one device so that only the device to which it is sent can decrypt it. The message travels all the way from the sender to the recipient in encrypted form.

In practice, it means that only the communicating users (who have the key) can read the messages.

End-to-end encryption has created an impregnable fortress for communication services (for example, messengers), going beyond the security "façade" of encryption-in-transit and encryption-at-rest solutions.

This is the most common approach when protecting oneself against data breaches nowadays, but it only works from "one end to the other," as the term implies. Even though this all sounds great, end-to-end encryption can only be used for a "communication system" like Whatsapp or Telegram.

While theoretically sound, end-to-end encryption lacks flexibility, so it can’t be used when the "two ends" that share data don't exist, such as for cloud storage.

This is the motivation behind the development of Zero-Knowledge Encryption, a method that solves the problem by hiding the encryption key, even from the storage provider, resulting in an authentication request without the need for password exchange.

Zero-Knowledge encryption

To log in to an account, you usually have to type in the exact password. In today's hyperconnected world, it's normal practice to tell the server your secret key ahead of time and test whether it matches.

Instead, there is another, more secure way, to manage this delicate process and that’s called Zero-Knowledge Encryption.

Without diving deep, The Zero-Knowledge relies on three main requirements:

1. Completeness — an honest prover will be able to convince the verifier that he has the password by completing some process in the required way;
2. Soundness — the verifier will almost certainly discover when the prover is lying;
3. Zero-knowledge — if the prover has a password, the verifier receives no more information other than the fact that the statement is true.

Essentially, the system will check to see if you can demonstrate your knowledge several times by responding to various conditions. It’s like a brute force attack carried out backwards — you perform the same action many times in order to make sure that the prover isn’t lying.

Instead of concluding, let’s round up the pros and cons of Zero-Knowledge proof encryption when compared to the alternatives:

The con here is a clear example of the exceptional security provided by the Zero-Knowledge Encryption solution, which prevents even system administrators from recovering your password. This is why we, at Passwork, rely on this technology in our products. Ultimately, that’s why you can rely on us too.

Comprehensive guide: Cybersecurity vocabulary – terms and phrases you need to know

Cybersecurity — as complex as it sounds — is an essential concept that we all need to be aware of in this day and age. Computers, phones, and smart devices have become an extension of our bodies at this point, which makes their security paramount. From your family photos to your bank

Passwork BlogEirik Salmi

Why Zero-Knowledge Encryption is the best

In this year of our lord, 2022, the term ‘Zero-Knowledge Encryption’ equates to best-in-class data insurance. We’ve already written an article named “What is Zero-Knowledge Proof?”, so we’re not going to look at definitions here, but rather, we’re going to explore the pros and cons of Zero-Knowledge

Passwork BlogIliya Garakh, CTO

Python connector 0.1.5: Automated secrets management

The new Python connector version 0.1.5 expands CLI utility capabilities. We’ve added commands that solve critical tasks for DevOps engineers and developers — secure retrieval and updating of secrets in automated pipelines. What this solves Hardcoded secrets, API keys, tokens, and database credentials create security vulnerabilities and operational bottlenecks.

Passwork BlogEirik Salmi

It is rare for technologies to be born from ambitious philosophical concepts or mind games. But, when it comes to security and cryptography – everything is a riddle.

One of such riddles is ‘How can you prove that you know a secret without giving it away?’. Or in other words, ‘how can you tell someone you love them without saying that you love them?’.

The Zero-Knowledge Proof technique, as suggested by the name, uses cryptographic algorithms to allow several parties to verify the authenticity of a piece of information without having to share the material that makes it up. But how is it possible to prove something without supporting evidence? In this article, we’ll try our best to break it down for you as easily as possible.

Why?

We’re asking ourselves day after day – why on Earth would people decide to use such a complicated concept. Well, millions of people use the internet every day, accepting cookies and sharing personal information in exchange for access to services and digital products. Users are gradually becoming more vulnerable to security breaches and unauthorized access to their data. Furthermore, individuals frequently have to give up their privacy in return for digital platform services such as suggestions, consultations, tailored support, and so on, all of which wouldn’t be available when browsing privately. Due to all the above mentioned, there is a certain asymmetry regarding access to information – you give your information in exchange for a service.

In 1985, three great minds noticed ‘a great disturbance in the Force’ ahead of their time and released a paper called "The Knowledge Complexity of Interactive Proof-Systems" which introduced the concept of Zero-Knowledge Proof (ZKP) for the first time.

So what is it?

ZKP is a set of tools that allows an item of data to be evaluated without having to reveal the data that supports it. This is made feasible by a set of cryptographic methods that allow a "tester" to mathematically prove to a "verifier" that a computational statement is valid without disclosing any data.

It is possible to establish that particular facts are correct without having to share them with a third party in this way. For example, a user could demonstrate that he is of legal age to access a product or service without having to reveal his exact age. Or, it’s a bit like showing your friend your driving license instead of proving to him that you can drive by road-tripping to Mexico.

This technique is often used in the digital world to authenticate systems without the risk of information being stolen. Indeed, it’s no longer necessary to provide any personal data in order to establish a person's identity.

Sounds great, but how does it work?

The prover and the verifier are the two most important roles in zero-knowledge proofs. The prover must demonstrate that they are aware of the secret whereas the verifier must be able to determine whether or not the prover is lying.

It works because the verifier asks the prover to do actions that can only be done if the prover is certain that he or she is aware of the secret. If the prover is guessing, the verifier's tests will catch him or her out. If the secret is known, the prover will pass the verifier's exam with flying colors every time. It's similar to when a bank or other institution requests letters from a known secret word in order to authenticate your identity. You're not telling the bank how much money you have in your account; you're simply demonstrating that you know.

Wonderful, but how does it REALLY work?

To answer this, let’s take a look at a piece of research by Kamil Kulesza.

Assume that two characters, Alice and Bob, find themselves at the mouth of a cave with two independent entrances leading to two different paths (A and B). A door inside the cave connects both paths, but it can only be unlocked with a secret code. This code belongs to Bob (the 'tester,') and Alice (the 'verifier,') wants to buy it, but first, she wants to make sure Bob isn't lying.

How can Bob demonstrate to Alice that he has the code without divulging its contents? They perform the following to achieve this: Bob enters the cave via one of the entrances at random while Alice waits outside (A or B). Once inside, Alice approaches the front door, summons Bob, and instructs him to use one of the two exits. Bob will always be able to return by the path that Alice used since he knows the secret code.

Bob will always be able to return via the path that Alice directs him to, even if it does not coincide with the one he chose in the first place, because he can unlock the door and depart through the other side with the secret code.

But wait a minute, there is still a 50% chance that both Alice and Bob chose the same path, right? It is correct indeed, however, if this exercise is repeated several times, the likelihood that Bob will escape along the same path chosen by Alice without possessing the code decreases until it is almost impossible. Conclusion? If Bob leaves this path a sufficient number of times, he has unmistakably shown to Alice that his claim of holding the secret code is true. Moreover, there was no need to reveal the actual code in this case.

You can find out more about the Bob and Alice metaphor here.

Got it, so how is it used?

As for right now, ZKP is developing hand in hand with blockchain technology.

Zcash is a crypto platform that uses a unique iteration of zero-knowledge proofs (called zk-SNARKs). It allows native transactions to stay entirely encrypted while still being confirmed under the network's consensus rules. It’s a great example of this technology being used in practice.

Even though zero-knowledge proofs have a lot of potential to change the way today's data systems verify information, the technology is still considered to be in its infancy — primarily because researchers are still figuring out how to best use this concept while identifying any potential flaws. This, however, doesn’t stop us from using this protocol in our products! ;)

For a deeper understanding of the technical aspects and history behind this protocol, we recommend watching this video on YouTube.

Python connector 0.1.5: Automated secrets management

The new Python connector version 0.1.5 expands CLI utility capabilities. We’ve added commands that solve critical tasks for DevOps engineers and developers — secure retrieval and updating of secrets in automated pipelines. What this solves Hardcoded secrets, API keys, tokens, and database credentials create security vulnerabilities and operational bottlenecks.

Passwork BlogEirik Salmi

Why Zero-Knowledge Encryption is the best

In this year of our lord, 2022, the term ‘Zero-Knowledge Encryption’ equates to best-in-class data insurance. We’ve already written an article named “What is Zero-Knowledge Proof?”, so we’re not going to look at definitions here, but rather, we’re going to explore the pros and cons of Zero-Knowledge

Passwork BlogIliya Garakh, CTO

How to create a secure password

Of course you want to keep your data safe. So why are so many security precautions frequently overlooked? Many accounts, for example, are protected by weak passwords, making it easy for hackers to do their work. There is a fine line between selecting a password that no one can guess

Passwork BlogIliya Garakh, CTO