La lliçó anterior va acabar amb un compte incòmode: l'RSA dona 128 bits de seguretat amb claus de 3072 bits, però per arribar als 256 bits de l'estàndard d'or farien falta claus de ~15360 bits — un creixement tan dolent que a la pràctica ningú ho fa. Aquesta lliçó presenta la família de portes falses que va resoldre aquest problema i que avui domina la criptografia asimètrica, des del teu mòbil fins al TLS: la criptografia de corba el·líptica (ECC, Elliptic Curve Cryptography). Veuràs per què aconsegueix les mateixes garanties amb claus de només 256 bits, la intuïció geomètrica de la seva funció d'un sol sentit (sense àlgebra feixuga, promès), quines corbes concretes importen avui i quines evitar, i com generar i serialitzar claus EC amb pyca/cryptography. Al final, MediNube prendrà una decisió d'arquitectura que condicionarà la resta del mòdul: quina corba fer servir per a les futures signatures de receptes electròniques.

1. El problema de l'RSA: claus que creixen fatal
2. Què és una corba el·líptica: la suma de punts
3. La porta falsa: el logaritme discret el·líptic
4. Les corbes que importen: NIST i Bernstein
5. Generació de claus EC amb pyca/cryptography
6. Serialització PEM: igual que a l'RSA, però en miniatura
7. RSA o ECC: criteri d'elecció pràctic
8. La decisió de MediNube

La seguretat de l'RSA descansa en la factorització, i la factorització té un problema per al defensor: els algorismes coneguts per atacar-la (com el sedàs general del cos de nombres, GNFS) són subexponencials — molt millors que la força bruta. Conseqüència: per guanyar uns pocs bits de seguretat cal engrandir la clau RSA moltíssim.

Amb les corbes el·líptiques passa el contrari: el millor atac conegut contra la seva porta falsa és essencialment genèric (cost ~2^(n/2), el mateix ordre que la paradoxa de l'aniversari que vas veure a 03-01). Això significa que una clau EC de n bits dona ~n/2 bits de seguretat, i la taula d'equivalències queda així:

Llegeix la taula per files: per a l'estàndard de 128 bits (regla d'or 5), l'RSA necessita una clau 12 vegades més gran que l'ECC. I la diferència es dispara cap avall: a la fila de 256 bits, l'RSA és directament inviable a la pràctica i l'ECC continua sent una clau de 64 bytes.

Per què importa, més enllà de l'elegància?

• Rendiment. Les operacions EC sobre números de 256 bits són molt més ràpides que les exponenciacions RSA sobre números de 3072. En un servidor que fa milers de connexions TLS per segon, la diferència es nota a la factura.
• Amplada de banda. Cada clau pública, cada signatura, cada intercanvi viatja per la xarxa. 32-64 bytes davant de 384 a cada handshake, multiplicat per milions de connexions.
• Mòbil i IoT. Un sensor mèdic amb bateria i un microcontrolador modest pot fer ECC amb soltesa; l'RSA-3072 li surt car. Per a MediNube, que planeja integrar dispositius de monitoratge domiciliari, això no és teòric.
• Generació de claus. Generar un parell RSA-3072 implica buscar primers enormes (segons); generar un parell EC és triar un número aleatori (microsegons). Això habilitarà les claus efímeres de 04-04.

Una corba el·líptica és el conjunt de punts (x, y) que compleixen una equació del tipus:

Dibuixada sobre els números reals, és una corba suau i simètrica respecte a l'eix X. L'interessant no és la corba en si, sinó que sobre els seus punts es pot definir una operació de suma amb una regla geomètrica sorprenentment senzilla:

Per sumar dos punts P i Q: traça la recta que els uneix. Aquesta recta talla la corba en un tercer punt. Reflecteix aquest punt respecte a l'eix X: el resultat és P + Q.

Amb aquesta suma definida, es defineix la multiplicació per un escalar com a suma repetida:

on G és un punt fix de la corba anomenat punt generador (ve definit a l'estàndard de cada corba, és públic). I aquí hi ha el truc que ho fa practicable: no cal fer k sumes de veritat. Igual que pow(m, e, n) no multiplica e vegades, la multiplicació escalar es calcula amb el mètode de duplicar i sumar: 8·G = 2·(2·(2·G)) — n'hi ha prou amb ~256 duplicacions i sumes encara que k tingui 256 bits. La direcció "fàcil" és realment fàcil.

Dues matisacions honestes, perquè la intuïció no t'enganyi:

• En criptografia la corba no viu sobre els números reals sinó sobre un cos finit (coordenades enteres mòdul un primer gran). El dibuix continu desapareix i queda un núvol de punts, però les fórmules de la suma geomètrica continuen funcionant exactament igual. La intuïció de la recta i el reflex és vàlida; el dibuix, no.
• L'equació exacta i els seus paràmetres a, b, el primer del cos i el generador G són el que defineix una corba concreta (P-256, Curve25519...). Triar malament aquests paràmetres pot destruir la seguretat — per això només es fan servir corbes estandarditzades i auditades, mai corbes pròpies (regla d'or 1, una altra vegada).

