La lliçó anterior va acabar amb un problema sense sortida: l'app mòbil d'una fisioterapeuta i l'API de Nimbus necessiten una clau simètrica comuna, però l'únic canal que tenen entre elles és exactament el que volen protegir. Durant quatre mil anys aquest problema no va tenir solució; als anys setanta es va resoldre amb una idea que sona impossible el primer cop que se sent: fer servir dues claus diferents, una que es publica i una altra que no es comparteix mai. Aquesta lliçó desenvolupa aquesta idea —el parell de claus, RSA, la criptografia de corba el·líptica, l'intercanvi Diffie-Hellman i la forward secrecy, el xifratge híbrid que explica com funciona TLS de debò, i la signatura digital, l'única primitiva que dona no-repudi—. És important perquè pràcticament tot el que fa segura la web moderna, des d'HTTPS fins a les passkeys i la signatura del JWT de Nimbus, és criptografia asimètrica.

1. La idea del parell de claus
2. Què es fa amb la pública i què amb la privada
3. RSA: el problema difícil de la factorització
4. Criptografia de corba el·líptica: la mateixa seguretat amb claus molt més curtes
5. Intercanvi de claus Diffie-Hellman
6. Efímer, ECDHE i confidencialitat persistent
7. Xifratge híbrid: com es fa servir de debò
8. Signatura digital: què garanteix i en què es diferencia d'un MAC
9. Signar un rebut de reserva de Nimbus amb Ed25519
10. Inspeccionar un parell RSA amb openssl
11. La pregunta que queda oberta i l'amenaça quàntica

En un esquema asimètric es generen dues claus matemàticament relacionades:

• La clau pública: es pot publicar en un web, imprimir en una samarreta o enviar per correu sense xifrar. La seva difusió no compromet res.
• La clau privada: no surt mai del sistema que la va generar. Idealment ni tan sols és exportable, com passa a les passkeys de FIDO2 de 02-05.

La relació entre totes dues és de porta trampa: és fàcil calcular la pública a partir de la privada, i computacionalment inviable fer el camí invers. Tota la criptografia asimètrica es recolza en problemes matemàtics amb aquesta asimetria —multiplicar dos primers grans és trivial, factoritzar el producte no ho és—.

Això resol la distribució de cop: per rebre missatges xifrats n'hi ha prou de publicar la clau pública. I el nombre de claus deixa de créixer quadràticament: n participants necessiten n parells, no n·(n−1)/2 claus compartides. Amb 10.000 usuaris, 10.000 parells en lloc de cinquanta milions de claus.

Aquesta taula és la que més vegades es recorda malament, i equivocar-se aquí inverteix per complet les garanties:

La regla mnemotècnica: la clau privada és la que "tanca" la teva identitat i "obre" els teus missatges. Signes amb allò que només tens tu; desxifres amb allò que només tens tu.

L'error habitual és invertir-ho, i les seves conseqüències són diferents en cada direcció:

• «Xifrem amb la privada perquè només ho llegeixin els nostres». Fals i perillós: el que es xifra amb la privada ho desxifra qualsevol amb la pública, perquè la pública és pública. Això no és xifrar, és —conceptualment— signar.
• «Signem amb la pública». Impossible: si qualsevol pot signar, la signatura no acredita res.

Una conseqüència important per al disseny de Nimbus: en un sistema amb milers de clients, xifrar amb clau pública no és el que es fa habitualment; l'habitual és acordar una clau simètrica amb criptografia asimètrica i xifrar les dades amb ella (apartat 7). El xifratge asimètric directe es reserva per a dades molt petites, com una clau.

RSA (Rivest, Shamir i Adleman, 1977) va ser el primer esquema asimètric pràctic i continua sent omnipresent, especialment en certificats i signatures de tokens.

La intuïció del problema difícil. Multiplicar dos nombres primers grans és instantani:

El camí invers —donat n, trobar p i q— és fàcil amb nombres petits i esdevé inviable quan n té 2048 o 3072 bits (més de 600 dígits decimals). La clau pública conté n; la privada depèn de conèixer p i q. La seguretat d'RSA és exactament la dificultat de factoritzar.

Tres coses que cal saber d'RSA per fer-lo servir bé:

1. És lent, sobretot l'operació amb la clau privada (signar o desxifrar). Recorda la taula de rendiment de 03-02: unes mil operacions per segon davant de gigabytes per segon d'AES.
2. No pot xifrar dades grans. Amb RSA-2048 el límit físic és la mida del mòdul, i amb el farciment obligatori queden uns 190 bytes útils. No és una limitació pràctica que es pugui esquivar amb més claus: és estructural.
3. El farciment importa tant com l'algorisme. L'esquema antic PKCS#1 v1.5 té atacs coneguts. Avui es fa servir OAEP per xifrar i PSS per signar. Les llibreries serioses t'obliguen a triar-lo explícitament; no copiïs mai codi que faci servir PKCS1v15 per a xifratge nou.

La criptografia de corba el·líptica (ECC) es recolza en un problema difícil diferent: el logaritme discret sobre els punts d'una corba el·líptica. El seu gran avantatge pràctic és l'eficiència.

Llegeix bé la fila destacada: una clau ECC de 256 bits ofereix la mateixa seguretat que una RSA de 3072 bits. Això significa claus i signatures molt més petites, encaixades més ràpides i menys consum, cosa que importa especialment a l'app mòbil de Nimbus i a qualsevol dispositiu amb bateria.

Corbes que veuràs a la pràctica:

Ed25519 i X25519 són la parella recomanada per defecte per a codi nou. No perquè siguin «més matemàtiques», sinó perquè el seu disseny elimina la majoria de les decisions on un desenvolupador es podria equivocar: no hi ha farciment per triar, no hi ha corbes per validar a mà, i l'algorisme de signatura és determinista, cosa que evita la fallada històrica de les signatures ECDSA amb aleatorietat defectuosa (el mateix tipus de fallada que vam veure a 03-01 amb el generador d'Android).

Un advertiment de nomenclatura, perquè genera confusió constant: X25519 serveix per intercanviar claus, Ed25519 serveix per signar. Són corbes emparentades però no intercanviables, i les llibreries no et deixaran barrejar-les.

Aquest és el mecanisme que resol el problema amb què va tancar 03-02. Diffie-Hellman permet que dues parts que no s'han vist mai acordin un secret compartit parlant per un canal que l'atacant escolta sencer, sense que l'atacant pugui deduir el secret.

1. L'Ana i l'API acorden públicament un color base, diguem-ne groc. L'atacant el veu.
2. L'Ana tria en secret un color propi, vermell, i el barreja amb el groc: obté taronja, i l'envia. L'atacant veu el taronja.
3. L'API tria en secret blau, el barreja amb groc i obté verd, que envia. L'atacant veu el verd.
4. L'Ana barreja el verd rebut amb el seu vermell secret. L'API barreja el taronja rebut amb el seu blau secret. Tots dos obtenen el mateix marró.
5. L'atacant té groc, taronja i verd, i no pot obtenir el marró, perquè separar una barreja de pintures en els seus components és molt més difícil que barrejar-les.

Aquesta dificultat de «separar la barreja» és, en la matemàtica real, el problema del logaritme discret.

Dues precisions fonamentals:

• El secret compartit no es fa servir directament com a clau. Es passa per una funció de derivació (HKDF, de 03-02) per obtenir claus de xifratge amb el format i la separació de dominis correctes.
• Diffie-Hellman tot sol no autentica. Un atacant actiu pot fer un intercanvi amb cada extrem i situar-se al mig: és el clàssic MITM de 02-02. La solució és autenticar l'intercanvi amb una signatura digital avalada per un certificat —i aquí és on el mòdul enllaça amb TLS (03-05) i amb la PKI (03-06)—.

