La lliçó anterior et va deixar amb un mapa de primitives i una promesa: començar per la més antiga i la més usada, la que empra una única clau compartida per xifrar i desxifrar. És la que mou el 99 % dels bytes xifrats del planeta —el contingut de cada connexió TLS, cada disc xifrat, cada còpia de seguretat de Nimbus— perquè és ràpida, senzilla de raonar i està resolta des de fa dècades. Aquesta lliçó explica per què AES és l'estàndard, què és un mode d'operació i per què triar-lo malament arruïna un algorisme intatxable, què és un nonce i per què repetir-lo és una catàstrofe, i com es xifra correctament un adjunt de Nimbus amb AES-GCM. Acaba al punt exacte on el simètric es queda sense respostes: com fer arribar la clau a l'altre extrem.

1. Què és la criptografia simètrica i quan es fa servir
2. Xifratge de bloc i xifratge de flux
3. AES: per què és l'estàndard
4. Modes d'operació: per què un bloc no basta
5. ECB, CBC i CTR: el catàleg clàssic i els seus paranys
6. Xifratge autenticat (AEAD) i dades addicionals autenticades
7. Xifrar un adjunt de Nimbus amb AES-GCM
8. La regla del nonce
9. Xifrar una còpia de seguretat amb openssl des de la línia d'ordres
10. Derivació de claus: HKDF
11. Rendiment i les seves conseqüències de disseny
12. El problema que queda obert: distribuir la clau

En un esquema simètric, la mateixa clau serveix per xifrar i per desxifrar. Emissor i receptor —o, molt sovint, la mateixa màquina en dos moments diferents— comparteixen aquest secret.

Els escenaris on és la resposta natural comparteixen un tret: la clau ja està disponible als dos extrems, sigui perquè només hi ha un extrem o perquè un altre mecanisme l'hi va posar.

Els seus dos avantatges són la velocitat —ordres de magnitud sobre l'asimètrica, amb instruccions específiques als processadors actuals— i les claus curtes: 256 bits basten per al molt llarg termini. La seva única gran mancança és la distribució: si dues parts que no s'han vist mai necessiten una clau comuna, el simètric tot sol no els la pot donar; i el nombre de claus creix de manera quadràtica, perquè n parts que vulguin parlar per parelles necessiten n·(n−1)/2 claus (amb 38 empleats, 703).

Hi ha dues maneres de construir un xifrador simètric:

La frontera entre tots dos és més difusa del que sembla: un xifrador de bloc en mode CTR es comporta com un de flux, perquè en lloc de xifrar les dades genera un raig que després es combina amb elles. Aquesta és exactament la idea sobre la qual es construeix AES-GCM. I tots dos comparteixen la regla que arrosseguem des de Vigenère: el mateix material de clau no es fa servir dues vegades. En un xifratge de flux això és literal: si xifrem dos missatges diferents amb el mateix raig, un XOR entre els dos xifrats elimina el raig i deixa els dos clars combinats entre si, cosa que sol bastar per recuperar-los.

AES (Advanced Encryption Standard) és un xifrador de bloc adoptat pel NIST el 2001 després d'un concurs públic internacional de cinc anys en què van participar quinze candidats, amb criptoanàlisi obert de tota la comunitat. Va guanyar l'algorisme belga Rijndael. Aquesta història és la millor il·lustració de Kerckhoffs que existeix: l'algorisme es va fer fort precisament per ser públic i per haver estat atacat durant dècades sense èxit pràctic.

