Tanquem el mòdul de fonaments amb la lliçó més important de totes per a la teva pràctica professional: la que defineix com es pensa en criptografia. El 1883, el criptògraf Auguste Kerckhoffs va formular un principi que continua governant la disciplina: un sistema criptogràfic ha de ser segur encara que l'adversari en conegui tot, excepte la clau. D'aquest principi es deriven conseqüències molt pràctiques: per què mai has d'inventar el teu propi xifratge, per què la "seguretat per obscurantisme" fracassa com a única defensa (amb cadàvers il·lustres: DVD CSS, GSM A5, targetes Mifare), per què fins i tot una comparació de cadenes pot filtrar un secret (atacs de canal lateral), i quines llibreries mereixen la teva confiança. La lliçó acaba amb les regles d'or que anirem reforçant durant tot el curs.

1. El principi de Kerckhoffs: enunciat i implicacions
2. Seguretat per obscurantisme: per què falla com a única defensa
3. "No inventis la teva pròpia criptografia": tres desastres històrics
4. Atacs de canal lateral: quan la implementació traeix
5. Cas MediNube: comparar secrets amb secrets.compare_digest
6. Criptoagilitat: dissenyar per poder canviar
7. Llibreries serioses enfront de primitives fetes a mà
8. Les regles d'or del curs

L'enunciat modern del principi de Kerckhoffs:

Un sistema criptogràfic ha de ser segur fins i tot si tot sobre el sistema —excepte la clau— és de coneixement públic.

Claude Shannon, pare de la teoria de la informació, ho va reformular dècades després de forma encara més taxativa: "l'enemic coneix el sistema" (màxima de Shannon). Dissenya sempre sota aquesta suposició. Per què és una bona idea concentrar tot el secret en la clau, en lloc de repartir-lo també per l'algorisme?

• Les claus són fàcils de protegir i substituir; els algorismes, no. Una clau són 32 bytes: es desa en un gestor de secrets, es rota en minuts si es filtra. Un algorisme és a cada binari desplegat, a cada còpia del codi, a la memòria de cada desenvolupador que hi ha treballat. Quan "se'n filtra l'algorisme" (i sempre acaba passant: enginyeria inversa, empleats que marxen, repositoris exposats), no el pots "rotar" sense reconstruir tot el sistema.
• Només l'escrutini públic dona confiança. Un algorisme secret l'han revisat, amb sort, cinc persones de la teva empresa. AES porta des de 1998 sent atacat pels millors criptoanalistes del planeta, amb reputació i carreres en joc per trobar-hi esquerdes — i continua dempeus. La seguretat d'un algorisme no es demostra: se sobreviu, i només se sobreviu als atacs que efectivament es proven.
• Separa la seguretat del desplegament. Si la seguretat exigeix que l'atacant no sàpiga "com funciona", aleshores cada empleat, contractista, còpia de seguretat del repositori i bolcat de memòria és un punt de fallada catastròfic i irrecuperable. Si només la clau és secreta, la superfície a protegir és mínima i està ben definida.

Fixa't que el principi no diu que hagis de publicar el teu disseny, ni que el secret addicional destorbi. Diu que la seguretat no pot dependre d'aquest secret. És una prova mental que pots aplicar a qualsevol sistema: "Si demà l'atacant llegeix tot el nostre codi i documentació, continua sense poder accedir a les dades?" Si la resposta és no, el sistema està trencat avui; només que encara no ho saps.

La seguretat per obscurantisme és confiar que l'atacant no descobreixi com funciona alguna cosa: l'algorisme casolà, l'endpoint no documentat, el paràmetre secret, el port no estàndard. Falla com a defensa principal per tres raons estructurals:

1. L'obscurantisme no es pot mesurar. D'una clau de 128 bits sabem exactament quant costa trencar-la. Quant "costa" descobrir el teu algorisme casolà? Potser una tarda amb un descompilador. No pots raonar sobre allò que no pots quantificar.
2. L'obscurantisme no es pot recuperar. Una clau filtrada es rota. Un secret de disseny filtrat està filtrat per sempre.
3. L'obscurantisme s'erosiona sol. Cada nou empleat, cada proveïdor, cada anàlisi de trànsit, cada binari distribuït redueix el secret. El temps juga en contra.