A TLS veuràs les sigles ECDHE: Elliptic Curve Diffie-Hellman Ephemeral. La paraula clau és l'última.

• Estàtic: les parts fan servir sempre el mateix parell de claus per a l'intercanvi.
• Efímer: es genera un parell nou per a cada sessió i es destrueix en acabar.

D'aquí surt la propietat més valuosa de la criptografia moderna:

Confidencialitat persistent (forward secrecy, també anomenada perfect forward secrecy): comprometre la clau privada de llarga durada del servidor no permet desxifrar les sessions passades.

Val la pena aterrar-ho a Nimbus amb un escenari concret:

1. Un atacant grava durant mesos tot el trànsit xifrat entre les apps mòbils i l'API. No pot llegir res. Ho guarda igualment.
2. Dos anys després, aconsegueix la clau privada del servidor de Nimbus —per una intrusió, una còpia mal esborrada o una ordre judicial en una altra jurisdicció—.

Aquesta és la raó per la qual TLS 1.3 va eliminar de l'estàndard tots els modes sense forward secrecy i per la qual l'intercanvi de clau RSA està prohibit en configuracions modernes (03-05). I és també la resposta directa a l'escenari de «collir ara, desxifrar després» de l'apartat 11.

Ja tenim les dues peces i les seves limitacions creuades:

• L'asimètric resol la distribució però és lent i no pot amb dades grans.
• El simètric és rapidíssim però no pot distribuir la seva pròpia clau.

La solució és combinar-los, i s'anomena xifratge híbrid. És el patró que hi ha darrere de TLS, de PGP, del xifratge de sobre del núvol i de gairebé tota la resta:

Per què això és el correcte i no un pedaç:

• Es xifren 190 bytes amb l'asimètric en lloc de 3 MB. El cost de la part lenta és constant i menyspreable.
• La mida del missatge deixa de tenir límit.
• Si es fa servir ECDHE al pas 3 en lloc de xifrar la clau, s'obté a més forward secrecy.

Aquest mateix patró, aplicat a l'emmagatzematge en lloc de a la comunicació, s'anomena xifratge de sobre (envelope encryption): una clau de dades xifra l'objecte i una clau mestra del KMS xifra la clau de dades. És com xifra Nimbus els adjunts del bucket A-05, i es desenvolupa a 03-06 i 03-07.

Signar no és xifrar. Una signatura digital no amaga res: el missatge viatja llegible i la signatura s'hi adjunta. El que aporta és prova d'origen.

El flux real —i és important, perquè explica per què signar un fitxer de 4 GB és ràpid—:

No es signa el missatge: es signa el seu hash. Per això el cost de signar no depèn de la mida del fitxer, i per això una funció hash trencada (MD5, SHA-1) trenca també la signatura: si l'atacant troba dos documents amb el mateix hash, una signatura vàlida per a un ho és per a l'altre. Els hashos s'estudien a 03-04.

La diferència decisiva és el no-repudi. Si Nimbus i la passarel·la comparteixen una clau HMAC, un webhook amb MAC vàlid demostra que el va generar algun dels dos, i com que Nimbus també té la clau, no serveix com a prova davant d'un tercer: Nimbus podria haver-lo fabricat. Amb una signatura, en canvi, només la clau privada de la passarel·la pot produir-la, i Nimbus no la té; per això la signatura sí que és prova.

La regla pràctica: fes servir MAC quan les dues parts es coneixen, comparteixen un secret i només necessiten detectar manipulació; fes servir signatura quan el verificador pot ser qualsevol o quan necessites prova oposable.

Nimbus vol emetre rebuts de reserva verificables: la clínica ha de poder comprovar, mesos després, que aquell rebut el va emetre Nimbus i no ha estat alterat.

Sortida:

El que cal comprendre d'aquest codi:

• La clau pública en PEM ocupa tres línies. Compara-la amb una clau pública RSA-3072, que n'ocupa unes quinze. Aquest és l'avantatge de mida d'ECC de l'apartat 4.
• La serialització canònica és imprescindible. sort_keys=True fixa l'ordre de les claus i separators=(",", ":") elimina els espais. Sense això, dues serialitzacions del mateix objecte produirien bytes diferents i la signatura fallaria per un motiu que no és un atac. És la fallada d'integració número u amb signatures sobre JSON.
• privada.sign(missatge) fa internament el hash. Ed25519 fa servir SHA-512 per dins; tu no toques aquesta part, i aquest és justament l'objectiu.
• verify no retorna True/False: llança InvalidSignature. És un disseny deliberat, perquè sigui impossible ignorar el resultat per descuit amb un if mal escrit. No capturis mai aquesta excepció sense actuar.
• Canviar l'import invalida la signatura. Un sol camp modificat i la verificació falla: això és integritat i autenticitat juntes.
• El rebut porta pacient_ref, no el nom. Un document signat és difícil de retirar del món i sol acabar arxivat durant anys. Minimitza les dades personals que conté (02-04; el marc legal, a 06-03).

Nota de validació professional. Si un rebut signat s'ha de fer servir com a prova amb efectes legals o fiscals a Espanya, la signatura criptogràfica és condició necessària però no suficient: la normativa de signatura electrònica i factura electrònica imposa requisits addicionals sobre el certificat, el prestador i la conservació. Valida el disseny amb assessoria jurídica abans de donar-li valor probatori; els aspectes normatius es tracten al mòdul 6.

Encara que per a codi nou la recomanació sigui ECC, RSA continua sent a la majoria de certificats i a molts emissors de JWT, així que cal saber manejar-lo.

Sortida del pas 3 (retallada):

Sortida del pas 4:

Lectura d'aquests resultats:

• El mòdul és l'n = p·q de l'apartat 3, aquí de 3072 bits (384 bytes). És públic. Els factors p i q són només a la clau privada.
• L'exponent públic 65537 és el valor estàndard: primer, petit i amb pocs bits a u, cosa que fa ràpida l'operació pública. Veure'l diferent és un senyal d'alarma.
• 2484 bytes davant de 119. La mateixa taula de l'apartat 4, feta visible al sistema de fitxers.
• chmod 600 no és decoratiu. Una clau privada llegible per tots els usuaris del sistema és una troballa d'auditoria habitual, i tornarà a aparèixer a 03-06 i a 05-06.
• No facis servir mai -des3 ni contrasenyes febles per protegir la clau privada. Si necessita xifratge en repòs, fes servir xifratge modern; i si és una clau de servei, el correcte és que visqui en un gestor de secrets o en un HSM, no en un fitxer (03-06).

Tota la lliçó s'ha recolzat en un supòsit que encara no hem justificat. Repassa l'intercanvi de l'apartat 5: l'app mòbil rep una clau pública per la xarxa i la fa servir per acordar el secret. Com sap que aquella clau és de Nimbus i no d'un atacant situat al mig?

Si no hi ha manera de comprovar-ho, el MITM funciona perfectament: l'atacant fa un intercanvi amb l'app fent-se passar per Nimbus i un altre amb Nimbus fent-se passar per l'app, i desxifra i torna a xifrar tot el que hi passa. Tots dos extrems tindrien xifratge impecable amb la persona equivocada.

La criptografia asimètrica trasllada el problema, no l'elimina. Ja no cal distribuir secrets, però cal autenticar claus públiques. Aquest és el problema que resolen els certificats digitals i la infraestructura de clau pública, i és l'assumpte de 03-06. La manera concreta com TLS ho aplica a cada connexió es veu a 03-05.

Un ordinador quàntic prou gran podria executar l'algorisme de Shor, que trenca alhora RSA, Diffie-Hellman i la criptografia de corba el·líptica. No els debilita: els resol. Avui no existeix una màquina així, i les estimacions públiques parlen d'anys o dècades, però això no fa que l'assumpte sigui irrellevant avui:

Per què importa ja: «collir ara, desxifrar després». Un adversari amb recursos pot gravar avui trànsit xifrat que no pot llegir, guardar-lo, i desxifrar-lo quan disposi de la màquina. Si la dada continua sent sensible d'aquí a quinze anys, el problema és d'avui.

Per a Nimbus, a la pràctica: les dades de cites perden valor amb relativa rapidesa, així que no és una prioritat d'aquest any. El que sí que és assenyat és (1) fer servir forward secrecy sempre, que ja limita el dany d'escenaris d'aquest tipus; (2) mantenir el programari de TLS actualitzat, perquè els navegadors i les llibreries estan activant modes híbrids postquàntics (X25519 combinat amb ML-KEM) de manera transparent; i (3) portar un inventari d'on es fa servir cada algorisme, que és el que farà barata la migració quan toqui. Aquesta agilitat criptogràfica —poder canviar d'algorisme sense reescriure el sistema— és la conclusió pràctica de l'apartat, i connecta amb el byte de versió que vam introduir al format de xifratge de 03-02.

Errors conceptuals

1. Invertir l'ús de les claus. Es xifra amb la pública del destinatari i es signa amb la pròpia privada. «Xifrar amb la privada» no protegeix res.
2. Creure que la signatura xifra. Una signatura no amaga el contingut; l'acredita. Si a més cal confidencialitat, s'ha de xifrar a part.
3. Confondre MAC amb signatura. Només la signatura dona no-repudi. Si el verificador pot ser qualsevol, necessites signatura.
4. Pensar que ECC és «menys segura» per tenir claus més curtes. P-256 equival a RSA-3072. La longitud no és comparable entre famílies.
5. Suposar que una clau pública rebuda per la xarxa és de qui diu ser. No ho és fins que alguna cosa ho certifica (03-06).

Errors d'implementació

6. Xifrar dades grans amb RSA. No hi caben, i és lentíssim. Fes servir xifratge híbrid.
7. Fer servir PKCS#1 v1.5 en codi nou. OAEP per xifrar, PSS per signar; o directament Ed25519, que no et deixa triar malament.
8. Signar JSON sense serialització canònica. Un espai o una reordenació de camps trenca la verificació i produeix incidències que semblen atacs.
9. Generar claus amb random o en dispositius sense bona entropia. És la lliçó de 03-01, i en signatures ECDSA és letal.
10. Deixar la clau privada en un fitxer llegible, al repositori o a la imatge del contenidor. El problema de 03-06.
11. Ignorar el resultat de verify. Si no llança excepció és vàlida; si la llança, el missatge es descarta i es registra l'esdeveniment. Mai «es continua per si de cas».

Consells

• Per a codi nou: Ed25519 per signar, X25519 per intercanviar. Si una interoperabilitat t'obliga a RSA, fes servir 3072 bits amb OAEP/PSS.
• Desa sempre un identificador de clau (kid) al costat de la signatura. Sense ell, rotar la clau obliga a aturar el servei; amb ell, la rotació és transparent. És exactament el que feia el JWKS de 02-05 i es desenvolupa a 03-06.
• Publica les teves claus públiques per un canal que el client pugui verificar, i tingues pensat des del principi com les rotaràs.
• Anota a l'inventari tècnic quin algorisme fa servir cada component. El dia de la migració postquàntica, aquell document serà la diferència entre un projecte i una crisi.

Per a cada requisit de Nimbus indica: quina primitiva faries servir (xifratge simètric, xifratge asimètric, intercanvi de claus, signatura o MAC), amb quin algorisme concret, quina clau fa servir cada part i per què descartes les alternatives.

1. L'app mòbil i l'API han d'acordar una clau de sessió sense haver-se vist mai.
2. Nimbus ha de demostrar davant d'un jutjat, dos anys després, que un rebut el va emetre el seu sistema.
3. L'API ha de comprovar que un webhook ve de la passarel·la de pagament, amb la qual comparteix un secret configurat.
4. Nimbus vol enviar la clau de desxifratge d'una còpia a la consultora (A-19) per a una restauració puntual.
5. Les actualitzacions de l'agent que Nimbus instal·la als servidors d'alguns clients han de ser verificables pel client.
6. Un adjunt de 18 MB s'ha de desar xifrat al bucket A-05.

