El mòdul anterior va acabar amb una llista de defenses que ja has vist funcionar —TLS, les URL signades de 120 segons, l'HMAC del webhook de la passarel·la, DKIM, les passkeys, la signatura RS256 del JWT, el xifratge de les còpies, la comparació en temps constant del TOTP— i amb una constatació: totes descansen sobre el mateix fonament i fins ara l'hem tractat com una caixa negra. Aquesta lliçó obre la caixa. No en sortiràs sabent xifrar: en sortiràs sabent què se li demana a la criptografia, què se li pot demanar de debò, amb quin vocabulari precís se'n parla i per què —aquesta és la idea que travessa tot el mòdul— la part difícil gairebé mai no és l'algorisme. És important perquè la majoria de les fallades criptogràfiques reals de les pimes no consisteixen a trencar AES, sinó a fer servir la primitiva equivocada per al problema equivocat, confondre codificar amb xifrar, o generar una clau amb una font d'aleatorietat que no ho era.

1. Quin problema resol exactament la criptografia
2. Vocabulari precís: xifrar, codificar, calcular un hash i ofuscar no són el mateix
3. Història com a palanca conceptual: Cèsar, Vigenère i Enigma
4. El principi de Kerckhoffs i per què la seguretat viu a la clau
5. Models d'atacant i tipus d'atac criptogràfic
6. Què significa «segur» avui: bits de seguretat i mides de clau
7. Aleatorietat criptogràfica: el fonament invisible
8. El mapa del mòdul 3
9. La criptografia que Nimbus ja fa servir sense haver-la explicat

La criptografia és el conjunt de tècniques matemàtiques que permeten protegir informació davant d'un adversari que té accés al canal, al suport o a tots dos. Aquesta última frase és la clau i convé llegir-la a poc a poc: la criptografia no pressuposa un canal segur ni un disc fora de perill. Pressuposa el contrari. Assumeix que l'atacant veu les dades i, tot i així, aconsegueix que no li serveixin de res.

És l'aplicació directa del principi d'assumeix la bretxa de 01-03. Una nota clínica d'una clínica de fisioteràpia clienta de Nimbus viatja per wifis de cafeteries, es desa en discos d'un proveïdor cloud i es copia a buckets de respatller. En cap d'aquests tres punts no controlem el medi físic. La criptografia converteix «que ningú no toqui el medi» —impossible— en «que tocar el medi no serveixi de res» —assolible.

A 01-01 es va definir la tríada CIA i els seus complements: autenticitat, no-repudi i traçabilitat. Cadascuna d'aquestes propietats té una primitiva criptogràfica concreta que la proporciona. Aquesta taula és el mapa mental del mòdul sencer:

Tres lectures importants d'aquesta taula:

• Xifrar no dona integritat per si sol. És l'error conceptual més estès. Un text xifrat amb un mode antic pot ser alterat per un atacant de manera controlada sense conèixer la clau. Per això avui es fa servir xifratge autenticat, que ajunta les dues propietats en una sola operació (03-02).
• Un MAC i una signatura no són intercanviables. Tots dos donen autenticitat i integritat, però el MAC fa servir una clau compartida: si Nimbus i la passarel·la comparteixen la clau, Nimbus podria haver fabricat aquell missatge, així que no serveix com a prova davant d'un tercer. La signatura, amb clau privada, sí (03-03).
• El frescor no el dona cap de les anteriors. Un missatge xifrat, íntegre i autèntic de fa tres mesos continua sent xifrat, íntegre i autèntic avui. Reenviar-lo és un atac de repetició, i es combat amb nonces i finestres temporals, no amb més xifratge.

Igual d'important que l'anterior. La criptografia no:

• Protegeix davant de qui té la clau legítimament. Si un atacant roba les credencials de l'Iván, l'API desxifra per a ell amb tota correcció. Això és un problema d'identitat (02-05) i d'autorització, no de criptografia.
• Amaga metadades. TLS amaga el contingut de la petició, no que el teu portàtil parli amb nimbusreservas.example a les 03:14, ni la mida aproximada de la resposta.
• Dona disponibilitat. Un ransomware fa servir criptografia perfectament correcta contra tu. Xifrar no evita que esborrin.
• Substitueix el control d'accés. Hi tornarem a 03-07: xifrar una base de dades l'API de la qual exposa un IDOR no arregla l'IDOR.
• S'arregla sola. Una clau mal desada converteix AES-256 en un adorn. Aquest és l'assumpte de 03-06.

El mòdul sencer depèn de fer servir bé cinc paraules. Comencem per les bàsiques:

I ara la distinció que més vegades es fa malament en la pràctica professional:

Codificar no protegeix absolutament res. Base64 apareix constantment en tokens, en capçaleres HTTP i en configuracions, i amb una regularitat depriment algú conclou que «està encriptat». Demostrem que no:

Sortida:

Analitzem el codi línia a línia, perquè el detall importa:

• dada.encode("utf-8") converteix el text Python en bytes. Base64 opera sobre bytes, no sobre caràcters.
• base64.b64encode(...) produeix la representació en l'alfabet A-Z a-z 0-9 + /, amb = de farciment al final. No hi ha intervingut cap clau. El resultat depèn únicament de l'entrada.
• base64.b64decode(...) reverteix l'operació. No se li passa cap secret perquè no n'existeix cap.

La conclusió operativa: si veus un valor acabat en == en un registre, un tiquet o una URL, no està protegit; està transportat. I si conté dades personals, aquell registre és una fuita (això connecta directament amb la regla de «què registrar i què no» de 02-04).

Prova de butxaca per distingir-les. Pregunta't: puc desfer això sense cap secret? Si la resposta és sí, és codificació o ofuscació, i no aporta seguretat. Si necessito un secret, és xifratge. Si no es pot desfer de cap manera, és un hash.

La història de la criptografia no s'estudia aquí per erudició, sinó perquè cada fracàs històric va deixar una lliçó que continua vigent paraula per paraula.

Aquest exemple existeix només perquè vegis amb els teus propis ulls què significa «espai de claus petit».

Advertiment explícit. El xifratge Cèsar no té cap valor de seguretat. No el facis servir mai per protegir res, ni tan sols com a «capa addicional». Apareix aquí exclusivament com a il·lustració conceptual, igual que un dibuix d'un pany de 1900 en un manual de serralleria.

Fragment de la sortida:

Què cal entendre d'això:

• No ha calgut cap matemàtica. El bucle prova les 25 claus en microsegons i un humà identifica la correcta amb un cop d'ull.
• L'operació % 26 és el que fa que l'alfabet sigui circular: després de la z torna la a.
• Desxifrar és xifrar amb el desplaçament negatiu: cesar(text, -clau).
• Un ordinador modern provaria de l'ordre de mil milions de claus per segon en un esquema tan simple. Amb 25 claus no hi ha defensa possible. Amb 2^128, com veurem a l'apartat 6, la força bruta deixa d'existir com a opció.

La lliçó permanent de Cèsar, la de Vigenère i la d'Enigma es resumeixen en tres frases que valen per al 2026: l'espai de claus ha de ser astronòmic; el material de clau no es reutilitza mai; i l'atacant ataca el més feble, que gairebé sempre és el procediment humà, no l'àlgebra.

A 01-03 vas conèixer el principi de Kerckhoffs com un dels quinze principis de disseny segur. Aquí és on cobra tot el seu sentit:

Un sistema criptogràfic ha de ser segur fins i tot si tot el que hi és relatiu, tret de la clau, és de domini públic.

Dit d'una altra manera: l'algorisme és públic; el secret és la clau, i només la clau. El contrari —confiar que ningú no conegui l'algorisme— s'anomena seguretat per obscuritat i és una de les pitjors decisions possibles en criptografia, per quatre raons concretes:

D'aquí surt la regla pedagògica central d'aquest mòdul, que llegiràs a les set lliçons:

No implementis mai criptografia a mà. Ni l'algorisme, ni el mode, ni el farciment, ni la comparació d'etiquetes. Fes servir llibreries establertes, mantingudes i auditades —en Python, cryptography, i els mòduls hashlib, hmac i secrets de la biblioteca estàndard—. La teva feina professional no és inventar primitives: és triar la correcta, configurar-la bé i gestionar-ne les claus. Les tres coses es fan malament sovint, i les tres són suficients per arruïnar un sistema.

Això no és una recomanació d'estil. La criptografia de qualitat industrial exigeix defensar-se de canals laterals, d'errors de farciment, de multiplicacions que triguen diferent segons els bits, de generadors de nombres aleatoris defectuosos. Una implementació «que dona el resultat correcte» pot estar filtrant la clau pel temps d'execució sense que cap test ho detecti.

Per dir que una cosa és segura cal dir davant de quin atacant. La criptografia formalitza això en models d'atacant, que es distingeixen pel que l'adversari pot fer:

L'estàndard modern és exigir seguretat davant del model més fort. Un algorisme actual com AES-GCM es considera segur fins i tot davant d'un atacant que tria textos en clar a voluntat; si un esquema només aguanta el model feble, es descarta.

Aturem-nos en la de temporització perquè és contraintuïtiva. Si el teu codi compara un codi de verificació caràcter a caràcter i retorna False així que troba una diferència, triga més quan encerta més caràcters. Un atacant que mesuri milers d'intents reconstrueix el secret caràcter a caràcter, i redueix un problema impossible a un de trivial. Per això existeix hmac.compare_digest, que veuràs en detall a 03-04, i per això comparar secrets amb == està prohibit en tot aquest curs.

La idea que has de treure d'aquest apartat. Gairebé cap incident criptogràfic real no es deu al fet que algú trenqués l'àlgebra. Es deu a claus mal desades, nonces repetits, versions obsoletes de protocol, validacions desactivades i comparacions ingènues. L'atacant ataca l'implementador, no l'algorisme.

Un esquema té n bits de seguretat quan el millor atac conegut requereix de l'ordre de 2^n operacions. No és el mateix que la mida de la clau: RSA amb clau de 2048 bits ofereix aproximadament 112 bits de seguretat, perquè factoritzar és més fàcil que provar totes les claus.

Els nombres grans no signifiquen res fins que s'aterren. Suposem una màquina imaginària capaç de provar mil milions de claus per segon (10^9), i suposem que n'ajuntem mil milions, d'aquestes màquines (10^18 claus per segon, molt per damunt de tota la capacitat de còmput del planeta):

Onze bilions d'anys davant dels ~13.800 milions d'anys d'edat de l'univers. I cada bit addicional duplica aquest nombre: 256 bits no és «el doble de segur» que 128, és 2^128 vegades més.

La conclusió pràctica és alliberadora: la mida de clau no és el problema. Si fas servir AES-128 o AES-256, la força bruta contra la clau està descartada per sempre amb tecnologia clàssica. Quan llegeixis que «han trencat un xifratge», gairebé sempre significa una d'aquestes cinc coses:

1. La clau es va derivar d'una contrasenya feble (03-04).
2. La clau estava desada on l'atacant va arribar (03-06).
3. Es va fer servir un mode o algorisme obsolet (ECB, RC4, MD5).
4. Es va repetir un nonce o es va reutilitzar material de clau (03-02).
5. Es va trencar la implementació: canal lateral, validació desactivada, error de farciment.

I AES-256 davant d'AES-128? Tria 256 quan la dada hagi de continuar sent confidencial durant dècades o quan una norma sectorial ho exigeixi; el cost de rendiment és petit. Per a l'ús general de Nimbus, qualsevol dels dos està fora de l'abast de qualsevol adversari.