Matís professional important: l'obscurantisme com a capa addicional sobre un disseny sòlid no és dolent (no documentar públicament la topologia interna de la teva xarxa afegeix fricció real a l'atacant i no costa res). El que és indefensable és que sigui l'única barrera, o que substitueixi una barrera real. En la revisió de codi de la lliçó 01-02 ja vas veure una seguretat per obscurantisme de manual: Base64 com a "protecció" funciona exactament fins que algú mira.

La conseqüència pràctica número u del principi de Kerckhoffs per a un desenvolupador: no dissenyis ni implementis els teus propis algorismes criptogràfics per a producció. No és una qüestió d'humilitat, sinó d'estadística: els algorismes secrets i propietaris tenen un historial de derrotes gairebé perfecte. Tres casos famosos, els tres amb el mateix patró:

El sistema de xifratge dels DVD de vídeo (1996) feia servir un algorisme secret amb claus de 40 bits, protegit per acords de confidencialitat. El 1999 va ser objecte d'enginyeria inversa (a partir d'un reproductor de programari) i es va publicar DeCSS. L'anàlisi va revelar que el disseny era tan feble que l'atac efectiu costava ~2^25 operacions — segons en un PC de l'època. Va quedar trencat per sempre: no es pot "actualitzar l'algorisme" de milions de discos i reproductors ja fabricats.