La Marta ha llegit en una auditoria que «el servidor no ofereix forward secrecy» i pregunta si això significa que el trànsit va sense xifrar.

Es demana: (a) respon a la Marta en dos paràgrafs sense fórmules; (b) descriu l'escenari concret de dany a Nimbus si la clau privada del servidor es filtrés d'aquí a tres anys, amb i sense forward secrecy; (c) explica quina configuració concreta ho garanteix i per què TLS 1.3 ho resol per disseny; (d) relaciona això amb el risc de «collir ara, desxifrar després».

Un desenvolupador proposa aquest disseny per als rebuts:

Es demana: (a) identifica els problemes de les tres línies marcades; (b) indica quina propietat de seguretat creu l'autor que està aconseguint i quina aconsegueix realment; (c) explica per què aquest disseny no serveix per al requisit que la clínica verifiqui el rebut pel seu compte; (d) proposa el disseny correcte i justifica la primitiva triada.

Exercici 1

Exercici 2

(a) Resposta a la Marta. No: el trànsit va xifrat igualment i avui ningú no el pot llegir. «Forward secrecy» es refereix a una altra cosa —a què passaria en el futur si algú aconseguís la clau privada del servidor—. Sense forward secrecy, aquella clau permetria desxifrar retroactivament totes les converses antigues que algú hagués gravat; amb ella, cada sessió fa servir un secret efímer que es destrueix en acabar, així que el passat queda protegit per sempre.

Dit d'una altra manera: sense forward secrecy, la clau del servidor és una clau mestra que obre també l'arxiu històric; amb forward secrecy, obre només les portes d'avui endavant. Per això l'auditoria ho assenyala encara que ara mateix no hi hagi cap problema visible.

(b) Escenari. Un atacant grava el trànsit de les apps mòbils durant divuit mesos. Sense forward secrecy, en obtenir la clau privada d'aquí a tres anys desxifra els divuit mesos complets: agendes de clíniques, correus, telèfons i informació que revela indirectament dades de salut. Amb forward secrecy, no desxifra ni una sessió; només podria suplantar el servidor a partir d'aquell moment, cosa que es talla revocant el certificat i rotant la clau (03-06).

(c) Configuració. Permetre únicament suites amb ECDHE i deshabilitar l'intercanvi de clau RSA estàtic; a la pràctica, exigir TLS 1.3 —que va eliminar de l'estàndard tots els modes sense forward secrecy— i mantenir TLS 1.2 només amb suites ECDHE mentre hi hagi clients antics. El detall de configuració és a 03-05.

(d) Relació amb «collir ara, desxifrar després». És el mateix patró —gravar avui, desxifrar demà— amb un habilitador diferent: allà la clau robada, aquí un futur ordinador quàntic. La forward secrecy no protegeix davant de l'amenaça quàntica per si sola (el mateix intercanvi efímer és vulnerable a Shor), però elimina l'escenari més probable i barat, i encaixa amb la mateixa resposta: claus efímeres, algorismes actualitzables i inventari d'on es fa servir cadascun.

Exercici 3

(a) Problemes:

1. str(rebut) — serialització no canònica: depèn de l'ordre d'inserció del diccionari i del repr de Python. El mateix rebut pot produir cadenes diferents i verificacions fallides sense cap atac. A més no és interoperable amb cap altre llenguatge.
2. sha256(CLAU + text) — és la construcció prefix-MAC, vulnerable a l'atac d'extensió de longitud en funcions tipus SHA-2: un atacant pot afegir dades al missatge i calcular una signatura vàlida sense conèixer la clau. Per a això existeix l'HMAC, que s'estudia a 03-04. I la clau, a més, és al codi i és una cadena endevinable.
3. == — comparació de secrets no constant en el temps: obre un canal lateral de temporització (03-01). Cal fer servir hmac.compare_digest.