AES-128 davant d'AES-256. Tots dos estan fora de l'abast de qualsevol força bruta (recorda el càlcul de 03-01: 2^128 són onze bilions d'anys amb una màquina impossible). AES-256 es tria quan la dada ha de continuar confidencial durant dècades, quan una norma sectorial ho exigeix o quan es vol marge davant de l'amenaça quàntica a llarg termini. A Nimbus farem servir 256 perquè el cost de rendiment és marginal i la conversa amb auditors se simplifica. ChaCha20 és l'alternativa moderna: un xifrador de flux molt ràpid en programari pur, habitual en dispositius mòbils sense acceleració AES —i per tant rellevant per a l'app de Nimbus—; combinat amb l'autenticador Poly1305 dona ChaCha20-Poly1305, un AEAD de la mateixa categoria que AES-GCM.

AES xifra exactament 16 bytes. Un adjunt d'una clínica pot pesar 3 MB. Com es xifren 3 MB amb una funció que només sap manejar 16 bytes?

La resposta és un mode d'operació: el conjunt de regles que diu com trossejar el missatge, com encadenar els blocs i com farcir l'últim. I aquí hi ha la idea més important de la lliçó:

AES és intatxable; els modes són on la gent s'equivoca. Pràcticament totes les fallades de xifratge simètric que veuràs a la teva carrera són fallades de mode, de nonce o de gestió de clau. Mai del xifrador.

Per entendre el problema, imagina que xifrem cada bloc de 16 bytes per separat amb la mateixa clau i sense res més. Com que AES és determinista, dos blocs de text en clar idèntics produeixen dos blocs xifrats idèntics. L'estructura de l'original sobreviu al xifratge.

La demostració clàssica és la del pingüí: si es pren la imatge d'un pingüí i es xifra en mode ECB, el resultat continua sent, visiblement, un pingüí. Els colors canvien, però les zones d'un mateix to uniforme es converteixen en zones d'un altre to uniforme, i la silueta es reconeix sense cap esforç. Aquest és el sentit literal de «el xifratge no ha de conservar estructura».

Traslladat a Nimbus: si es xifressin en ECB els registres de cites, totes les files el camp estat de les quals valgués CANCELLADA tindrien el mateix bloc xifrat. Sense desxifrar res, un observador comptaria cancel·lacions per clínica i detectaria patrons. La confidencialitat es perd sense trencar AES.

El que cal és que el mateix text en clar xifrat dues vegades produeixi resultats diferents. Aquest és el paper de l'IV (vector d'inicialització) o del nonce: un valor variable que es combina amb el procés perquè cada xifratge sigui únic.

Ni l'IV ni el nonce no són secrets: s'emmagatzemen al costat del text xifrat, en clar. L'únic secret és la clau.

Detall de cadascun:

• ECB (Electronic Codebook). Cada bloc es xifra independentment. És el pingüí. No hi ha cap cas d'ús legítim en un sistema d'informació. Si el trobes al codi, és una troballa d'auditoria, no una preferència d'estil.
• CBC (Cipher Block Chaining). Cada bloc es combina per XOR amb el xifrat de l'anterior abans de xifrar-se; el primer, amb l'IV. Resol els patrons, però arrossega tres inconvenients: necessita farciment —cosa que històricament va obrir els atacs de padding oracle, en què l'atacant desxifra sense la clau observant com respon el servidor a farciments no vàlids—, exigeix un IV impredictible (un de predictible habilita atacs de text en clar triat), i no dona integritat: un atacant pot alterar bits del xifrat i provocar canvis controlats en el clar.
• CTR (Counter). Converteix AES en un xifrador de flux: es xifra un comptador creixent i el resultat es combina per XOR amb les dades. Ràpid, paral·lelitzable i sense farciment. Però si es repeteix el parell (clau, nonce), es repeteix el raig i l'atacant recupera els clars. Tampoc no dona integritat.

La lectura de la taula és contundent: cap mode clàssic no protegeix la integritat. I sense integritat, la confidencialitat és fràgil, perquè un atacant que pot modificar el text xifrat i observar el comportament del sistema té un camí cap a les dades. D'aquí la resposta moderna.

AEAD significa Authenticated Encryption with Associated Data: xifratge i autenticació en una sola operació i amb una sola clau. En xifrar es produeix, a més del text xifrat, una etiqueta d'autenticació de 16 bytes. En desxifrar, la llibreria verifica l'etiqueta abans de retornar res: si no quadra, llança una excepció i no lliura ni un byte.

Per què això és avui la resposta per defecte:

1. Elimina tota una família d'atacs. Sense integritat, existeixen els oracles de farciment, la mal·leabilitat i la manipulació de bits. Amb AEAD, alterar un sol bit del text xifrat produeix un error, no un text en clar diferent.
2. Evita l'error de combinar malament. Abans es feia «xifrar i després calcular un MAC», i l'ordre importava: MAC-then-encrypt i encrypt-and-MAC tenen problemes coneguts; només encrypt-then-MAC és correcte. AEAD treu aquesta decisió de les mans del desenvolupador.
3. És el que fan servir els protocols seriosos. TLS 1.3 només admet suites AEAD (03-05).