Ja tens les dues peces per veure la funció d'un sol sentit:

• Fàcil: donat un escalar secret k i el generador G, calcular el punt Q = k·G (duplicar i sumar, microsegons).
• Inviable: donat el punt Q i el generador G, recuperar l'escalar k. Aquest és el problema del logaritme discret el·líptic (ECDLP), i no es coneix cap drecera en corbes ben triades: el millor atac costa de l'ordre de 2^128 operacions per a una corba de 256 bits.

La correspondència amb el que ja saps de 04-01 és directa:

Fixa't que generar un parell de claus EC és trivial: la privada és literalment un número aleatori de 256 bits sortit del CSPRNG (regla d'or 3), i la pública s'obté amb una multiplicació escalar. Res de buscar primers. Per això generar claus EC és milers de vegades més ràpid que generar claus RSA — un detall que semblarà menor fins que a 04-04 vulguem generar un parell nou per cada connexió.

Nota per al futur (i perquè no t'espanti un titular): tant la factorització com el logaritme discret — clàssic i el·líptic — cauria davant d'un ordinador quàntic a gran escala amb l'algorisme de Shor. Avui no existeix aquesta màquina, i la resposta (criptografia post-quàntica) és la lliçó 06-05. Per a tot el que construïm en aquest mòdul, l'ECC és l'estàndard actual i correcte.

A la pràctica no tries paràmetres: tries una corba amb nom d'un catàleg molt curt. Les que necessites conèixer s'agrupen en dues famílies:

Estandarditzades pel NIST estatunidenc (P-256 també s'anomena secp256r1 o prime256v1 — tres noms, la mateixa corba; P-384 és secp384r1). Són l'estàndard de la interoperabilitat: certificats TLS, targetes intel·ligents, DNIe, APIs governamentals, maquinari HSM... si un sistema aliè t'exigeix una corba concreta, gairebé segur que serà una d'aquestes. Són segures amb una implementació correcta, però tenen dues ombres:

• Implementar-les en temps constant és difícil, i hi ha hagut implementacions històriques amb fuites per canal lateral (recorda els timing attacks de 01-04). La de pyca/cryptography (OpenSSL per sota) és correcta; el risc és en implementacions casolanes o exòtiques.
• Les seves constants deriven de llavors no explicades públicament, cosa que ha generat desconfiança històrica (mai no s'ha demostrat res dolent, però la criptografia moderna prefereix constants justificables).

Dissenyades per Daniel J. Bernstein amb la filosofia oposada: que la implementació segura sigui el camí fàcil. Constants explicades i minimalistes, operacions en temps constant per disseny de la mateixa corba, sense casos especials que un programador pugui gestionar malament, sense decisions perilloses delegades a qui la fa servir. Vénen en dues presentacions que convé no confondre:

• X25519 (sobre Curve25519): la corba per a intercanvi de claus. És la protagonista de 04-04.
• Ed25519: la corba (una transformació de la mateixa) per a signatures digitals. És la protagonista de 04-03.

Són les corbes preferides del programari modern: SSH, Signal, WireGuard, age, i una fracció creixent de TLS les fan servir per defecte.

I les que has de saber evitar: qualsevol corba per sota de 224 bits (SECP192R1, SECT163K1... si les veus en codi heretat, és una troballa), i corbes exòtiques triades sense motiu. SECP256K1 és un cas a part: és la corba de Bitcoin/Ethereum, correcta en el seu nínxol, però fora d'ell no hi ha raó per triar-la.

Les tres variants que faràs servir, cadascuna amb el seu mòdul a hazmat.primitives.asymmetric:

Detalls que convé interioritzar:

• Amb les corbes NIST, la corba es passa com a paràmetre (ec.generate_private_key(ec.SECP256R1())) i el mateix objecte serveix per a diversos usos. Amb les corbes de Bernstein, la classe és la corba i l'ús: Ed25519PrivateKey només sap signar, X25519PrivateKey només sap intercanviar. Aquesta rigidesa és un avantatge: l'API t'impedeix reutilitzar una clau per a dos propòsits diferents, un error clàssic.
• No hi ha key_size a triar ni public_exponent a recordar: la corba ja ho defineix tot. Menys decisions, menys maneres d'equivocar-se — exactament la filosofia Bernstein.
• La generació és instantània. Genera mil parells en un bucle i cronometra; fes el mateix amb rsa.generate_private_key i compara (avanço: no voldràs esperar).
• Fidel al que hem après: la privada és un escalar aleatori del CSPRNG del sistema; la pública, un punt. pyca/cryptography no et deixa veure l'escalar per accident, i així ha de ser.

El que no farem encara: ni priv_signatura.sign(...) ni priv_intercanvi.exchange(...). Cada operació té la seva lliçó (04-03 i 04-04) i el seu context; avui l'objectiu és tenir les claus i entendre per què són tan petites.

Tot el que vas aprendre a 04-01 sobre PEM s'aplica sense canvis — mateixa API, mateixos formats, mateixa disciplina de xifrar la privada:

Compara aquest PEM públic de ~4 línies amb el de l'RSA-3072 (una desena de línies de Base64): és la taula d'equivalències feta visible. Nota pràctica: load_pem_public_key retorna el tipus correcte segons el contingut (Ed25519PublicKey, EllipticCurvePublicKey, RSAPublicKey...) — si el teu codi espera una corba concreta, comprova el tipus amb isinstance en carregar-la, no ho donis per fet.

La pregunta que et faràs a cada projecte nou, resposta en una taula:

L'última fila de l'esquerra mereix un apunt: l'ECC no té un equivalent directe del "xifra aquest missatget amb la pública" de l'RSA-OAEP. Amb corbes el·líptiques, la confidencialitat es construeix combinant intercanvi de claus i xifratge simètric — que és justament el camí de 04-04 i 04-05, i és també com funciona el món real. No és una mancança; és que el patró de l'RSA-OAEP era la drecera, no la norma.

Toca aplicar el criteri. A la reunió d'arquitectura de la capa de seguretat hi ha dos fronts oberts:

1. Signatures de receptes electròniques (el deute del mòdul 1): cada metge signarà les receptes que emeti, i farmàcies externes hauran de poder verificar-les. Cap sistema heretat imposa RSA aquí — el sistema és nou. Decisió: Ed25519. Claus de 32 bytes que caben a qualsevol lloc, signatures ràpides i compactes, i una API que no permet equivocar-se. Cada metge de la Clínica Sol i del Centre Mèdic Luna tindrà el seu parell Ed25519. Els detalls, a la propera lliçó.
2. Canal segur entre MediNube i les clíniques (el deute de 02-01): X25519 per a l'intercanvi de claus, per les mateixes raons. Es materialitza a 04-04.

I el parell RSA-3072 que vam generar a 04-01? Es queda: la integració amb el sistema d'un hospital públic exigeix RSA per normativa, i allà l'RSA-OAEP continua sent correcte. Conviuran — la criptoagilitat (regla d'or 8) consisteix exactament a poder mantenir totes dues famílies i jubilar-ne una sense reescriure el sistema.

I la pregunta incòmoda de 04-01 continua intacta, ara multiplicada: si cada metge té una clau pública Ed25519, com sap una farmàcia de quin metge és cada clau? Anota-la; a 04-04 tornarà amb dramatisme.

• Comparar mides de clau entre famílies. "El meu RSA de 3072 és més segur que el teu Ed25519 de 256" és fals: tots dos donen ~128 bits de seguretat. Els bits de clau només són comparables dins de la mateixa família; el que es compara entre famílies són els bits de seguretat.
• Triar la corba "més gran per si de cas". P-521 o signatures RSA-4096 rarament aporten res davant de 25519/P-256 i encareixen tot. 128 bits de seguretat és l'estàndard del curs; puja-ho només amb un requisit concret (normativa, longevitat extrema de les dades).
• Confondre Ed25519 amb X25519. Parents, però no intercanviables: una és de signatura i l'altra d'intercanvi, amb formats de clau diferents. L'API de pyca/cryptography et protegeix (classes separades); altres ecosistemes no sempre.
• Reutilitzar la mateixa clau per signar i intercanviar. Encara que una llibreria ho permetés, és un antipatró clàssic: cada propòsit, el seu parell de claus. Guarda't aquesta regla per quan a 06-01 parlem d'inventari i rotació de claus.
• Implementar l'aritmètica de corbes a mà. Les fórmules de la suma de punts caben a la pantalla i la temptació és real. Però els casos especials (punt a l'infinit, P + (-P), temps constant) són un camp de mines. Regla d'or 1: la corba es tria, no s'implementa.
• Corbes petites o obscures en codi heretat. SECP192R1 o similars per sota de 224 bits: troballa de seguretat, a migrar. I si veus SECP256K1 fora d'un context blockchain, pregunta per què — gairebé segur que va ser un copy-paste.
• Desar la privada EC sense xifrar perquè "és petitona". La mida no canvia la disciplina de 04-01: PKCS8 + BestAvailableEncryption, passphrase fora del repositori.

1. La taula, interioritzada. Sense mirar la taula: (a) quina mida de clau ECC necessites per a 192 bits de seguretat i quina mida tindria l'RSA equivalent? (b) Per què la relació no és lineal — per què l'RSA "creix fatal" i l'ECC creix suau? (c) Quants bits de seguretat dona una clau EC de 256 bits i per què no 256?

2. Duel de generació. Escriu un script que generi 50 parells Ed25519 i 3 parells RSA-3072, cronometrant cada tanda amb time.perf_counter(). Calcula el cost mitjà per parell i el factor de diferència. Serialitza una pública de cada família a PEM i compara longituds amb len(). Quina implicació té el resultat per a un servidor que volgués generar un parell efímer per connexió (avanç de 04-04)?

3. Codi heretat. Audites aquesta arrencada a MediNube:

   from cryptography.hazmat.primitives.asymmetric import ec
   from cryptography.hazmat.primitives import serialization
   
   def generar_parell_metge_MALAMENT():
       priv = ec.generate_private_key(ec.SECP192R1())
       pem = priv.private_bytes(
           serialization.Encoding.PEM,
           serialization.PrivateFormat.PKCS8,
           serialization.NoEncryption(),
       )
       return pem
   

   Identifica els dos problemes, escriu generar_parell_metge corregida (recorda la decisió de MediNube: aquestes claus signaran receptes) i justifica cada canvi.

1. (a) ECC de 384 bits (P-384); l'RSA equivalent serien 7680 bits, que pràcticament ningú desplega. (b) Perquè els millors atacs són de naturalesa diferent: contra l'RSA existeix un algorisme subexponencial (GNFS), així que cada bit extra de seguretat exigeix inflar molt la clau; contra l'ECDLP en corbes ben triades només hi ha atacs genèrics de cost ~2^(n/2), així que n'hi ha prou amb afegir 2 bits de clau per cada bit de seguretat. (c) ~128 bits, precisament per aquest 2^(n/2): el mateix fenomen "meitat de la mida" que la paradoxa de l'aniversari imposava als hashes a 03-01.

El factor típic ronda entre milers i desenes de milers: l'Ed25519 triga microsegons (triar 32 bytes aleatoris i una multiplicació escalar); l'RSA-3072 triga de desenes a centenars de mil·lisegons (buscar dos primers enormes, i a més amb durada variable — de vegades els primers apareixen ràpid, de vegades no). Implicació: generar un parell EC per connexió és gratis, generar un parell RSA per connexió seria un suïcidi de rendiment. Aquesta asimetria és la que fa viables les claus efímeres i la forward secrecy de 04-04.

3. Els dos problemes: (1) SECP192R1 és una corba d'~96 bits de seguretat, molt per sota del mínim — insuficient i prohibida per a codi nou; (2) NoEncryption() desa la privada del metge nua: qui llegeixi el fitxer pot signar receptes com aquest metge. Correcció:

Justificació: Ed25519 en lloc d'una altra corba NIST perquè el sistema de receptes és nou (res no imposa interoperabilitat NIST) i és la decisió d'arquitectura presa en aquesta lliçó; la passphrase entra com a paràmetre perquè ha de venir de fora del codi (gestor de secrets — mòdul 6), mai escrita al font.

Ja tens la segona gran porta falsa de la criptografia asimètrica. Sobre una corba el·líptica es defineix una suma de punts geomètrica, i amb ella la multiplicació escalar Q = k·G: calcular Q des de k és instantani, recuperar k des de Q — el logaritme discret el·líptic — és inviable. Com que els millors atacs contra l'ECDLP són genèrics (~2^(n/2)) i contra l'RSA són subexponencials, l'ECC dona els mateixos 128 bits de seguretat amb claus de 256 bits en lloc de 3072: menys bytes a la xarxa, operacions més ràpides i generació de claus pràcticament gratis. Coneixes el catàleg (P-256/P-384 quan la interoperabilitat mana; Ed25519 per signar i X25519 per intercanviar quan tries tu, que és gairebé sempre), saps generar i serialitzar les tres variants amb pyca/cryptography, i MediNube ha pres la seva decisió: Ed25519 per a les signatures dels metges, X25519 per al canal amb les clíniques. Però fixa't en el que tens entre mans: claus capaces de signar... i encara no saps signar. És hora de saldar el deute més antic del curs — el no repudi promès al mòdul 1 — i que la Dra. de la Clínica Sol signi la seva primera recepta electrònica. Això és la propera lliçó, 04-03: Signatures Digitals. Ens veiem allà.