(b) L'autor creu que està aconseguint una signatura amb no-repudi. Aconsegueix, en el millor dels casos, un MAC mal construït: integritat i autenticitat fràgils entre parts que comparteixen el secret, sense no-repudi, i amb la clau a l'abast de qualsevol amb accés al repositori.

(c) Per què no serveix. Perquè la clínica verifiqui pel seu compte, necessitaria CLAU_SECRETA. I així que la té, pot fabricar rebuts indistingibles dels de Nimbus. Un esquema de clau compartida no pot donar verificació pública: és la diferència estructural entre MAC i signatura.

(d) Disseny correcte. Signatura Ed25519 amb la clau privada de Nimbus custodiada al gestor de secrets o KMS, sobre una serialització canònica (json.dumps(..., sort_keys=True, separators=(",", ":"))), incloent-hi al mateix rebut un identificador de clau (kid) i la data d'emissió, i publicant la clau pública en un extrem verificable. Així qualsevol clínica verifica sense poder falsificar, la rotació de clau és possible gràcies al kid, i el rebut té valor probatori tècnic —amb la validació legal assenyalada a l'apartat 9—.

Has vist la idea que va resoldre el problema amb què va tancar la lliçó anterior. Un parell de claus relacionades per una funció de porta trampa —fàcil en un sentit, inviable en l'altre— permet publicar-ne una meitat sense perdre res, i amb això desapareix la necessitat de distribuir secrets previs. Tens fixada la taula que més es confon: es xifra amb la pública i es desxifra amb la privada; es signa amb la privada i es verifica amb la pública. Coneixes RSA i el seu problema difícil, les seves mides vigents —2048 com a mínim, 3072 com a recomanació— i els seus dos límits estructurals, la lentitud i la impossibilitat de xifrar dades grans; i coneixes la criptografia de corba el·líptica, on 256 bits equivalen a 3072 d'RSA, amb Ed25519 per signar i X25519 per intercanviar com a recomanació per defecte per a codi nou.

Has entès Diffie-Hellman amb l'analogia dels colors i la seva versió efímera, ECDHE, de la qual surt la propietat més valuosa del conjunt: la confidencialitat persistent (forward secrecy), que fa que robar la clau privada del servidor d'aquí a tres anys no permeti llegir res del que s'ha gravat fins avui. Has vist el xifratge híbrid —clau simètrica per a les dades, criptografia asimètrica només per protegir aquella clau— que és el patró real de TLS i del xifratge de sobre dels adjunts de Nimbus. I has separat amb precisió signatura i MAC: tots dos donen integritat i autenticitat, però només la signatura dona no-repudi, perquè el verificador no la pot fabricar. Ho has practicat signant un rebut de reserva amb Ed25519 en 64 bytes, comprovant que alterar l'import invalida la signatura, i aprenent el detall que trenca la majoria de les integracions reals: la serialització canònica.

Però la lliçó acaba amb la mateixa honestedat amb què va acabar l'anterior. La criptografia asimètrica no elimina el problema de confiança: el trasllada. Ja no cal distribuir secrets, però encara s'ha de respondre una pregunta sense la qual tot l'anterior s'esfondra davant d'un atacant al mig: aquesta clau pública que acabo de rebre, és realment de Nimbus?

A Funcions Hash, HMAC i Emmagatzematge de Contrasenyes (03-04) fem un pas enrere cap a la primitiva que ja ha aparegut dues vegades sense explicació —el hash que se signa en lloc del missatge— i l'estudiem a fons: quines propietats té, per què MD5 i SHA-1 estan trencats, com es construeix correctament un HMAC per validar el webhook de la passarel·la de pagament, i, per fi, com ha de desar Nimbus les contrasenyes dels seus usuaris amb Argon2id, sal i paràmetres calibrats. La resposta a la pregunta de la clau pública haurà d'esperar a 03-06.