Un AEAD accepta una tercera dada d'entrada: les AAD, que s'autentiquen però no es xifren. Són metadades que viatgen en clar però queden lligades criptogràficament al text xifrat: si algú les canvia, el desxifratge falla.

La seva utilitat a Nimbus és directa. Els adjunts del bucket A-05 són objectes independents amb noms predictibles. Si només xifrem el contingut, un atacant amb permís d'escriptura al bucket podria moure l'objecte xifrat de la clínica CL-014 a la carpeta de la clínica CL-207: el contingut es continuaria desxifrant sense problema, perquè la clau és la mateixa, i la clínica equivocada veuria el document d'una altra. És una fuita entre tenants sense trencar res.

La solució és posar el context a les AAD:

Ara el text xifrat només es desxifra si es presenta amb aquest context exacte. Mogut a un altre tenant, el desxifratge llança una excepció. És la traducció criptogràfica del WHERE tenant_id que va corregir l'IDOR a 01-01: la dada queda lligada al seu amo.

Aquest és l'exemple central de la lliçó. Fa servir la llibreria cryptography, que és la implementació de referència en Python i la que has de fer servir en producció.

Sortida:

Punts que cal entendre d'aquest codi, un a un:

• AESGCM.generate_key(bit_length=256) fa servir internament el generador segur del sistema. No derivis mai una clau d'un str fix ni d'una contrasenya amb sha256(...): això es fa amb un KDF (apartat 10 i 03-04).
• El nonce és de 12 bytes (96 bits) perquè és la mida per a la qual GCM està especificat i optimitzat. Altres mides obliguen a un processament addicional i augmenten el risc d'error.
• secrets.token_bytes(12) dins del flux de xifratge, mai fora. Un nonce calculat una vegada i reutilitzat en un bucle és la fallada més freqüent (apartat 8).
• encrypt retorna el text xifrat amb l'etiqueta ja concatenada al final. Per això el resultat ocupa 16 bytes més que l'original. No has de gestionar l'etiqueta per separat.
• decrypt verifica abans de desxifrar. Si l'etiqueta no quadra llança InvalidTag i no retorna dades parcials. No capturis mai aquesta excepció per «continuar endavant amb el que hi hagi»: no hi ha res vàlid a recuperar.
• L'AAD no es desa xifrat perquè no cal: tenant_id i adjunt_id ja són a la ruta de l'objecte i a la base de dades. El que aporta l'AAD és que no es puguin canviar sense invalidar el xifratge.
• La mida es conserva gairebé exactament: 65 bytes de contingut produeixen 93 de desats. GCM no farceix, així que revela la longitud aproximada de l'original. Si aquesta longitud és sensible (per exemple, distingir un informe llarg d'un de curt), s'afegeix farciment explícit abans de xifrar.

Tres coses estan malament aquí: el mode ECB (patrons visibles), la clau constant (no és un secret) i l'absència d'integritat. La versió correcta és la del bloc anterior: AES-GCM, clau del gestor de secrets, nonce únic, AAD amb el context.

És la regla operativa més important del xifratge simètric modern:

Amb una mateixa clau, un nonce no es repeteix mai.

Per què en GCM és catastròfic i no simplement dolent:

1. Es perd la confidencialitat, igual que en CTR: dos missatges xifrats amb el mateix parell (clau, nonce) comparteixen el raig; el XOR dels xifrats revela el XOR dels clars.
2. Es perd l'autenticació, i de manera permanent. GCM construeix la seva etiqueta amb una clau d'autenticació derivada de la principal. Amb dos missatges sota el mateix nonce, un atacant pot recuperar aquesta clau d'autenticació i, a partir d'aquí, falsificar etiquetes vàlides per a missatges que ell triï, indefinidament i per a tots els nonces. No és una fuita puntual: és la pèrdua de la propietat d'integritat per a aquella clau.

Les dues estratègies vàlides per generar nonces:

Recomanació per a Nimbus: nonce aleatori de 12 bytes, perquè l'API corre en diversos contenidors sense estat compartit i un comptador exigiria coordinació. Amb el límit pràctic de rotar la clau abans d'acostar-se a 2^32 missatges (uns quatre mil milions), que en el volum de Nimbus significa una rotació anual folgada (03-06).

Els tres errors concrets que cal vigilar en revisió de codi:

La Lucía necessita xifrar el bolcat nocturn abans de pujar-lo a l'emmagatzematge extern. Des de la línia d'ordres:

Opció per opció:

Advertiment important sobre aquesta eina. openssl enc produeix xifratge sense autenticació: CBC no porta etiqueta, així que no detecta manipulació del fitxer xifrat. És acceptable per a una còpia que a més va acompanyada del seu hash verificat (03-04) i viu en un emmagatzematge immutable, però no és el patró recomanat per a dades noves. Per a còpies de seguretat avui convé fer servir eines que facin AEAD per disseny —age, restic, borg amb xifratge, o el xifratge del costat del servidor del proveïdor amb claus gestionades (03-06, 03-07)— en lloc de construir l'esquema a mà. I en tots els casos, la clau no pot viure a la mateixa màquina ni al mateix compte cloud que la còpia: si l'atacant arriba a les còpies, arribaria també a la clau.

Un problema pràctic freqüent: Nimbus té una clau mestra al gestor de secrets, però necessita claus diferents per a adjunts, per a còpies i per a l'índex cec de cerca (03-07). Fer servir la mateixa clau per a tot és mala pràctica —viola la separació de dominis i multiplica el risc de col·lisió de nonces—, però desar cinc claus mestres multiplica la feina de custòdia.

La solució és HKDF (HMAC-based Key Derivation Function): deriva múltiples claus independents a partir d'una de sola, de manera que conèixer-ne una de derivada no revela res de la mestra ni de les germanes.

Claus d'aquest codi:

• info és l'etiqueta de propòsit. Canviar una sola lletra produeix una clau completament diferent: és el que garanteix que les tres derivades siguin independents. Incloure la versió (v1) permet rotar sense ambigüitat (03-06).
• length=32 fixa la mida de sortida. HKDF pot produir qualsevol longitud a partir de la mateixa entrada.
• La clau mestra ha de tenir alta entropia ja. HKDF expandeix i separa, no enforteix. No serveix per derivar d'una contrasenya humana.

La distinció que no has de confondre: HKDF deriva claus a partir d'altres claus i és deliberadament ràpid. Derivar a partir de contrasenyes humanes requereix una funció deliberadament lenta —Argon2id, scrypt, bcrypt, PBKDF2—, perquè l'entrada té poca entropia i cal encarir cada intent de l'atacant. Això s'estudia a 03-04.

Els ordres de magnitud expliquen per què els sistemes reals estan construïts com estan. Xifres orientatives en una CPU de servidor moderna amb AES-NI:

Les tres conseqüències de disseny: (1) mai no es xifren dades grans amb criptografia asimètrica —RSA ni tan sols pot xifrar més bytes que el seu mòdul—, d'on neix el xifratge híbrid de 03-03; (2) xifrar en repòs és pràcticament gratis, així que «alenteix la base de dades» va deixar de ser un argument acceptable fa quinze anys; i (3) el cost és a les operacions asimètriques per connexió, no als bytes, raó per la qual TLS reutilitza sessions i una API amb moltes connexions curtes gasta més CPU en encaixades que en xifrar trànsit (03-05).

Tot l'anterior funciona si les dues parts ja comparteixen la clau. I aquí és on el simètric xoca contra el seu límit. Pensa en el cas més quotidià de Nimbus:

Una fisioterapeuta obre l'app al mòbil, a la sala d'espera, connectada a la wifi de la clínica. El seu dispositiu i l'API de Nimbus no s'han vist mai abans. Necessiten una clau simètrica comuna per xifrar la sessió. Com se la comuniquen, si l'únic canal que tenen és precisament el que volen protegir?

Enviar-la pel canal no serveix: qui escolta la captura. Repartir-la per endavant tampoc: els clients són milers i canvien a diari. I el problema d'escala és demolidor: amb 10.000 usuaris finals caldrien gairebé cinquanta milions de claus. Aquest és el problema de la distribució de claus, que va estar sense resoldre durant els primers quatre mil anys d'història de la criptografia; es va resoldre als anys setanta, i la seva solució és la raó per la qual existeix el comerç a internet.

Errors de mode i paràmetres