Tota la criptografia descansa a poder generar valors que l'atacant no pugui predir: claus, nonces, sals, identificadors de sessió, tokens de recuperació de contrasenya. Si aquests valors són endevinables, l'algorisme és irrellevant: l'atacant no trenca res, simplement regenera el teu secret.

Python té dos generadors i triar malament és una fallada de seguretat real:

Sortida (diferent a cada execució, per definició):

Explicació de cada línia:

• random.choice fa servir el Mersenne Twister, un generador excel·lent per a estadística i catastròfic per a seguretat: és determinista i el seu estat intern es pot reconstruir observant prou sortides. Si Nimbus generés amb ell els tokens de «he oblidat la contrasenya», un atacant que demanés uns quants tokens per al seu propi compte podria predir el de la Sara.
• secrets.token_urlsafe(32) demana 32 bytes al generador segur del sistema operatiu i els codifica en Base64 segur per a URL. Compte: els 32 són bytes d'entropia, no caràcters de sortida.
• secrets.token_bytes(32) retorna bytes crus: és la manera correcta de generar una clau simètrica de 256 bits des de zero.
• secrets.randbelow(1_000_000) dona un enter uniforme sense el biaix que introduiria un % 1000000 sobre un nombre aleatori gran. El format :06d conserva els zeros a l'esquerra: 048217 és un codi vàlid.

Cas històric. El 2013 es va descobrir que una fallada en el generador de nombres aleatoris de determinades aplicacions Android feia que les claus de signatura de transaccions es repetissin. Amb dues signatures que compartissin aquell valor, la clau privada quedava exposada amb àlgebra elemental. L'algorisme era correcte i estava ben implementat. L'aleatorietat no ho era, i això va bastar.