Els algorismes de xifratge de les trucades GSM (anys 80-90) es van dissenyar en secret per comitès del sector. Es van filtrar i reconstruir per enginyeria inversa als anys 90, i el criptoanàlisi públic els va enderrocar: A5/2 (la variant d'exportació, deliberadament debilitada) es trenca en temps real; per a A5/1 es van publicar taules precalculades que permeten desxifrar trucades amb maquinari domèstic. Milers de milions de telèfons van quedar exposats durant dècades per la inèrcia del desplegament.

La targeta sense contacte més venuda del món (transport públic, accessos a edificis) feia servir CRYPTO1, un xifratge propietari i secret amb claus de 48 bits. El 2008, investigadors van reconstruir l'algorisme analitzant el xip al microscopi i van trobar debilitats estructurals: la clau es recupera en segons amb un lector de butxaca. Sistemes de transport i control d'accés de ciutats senceres van haver de migrar-se.

El patró es repeteix, punt per punt: (1) el disseny es manté en secret → (2) se li fa enginyeria inversa, sempre → (3) en quedar exposat, el criptoanàlisi públic troba en mesos les debilitats que el disseny tancat va incubar durant anys → (4) el cost de reemplaçament és brutal perquè l'algorisme està fos en el desplegament. Compara-ho amb AES: disseny publicat, concurs internacional (NIST, 1997-2000), quinze finalistes destrossant-se mútuament, i vint-i-cinc anys d'escrutini mundial posterior. Aquesta asimetria de revisió és tota la diferència.

I la versió quotidiana de l'error no és dissenyar un xifratge nou, sinó coses com: "XOR amb una contrasenya repetida", "AES però implementat a mà llegint l'especificació", "un hash casolà barrejant MD5 dues vegades". Tot això és inventar criptografia pròpia. La regla inclou implementar primitives conegudes: l'especificació d'AES cap en unes quantes pàgines, però implementar-la sense fuites de canal lateral (apartat següent) és feina d'especialistes.

Fins ara hem parlat de trencar les matemàtiques. Però hi ha una família d'atacs que ignora les matemàtiques i observa l'execució física del sistema: quant triga, quanta energia consumeix, què emet electromagnèticament, com es comporta la memòria cau de la CPU. Són els atacs de canal lateral (side-channel). Aquí només necessites el concepte i el seu exemple més accessible: l'atac de temps (timing attack) sobre una comparació no constant.

Pensa en com compara cadenes l'operador == de Python: recorre els caràcters i s'atura a la primera diferència. Això significa que comparar "AAAA" == "BXXX" triga una mica menys que "AAAA" == "ABXX", perquè la primera comparació falla en el caràcter 1 i la segona en el 2. La diferència són nanosegons... però és mesurable estadísticament repetint la petició milers de vegades, especialment en una xarxa local o entre contenidors.

L'atac resultant contra un endpoint que compara un token secret amb ==:

1. L'atacant prova A000..., B000..., C000... i mesura temps. La variant el primer caràcter de la qual coincideix amb el secret triga sistemàticament una mica més (la comparació avança un caràcter més abans de fallar).
2. Fixat el primer caràcter, repeteix amb el segon. I així successivament.
3. Resultat: en lloc d'endevinar el token sencer (impossible: 2^128), el reconstrueix caràcter a caràcter — d'un cost exponencial a un cost lineal. Els 128 bits d'entropia de la lliçó anterior queden anul·lats per la implementació.

Aquest és el missatge profund de l'apartat: la seguretat teòrica es pot evaporar en la implementació. I és una altra cara de "no inventis la teva pròpia criptografia": les llibreries serioses implementen les seves operacions en temps constant (el temps no depèn de les dades secretes), un art ple de trampes (els compiladors "optimitzen" eliminant el temps constant, les memòries cau filtren accessos...). Altres canals laterals —consum elèctric, emissions electromagnètiques, ús de la memòria cau— segueixen la mateixa lògica i afecten sobretot el maquinari (targetes, HSM); per a tu, el canal que has de vigilar en el dia a dia és el temps.

Les clíniques integren els seus sistemes amb MediNube a través d'una API que autentica cada petició amb una clau d'API. En el codi heretat trobes això:

El == compara caràcter a caràcter i talla al primer error: el temps de resposta de l'endpoint depèn de quants caràcters inicials ha encertat l'atacant. Amb paciència i estadística, la clau de la Clínica Sol s'extreu caràcter a caràcter, com acabem de veure. La correcció és una línia:

Desglossament:

• secrets.compare_digest(a, b) compara les dues cadenes senceres sempre, trigui el que trigui: el temps no revela en quina posició difereixen. (Accepta dos str ASCII o dos bytes.)
• La resta del raonament de la lliçó 01-03 continua aplicant-se: la clau ha d'haver nascut de secrets.token_urlsafe(32), i l'endpoint ha de, a més, limitar intents i registrar errors — defensa en profunditat.
• Fes servir compare_digest sempre que comparis un valor secret rebut de l'exterior: claus d'API, tokens de recuperació, signatures de webhooks (ho reutilitzarem amb HMAC al mòdul 3). Per a comparacions sense secrets (un if estat == "actiu"), el == normal és perfectament correcte.

Nota: desar les claus d'API en un diccionari en el codi, com en l'exemple, és un altre deute de seguretat de MediNube — la gestió de secrets s'aborda de ple al mòdul 6. I com sempre: un desplegament sanitari real exigeix revisió per part de professionals de seguretat i compliment (RGPD).

Els algorismes criptogràfics envelleixen: MD5 i SHA-1 van caure, DES va quedar petit, i la computació quàntica obligarà a migracions massives (mòdul 6). La pregunta no és si hauràs de canviar d'algorisme durant la vida del teu sistema, sinó quant et costarà. La criptoagilitat és dissenyar perquè aquest canvi sigui barat:

• Etiqueta les dades amb el seu algorisme i versió. Cada dada xifrada o hashejada ha de portar metadades de amb què es va produir (v1 = AES-256-GCM, v2 = el que vingui). Així conviuen formats durant una migració i el codi sap com tractar cada registre. Els formats seriosos ja ho fan: ho veuràs en els hashes de contrasenyes ($argon2id$..., mòdul 3) i en les capçaleres de JWT (mòdul 6).
• Centralitza la criptografia. Un únic mòdul/servei intern (medinube.crypto) que la resta de l'aplicació consumeix. Canviar d'algorisme = canviar un lloc, no quaranta.
• No et sobredimensionis per por, però deixa marge on és gratis: camps de base de dades que admetin hashes més llargs, protocols amb camp de versió des del dia u.
• El cas Mifare/GSM/CSS també és una lliçó de manca de criptoagilitat: el seu cost més gran no va ser el criptoanàlisi, sinó que l'algorisme trencat estava fos en maquinari impossible d'actualitzar.

Si no cal implementar primitives a mà, què s'utilitza? Llibreries mantingudes per especialistes, auditades i amb API difícils de fer servir malament:

Criteris per confiar en una llibreria criptogràfica (aplica'ls a qualsevol llenguatge):

• Manteniment actiu i equip identificable; historial públic de gestió de vulnerabilitats (CVE corregits amb rapidesa).
• Auditories externes publicades, o ús massiu sota escrutini real.
• API d'alt nivell que tria per tu els paràmetres segurs (la millor API és la que no et deixa triar malament). Desconfia de llibreries que et demanen decidir-ho tot.
• Implementacions en temps constant documentades.

I l'antipatró contrari: el fragment de Stack Overflow amb criptografia casolana, el paquet crypto-utils-fast amb 200 descàrregues, o "ja ho faig jo amb XOR que és més ràpid". A MediNube, la decisió d'arquitectura que prenem avui és: Python + cryptography (pyca) per a tot el curs, amb secrets/os.urandom per a l'aleatorietat.

Tot el mòdul 1 es condensa en aquestes regles. Les anirem reforçant (i ampliant amb matisos) durant la resta del curs; considera-les el contracte del criptògraf aplicat:

1. No inventis ni implementis la teva pròpia criptografia. Fes servir algorismes estàndard a través de llibreries serioses (cryptography, libsodium). Això inclou no "millorar" ni combinar primitives de forma creativa.
2. Assumeix que l'enemic coneix el sistema (Kerckhoffs/Shannon). Tota la seguretat ha de residir en les claus; l'obscurantisme, com a molt, és una capa extra, mai la defensa.
3. Tota l'aleatorietat de seguretat surt del CSPRNG. En Python: secrets o os.urandom. Mai random, mai marques de temps, mai ingredients casolans.
4. Codificar no és xifrar. Base64, hex i companyia són transport. Si no hi ha clau secreta, no hi ha confidencialitat.
5. L'entropia mana. Una clau val els bits d'entropia reals del seu origen, no la seva longitud aparent. Mínim seriós avui: 128 bits; el nostre estàndard: 256.
6. Compara secrets en temps constant (secrets.compare_digest). La implementació pot trair les matemàtiques.
7. Identifica l'objectiu abans que l'eina. Confidencialitat, integritat, autenticitat, no repudi? La resposta tria el mecanisme, no a l'inrevés.
8. Dissenya amb criptoagilitat. Versiona formats, centralitza la criptografia, prepara't per migrar d'algorisme.
9. La criptografia no substitueix la resta de la seguretat. Control d'accés, límits d'intents, auditoria, gestió de secrets i revisió professional (encara més amb dades sanitàries i el RGPD) continuen sent imprescindibles.

• Citar malament Kerckhoffs: "cal publicar l'algorisme". El principi no obliga a publicar res; exigeix que la seguretat no depengui del secret del disseny. Pots mantenir la teva arquitectura confidencial — però el teu sistema ha de resistir com si fos pública.
• L'extrem contrari: menysprear tot l'obscurantisme. No exposar versions de programari o rutes internes és higiene raonable. El pecat és comptar-la com a control de seguretat en lloc de com a fricció addicional.
• "Faig servir AES, així que compleixo la regla 1". Fer servir un algorisme estàndard malament (mode inadequat, IV repetit, clau derivada d'una contrasenya fluixa) també trenca la regla. Per això els mòduls 2 i 6 dediquen tant espai al com.
• Sprinkle-crypto: crides criptogràfiques disperses per tot el codi, cadascuna amb els seus paràmetres. Quan toqui migrar (regla 8), serà arqueologia. Centralitza des del primer dia.
• Canviar == per compare_digest a tot arreu "per si de cas". Només té sentit amb valors secrets comparats contra entrada externa; usar-lo per a lògica normal només enfosqueix el codi. Entén el perquè de cada regla, no el cargo-cult.
• Consell: converteix les regles d'or en checklist de revisió de codi del teu equip. La majoria de vulnerabilitats criptogràfiques reals (ho veuràs a la lliçó 06-04) són violacions directes d'una d'aquestes nou línies.

Exercici 1. Un proveïdor ofereix a MediNube un mòdul de "xifratge ultrasegur d'historials" amb aquest argument comercial: "El nostre algorisme és de disseny propi i confidencial, la qual cosa afegeix una capa de seguretat: en no conèixer-lo, cap hacker el pot atacar. Ha superat les nostres proves internes de qualitat durant 5 anys sense ser trencat." Redacta una resposta tècnica (4-6 frases) assenyalant les fallades de l'argument, citant el principi de Kerckhoffs i almenys un cas històric.

Exercici 2. Aquest endpoint de MediNube verifica el token que un webhook extern envia en una capçalera. Assenyala les dues violacions de les regles d'or i corregeix-les:

Exercici 3. Per a cada decisió, indica si és un ús acceptable de l'obscurantisme com a capa addicional o una violació del principi de Kerckhoffs, i per què: (a) MediNube no documenta públicament les rutes internes de la seva API d'administració; (b) els historials es "protegeixen" amb un XOR la màscara del qual és al codi font, i es confia que ningú descompili l'aplicació; (c) l'equip decideix no publicar al blog corporatiu quin algorisme de xifratge fan servir, tot i que és AES-256-GCM amb claus ben gestionades; (d) el token de sessió es diu X-Custom-Data en lloc d'Authorization "per despistar", i per la resta és un token aleatori de 256 bits ben verificat.

Solució 1. Resposta model: "L'argument inverteix el principi de Kerckhoffs: un sistema ha de ser segur suposant que l'atacant coneix l'algorisme, perquè el secret del disseny sempre acaba perdent-se (enginyeria inversa, filtracions) i, a diferència d'una clau, no es pot rotar. Que no el coneguin no impedeix atacar-lo: DVD CSS, GSM A5 i Mifare Classic eren algorismes propietaris i secrets, i els tres van ser reconstruïts per enginyeria inversa i trencats tan bon punt van rebre anàlisi pública. 'Cinc anys sense trencar-se' en proves internes només vol dir que ningú qualificat ho ha intentat: la confiança criptogràfica neix de l'escrutini públic massiu, com el que ha rebut AES des de 1998. Sol·licitem que el producte faci servir algorismes estàndard (p. ex. AES-256-GCM) mitjançant llibreries auditades; un disseny confidencial és, en si mateix, motiu de rebuig."

Solució 2. Violacions: (1) regla 3 — el token es genera amb random, un PRNG predictible (a més, amb només lletres ASCII: log2(52) ≈ 5,7 bits/caràcter, i el greu és la previsibilitat de Mersenne Twister); (2) regla 6 — la comparació amb == no és de temps constant i permet extreure el token caràcter a caràcter amb un atac de temps. Correcció:

(Bonus: en producció el token no viuria en una variable del codi sinó en un gestor de secrets — mòdul 6 —, i el mecanisme robust per a webhooks és signar el cos amb HMAC, que construirem al mòdul 3.)

Solució 3. (a) Acceptable: fricció extra sense cost; la seguretat real la donen l'autenticació i l'autorització de l'endpoint, no el secret de la ruta. (b) Violació clara: l'única barrera és que ningú miri el codi — no hi ha cap clau secreta gestionada com a tal, i el XOR amb màscara fixa ni tan sols és un xifratge seriós; trenca les regles 1, 2 i 4. (c) Acceptable: no publicar detalls és legítim; el sistema resisteix encara que se sàpiguen (AES ben usat no depèn del secret del "què"). És exactament la postura correcta davant Kerckhoffs: podria ser públic sense risc. (d) Acceptable però inútil i amb cost: la seguretat la dona el token de 256 bits ben verificat, no el nom de la capçalera; el "despistament" a penes frena ningú i complica la integració i el manteniment. No viola Kerckhoffs (la seguretat no depèn del truc), però és obscurantisme de valor gairebé nul.

Amb aquesta lliçó es tanca el mòdul de fonaments, i ja tens la mentalitat completa del criptògraf aplicat. Saps què persegueix la criptografia (confidencialitat, integritat, autenticitat i no repudi — lliçó 01-01), distingeixes amb rigor codificar, ofuscar i xifrar (01-02), saps d'on surt la imprevisibilitat que ho sosté tot i com generar-la correctament en Python (01-03), i ara tens el principi que governa el disseny: la seguretat rau en la clau, mai en el secret de l'algorisme, amb els seus corol·laris — no inventar criptografia pròpia, desconfiar de l'obscurantisme com a defensa, vigilar els canals laterals amb comparacions en temps constant, dissenyar amb criptoagilitat i recolzar-se en llibreries serioses. Les nou regles d'or condensen tot el mòdul; torna-hi cada vegada que dubtis, perquè la resta del curs no farà més que aprofundir-hi.

A MediNube, el balanç d'aquest mòdul és un bon punt de partida: hem desterrat el Base64-com-a-protecció, els tokens de recuperació ja neixen de secrets.token_urlsafe(32) i les claus d'API es comparen en temps constant. Però la necessitat central continua sense resoldre's: els historials de pacients com Ana Pérez continuen sense xifrar en disc. Al Mòdul 2: Criptografia Simètrica comencem a construir la solució de veritat — la llibreria cryptography entra en escena i, amb ella, els algorismes que protegeixen la major part de les dades del món: AES i ChaCha20, els seus modes d'operació, el xifratge autenticat (AEAD) i la derivació de claus. Ens veiem a la lliçó 02-01.