1. Fer servir ECB. Sense excepcions ni matisos. Si apareix al codi, és una troballa.
2. Triar CBC per a codi nou. No està trencat, però exigeix farciment correcte, IV impredictible i un MAC afegit bé. L'AEAD t'estalvia les tres decisions.
3. Reutilitzar el nonce. La fallada més greu i més comuna. Nonce nou dins del bucle, sempre, amb secrets.
4. Creure que xifrar dona integritat. Només la dona l'AEAD.
5. Capturar InvalidTag i continuar. Aquesta excepció significa «aquestes dades han estat alterades o el context és incorrecte». Es registra l'esdeveniment i s'avorta.

Errors de clau

6. Derivar la clau amb sha256(contrasenya). No és un KDF. Contrasenyes: Argon2id (03-04). Claus a partir de claus: HKDF.
7. Clau escrita al codi o en un .env versionat. És exactament la fallada que va permetre l'escalada en el ransomware de 02-06 i es tracta a 03-06.
8. Una única clau per a tot el sistema, o desar-la al costat de la dada xifrada. Deriva per propòsit amb HKDF, i recorda que una còpia xifrada amb la seva clau al mateix bucket és xifratge decoratiu.

Consells

• La resposta per defecte d'aquest curs per a xifratge simètric nou és: AES-256-GCM (o ChaCha20-Poly1305 sense acceleració per maquinari), nonce aleatori de 12 bytes, AAD amb el context de negoci, clau del gestor de secrets.
• Desa l'objecte xifrat com a versió || nonce || ciphertext+etiqueta. Aquest primer byte de versió et permetrà canviar d'algorisme d'aquí a tres anys sense reescriure les dades antigues.
• Lliga el xifratge al context amb AAD sempre que la dada tingui amo: en un SaaS multi-tenant, això és sempre. Xifrar és barat; dissenyar on viu la clau és la feina de debò.

L'Iván ha escrit aquesta funció per xifrar les notes internes de les reserves:

Es demana: (a) enumera els quatre problemes marcats i explica l'atac concret que habilita cadascun; (b) indica quina propietat de seguretat falta per complet i quina conseqüència té; (c) reescriu la funció amb AES-GCM, incloent-hi l'AAD adequat per a Nimbus i el format d'emmagatzematge; (d) explica què cal fer amb les notes ja xifrades amb el codi antic.

Per a cada cas de Nimbus, decideix: algorisme i mode, mida de clau, com es genera el nonce/IV, què poses a l'AAD (o per què no escau) i on viu la clau.

1. Adjunts de clíniques al bucket A-05, fins a 20 MB, milers al dia, diversos contenidors d'API en paral·lel.
2. Bolcat nocturn de PostgreSQL, 8 GB, un sol procés, restauració possible d'aquí a cinc anys.
3. Camp notes_cliniques de la taula de cites, uns 500 caràcters, xifrat a nivell d'aplicació.
4. Contingut de la sessió entre l'app mòbil i l'API.
5. Fitxer de configuració amb credencials de tercers que es desplega amb els contenidors.

La Marta ha llegit que «una fallada de nonce» va tombar una altra empresa i et demana una explicació de tres paràgrafs, sense matemàtiques, per al comitè.

Es demana: (a) explica amb una analogia què és un nonce i per què ha de ser únic; (b) explica per què repetir-lo en GCM és pitjor que repetir-lo en CTR; (c) digues quins dos controls concrets implantaries a Nimbus perquè aquesta fallada no pugui passar, i qui és responsable de cadascun.

Exercici 1

(a) Els quatre problemes:

(b) Falta la integritat/autenticitat. Conseqüència: ningú no detecta que una nota xifrada ha estat substituïda o modificada; el sistema desxifrarà brossa o text manipulat i ho mostrarà com a legítim.

(c) Versió correcta:

(d) Les notes antigues. No n'hi ha prou de canviar el codi: (1) es considera la clau antiga compromesa des del moment en què va estar al repositori, així que es rota; (2) s'executa una migració que desxifra amb l'esquema antic i torna a xifrar amb el nou, tenant a tenant; (3) el byte de versió permet que tots dos formats convisquin durant la migració; (4) s'elimina la clau antiga de l'historial del repositori sabent que esborrar el commit no revoca res (03-06); (5) es registra l'incident i s'avalua si hi va haver accés indegut.

Exercici 2

Nota sobre el cas 3: si aquestes notes contenen informació de salut, el disseny s'ha de validar amb el responsable de protecció de dades abans d'implantar-lo; el marc legal es tracta a 06-03.