Regla operativa per a Nimbus, sense excepcions: qualsevol valor que l'atacant no hagi d'endevinar es genera amb secrets (o amb l'equivalent de la plataforma: crypto.getRandomValues al navegador, crypto/rand a Go). Mai amb random, mai amb l'hora, mai amb un comptador, mai amb un UUID versió 1.

Abans d'entrar en els algorismes, aquest és el recorregut i quina peça aporta cada lliçó:

La lògica de la seqüència: el simètric resol la confidencialitat però deixa oberta la distribució de la clau; l'asimètric resol la distribució però és lent, cosa que obliga a combinar-los; els hashos i els MAC aporten la integritat que el xifratge no dona; els protocols són la manera correcta d'assemblar tot això; la PKI respon a «de qui és aquesta clau pública?»; i l'última lliçó ho aplica de punta a punta al sistema de Nimbus.

Tanca la lliçó un inventari honest: en dos mòduls hem recolzat defenses sobre criptografia sense explicar-la. Aquesta taula és el deute que el mòdul 3 ve a pagar.

L'última fila és la més eloqüent. En el cas de ransomware de Nimbus no va fallar cap primitiva criptogràfica: va fallar que una clau estava desada on no havia d'estar. És la tesi que governarà 03-06 i que convé interioritzar des d'avui: la matemàtica aguanta; la gestió és el que es trenca.

Errors conceptuals

1. Anomenar «encriptat» una cosa codificada en Base64. És l'error número u. Base64 i hexadecimal són transport, no protecció. Aplica la prova de butxaca de l'apartat 2.
2. Creure que xifrar aporta integritat. No l'aporta tret que facis servir xifratge autenticat. Un atacant pot alterar el text xifrat de manera controlada en modes antics.
3. Confondre hash amb xifratge. «Xifrem les contrasenyes» és una frase incorrecta i perillosa: si es poguessin desxifrar, l'atacant que roba la clau les tindria totes. Les contrasenyes es deriven amb una funció lenta i unidireccional (03-04).
4. Pensar que un algorisme secret és més segur. Kerckhoffs diu justament el contrari i l'experiència d'un segle ho confirma.
5. Obsessionar-se amb la mida de clau. Discutir AES-128 davant d'AES-256 mentre la clau viu en un fitxer .env del repositori és optimitzar la part que no falla.
6. Suposar que la criptografia substitueix el control d'accés. Són capes diferents. L'IDOR de 01-01 passava sobre una connexió TLS impecable.

Errors d'implementació

7. Fer servir random per a material de seguretat. Tokens, sals, nonces, claus: sempre secrets.
8. Comparar secrets amb ==. Obre un canal lateral de temporització. Es fa servir hmac.compare_digest.
9. Escriure la teva pròpia primitiva «perquè és un XOR senzill». No.
10. Copiar el primer fragment que apareix en un cercador. Bona part del codi criptogràfic que circula en fòrums és del 2011 i fa servir ECB, MD5 o IV fixos.

Consells pràctics

• Abans de triar algorisme, escriu en una frase quina propietat necessites: confidencialitat, integritat, autenticitat, no-repudi o frescor? La taula de l'apartat 1 et dona la primitiva gairebé sola.
• Escriu també davant de qui protegeixes. Xifrar el disc d'un servidor no defensa d'una API compromesa, i saber-ho evita comprar tranquil·litat falsa.
• Mantén una regla d'equip: el codi criptogràfic el revisen sempre dues persones, encara que el canvi sembli trivial.
• Consulta fonts vigents per a paràmetres i mides (NIST SP 800-57, les guies del CCN-CERT i ENISA, el full de ruta d'OWASP). Els valors concrets caduquen; els principis no.

Per a cada situació real de Nimbus, indica: (a) quina operació s'està aplicant —codificar, xifrar, calcular un hash o ofuscar—; (b) quina propietat de seguretat aporta realment; (c) si és adequada per a la finalitat declarada i, si no ho és, què s'hauria de fer.

1. El token de sessió que la SPA desa conté el correu de l'usuari en Base64, «perquè no es vegi a simple vista».
2. El Rubén envia a un client un fitxer ZIP protegit amb contrasenya i li envia la contrasenya pel mateix correu.
3. L'Iván desa a la base de dades el resultat de sha256(contrasenya).
4. L'adjunt d'una clínica es puja al bucket A-05 xifrat amb AES-GCM i la clau és en un gestor de secrets.
5. La Lucía publica, al costat de la còpia de seguretat nocturna, un fitxer .sha256 amb l'empremta de l'arxiu.
6. El JavaScript de la SPA està minificat i amb noms de variable d'una lletra, «perquè ningú no entengui la lògica de preus».

Aquest és el codi real que Nimbus fa servir per als enllaços de recuperació de contrasenya:

Es demana: (a) identifica els tres problemes marcats i explica l'atac concret que habilita cadascun; (b) estima quants intents necessitaria un atacant que coneix el correu de la Sara i el minut aproximat en què va demanar la recuperació; (c) reescriu la funció correctament, explicant cada decisió; (d) indica quines altres dues mesures, alienes a la generació del token, hauria de tenir aquest flux.

Per a cada requisit de Nimbus, digues quina propietat es necessita, quina primitiva la proporciona i en quina lliçó del mòdul s'estudia. No cal codi.

1. Que la consultora externa (A-19) no pugui llegir el contingut de les còpies que custodia.
2. Que Nimbus pugui demostrar davant d'un client, mesos després, que va ser aquell client qui va cancel·lar una reserva.
3. Que l'API detecti si un webhook de la passarel·la de pagament va ser fabricat per un tercer.
4. Que un atacant que gravi avui el trànsit xifrat de l'app mòbil no el pugui llegir si d'aquí a dos anys roba la clau privada del servidor.
5. Que un adjunt descarregat del bucket no es pugui reutilitzar demà amb la mateixa URL.
6. Que, si roben el bolcat de la taula de credencials, les contrasenyes no es puguin recuperar en un termini útil.

Exercici 1

Exercici 2

(a) Els tres problemes:

1. random.seed(int(time.time())) — se sembra el generador amb l'hora en segons. L'espai de llavors d'un dia sencer són 86.400 valors. Un atacant que sàpiga el dia reprodueix tots els tokens possibles.
2. random.randint(100000, 999999) — dues fallades: fa servir random (predictible) i només hi ha 900.000 valors possibles, uns 20 bits. És força bruta trivial fins i tot sense conèixer la llavor.
3. base64.b64encode(...) — el token no està protegit: conté el correu en clar per a qualsevol i, a més, revela el format intern, cosa que facilita fabricar candidats.

(b) Estimació. Si l'atacant coneix el correu i el minut aproximat, té ~60 llavors candidates. Cada llavor determina de manera determinista la primera sortida de randint, així que produeix ~60 tokens candidats. Amb reintents automatitzats, encerta en segons. Ni tan sols cal explorar els 900.000: la sembra per temps destrueix tota l'entropia.

(c) Versió correcta:

Decisions: entropia suficient i de font segura; el token no conté dades (és opac, no revela el correu); s'emmagatzema amb hash; caduca en 15 minuts; és d'un sol ús.

(d) Altres dues mesures: (1) resposta idèntica existeixi o no el compte —«si el correu està registrat, rebràs un enllaç»— per no permetre enumeració d'usuaris; (2) límit de taxa per correu i per IP, més registre de l'esdeveniment per a alerta (02-04). Una tercera de desitjable: invalidar totes les sessions actives en completar el canvi.

Exercici 3

Has obert la caixa negra. Ara tens el mapa que faltava: cada propietat de seguretat té la seva primitiva —confidencialitat al xifratge, integritat al hash i al MAC, autenticitat i no-repudi a la signatura, frescor al nonce, i l'acord de clau a l'intercanvi— i també saps el que la criptografia no fa: no protegeix de qui té la clau, no amaga metadades, no dona disponibilitat i no substitueix el control d'accés. Distingeixes amb precisió codificar, xifrar, calcular un hash i ofuscar, i tens una prova de butxaca per no tornar a confondre-les: ho puc desfer sense cap secret? Has vist en Base64 que codificar no protegeix res i en un Cèsar trencat en 25 intents què significa un espai de claus insuficient.

De la història te'n portes tres lliçons que continuen intactes: l'espai de claus ha de ser astronòmic, el material de clau no es reutilitza mai —tornarà amb els nonces a la lliçó següent— i l'atacant ataca el procediment i la implementació, no l'àlgebra. Sobre aquesta base has recuperat Kerckhoffs: l'algorisme és públic i el secret és només la clau, d'on surt la regla que governa el mòdul sencer —no implementis mai criptografia a mà—. Saps situar un adversari en el seu model, distingir un atac de força bruta d'un de canal lateral, i per què 2^128 posa la força bruta fora de l'univers, cosa que trasllada el problema real a les cinc causes de sempre: contrasenyes febles, claus mal desades, algorismes obsolets, nonces repetits i implementacions defectuoses. I has interioritzat el fonament invisible: secrets, mai random, perquè una mala font d'aleatorietat trenca qualsevol algorisme per perfecte que sigui.

Finalment has posat números al deute: onze elements de Nimbus que fa dos mòduls que funcionen gràcies a criptografia sense explicar, des de l'HMAC del webhook fins a les URL signades de 120 segons, i una fila final que resumeix la tesi del mòdul: en el ransomware de 02-06 no va fallar cap primitiva, va fallar on vivia una clau.

A Criptografia Simètrica (03-02) comencem per la primitiva més antiga i més usada: una única clau compartida que xifra i desxifra. Veuràs per què AES és l'estàndard, què és un mode d'operació i per què ECB està prohibit, quin paper hi juga el nonce i per què repetir-lo és catastròfic, i com es xifra correctament un adjunt de Nimbus amb AES-GCM lligant-lo al seu tenant_id. I acabaràs amb el problema que el simètric no pot resoldre sol —com fer arribar la clau a l'altre extrem—, que és exactament el que motiva la lliçó següent.