Exercici 3

(a) Analogia. Un nonce és com el número d'una habitació d'hotel combinat amb la clau mestra: la clau és sempre la mateixa, però obre una habitació diferent cada vegada. Si dos hostes reben el mateix número, acaben a la mateixa habitació i veuen les coses de l'altre. El nonce és el que fa que el mateix secret produeixi un resultat diferent a cada ús; si es repeteix, es repeteix el resultat i apareixen relacions entre missatges que no haurien d'existir.

(b) Per què en GCM és pitjor. En CTR, repetir el nonce trenca la confidencialitat d'aquests dos missatges: és un dany acotat. En GCM, a més, permet a l'atacant deduir el valor intern amb què es calculen les etiquetes d'autenticació i, amb ell, fabricar missatges falsos que el sistema acceptarà com a autèntics, per sempre i amb qualsevol nonce. Es passa de «dos missatges llegits» a «qualsevol pot signar en el teu nom amb aquella clau».

(c) Dos controls.

1. Tècnic: una única funció interna de xifratge a la base de codi —una caixa_forta.xifrar(dades, context)— que generi el nonce internament i no accepti que se li passi des de fora. Si el paràmetre no existeix, no es pot reutilitzar. Responsable: l'Iván, amb revisió de la Marta.
2. De procés: regla de revisió obligatòria de dues persones per a qualsevol canvi que toqui aquest mòdul, més una comprovació automàtica al CI (02-04) que rebutgi Cipher(, modes.ECB, random. i nonces literals fora de la caixa forta. Responsable: la Lucía (pipeline), amb la Marta com a aprovadora.

Ja saps fer servir la meitat ràpida de la criptografia. Tens clar què és un esquema simètric —una clau que xifra i desxifra—, quan és la resposta natural a Nimbus (adjunts, còpies, xifratge en repòs, contingut de sessió) i quines són les seves dues virtuts, velocitat i claus curtes. Distingeixes xifratge de bloc de xifratge de flux, i saps per què AES és l'estàndard: un concurs públic, vint-i-cinc anys de criptoanàlisi obert i acceleració per maquinari; la millor demostració pràctica del principi de Kerckhoffs.

Però la lliçó que has de treure'n és la del mode: AES és intatxable i tot i així ECB deixa veure el pingüí, CBC exigeix IV impredictible i farciment correcte, i CTR es desmorona si repeteixes el nonce. Cap dels tres no protegeix la integritat, i per això la resposta per defecte d'avui és el xifratge autenticat: AES-GCM o ChaCha20-Poly1305, amb etiqueta verificada abans de retornar un sol byte, i amb AAD per lligar el text xifrat al seu context —el tenant_id de Nimbus—, que és la versió criptogràfica del WHERE tenant_id amb què es va corregir l'IDOR. Ho has vist funcionar: alterar un bit produeix InvalidTag, i moure un adjunt de CL-014 a CL-207 també. Te'n portes a més la regla més important de l'apartat, un nonce no es repeteix mai sota la mateixa clau, amb el perquè exacte que en GCM això no sigui una fallada puntual sinó la pèrdua permanent de l'autenticació; la pràctica amb openssl enc i el seu advertiment —xifra però no autentica, i la clau no viu mai al costat de la còpia—; HKDF per derivar claus per propòsit a partir d'una de mestra; i els ordres de magnitud que expliquen per què mai no es xifren dades grans amb criptografia asimètrica.

I et queda un problema sense resoldre, el mateix que va tenir la humanitat durant quatre mil anys: si l'únic canal entre l'app mòbil de la fisioterapeuta i l'API de Nimbus és el que volem protegir, com acorden la clau? No hi ha resposta dins del món simètric.

A Criptografia Asimètrica (03-03) veuràs la idea que ho va canviar tot: dues claus diferents i relacionades matemàticament, una de pública que es reparteix sense por i una de privada que no surt mai. Amb ella es resol la distribució mitjançant l'intercanvi Diffie-Hellman i la seva propietat més valuosa, la confidencialitat persistent (forward secrecy); apareix el xifratge híbrid, que és el patró real de TLS; i arriba la signatura digital, l'única primitiva capaç de donar no-repudi. Al final quedarà oberta una altra pregunta, la que donarà sentit a la PKI: aquesta clau pública, de qui és realment?