← Cuadernos Lacre

Concepte · 18 de maig de 2026

Xifratge d'extrem a extrem, explicat de debò

El que diuen els proveïdors quan diuen E2EE, i el que no diuen. Una explicació didàctica del mecanisme i els seus límits, sense l'embolcall publicitari.

El que xifrar significa, de debò

Xifrar un missatge és transformar-lo en una cosa que sembli soroll per a qualsevol que no posseeixi certa informació anomenada clau. L'operació es fa al dispositiu del que envia i, amb la clau correcta, es desfà al dispositiu del que rep. Entremig, el missatge viatja com una successió de bytes sense significat aparent. Aquesta és la idea senzilla. La resta de l'article s'ocupa dels matisos que la converteixen, segons el cas, en una garantia real o en una etiqueta de mercat.

L'adjectiu d'extrem a extrem —en anglès end-to-end, abreujat E2EE— afegeix una precisió. El xifratge no es fa perquè un servidor intermedi pugui llegir-lo i lliurar-lo. Es fa perquè només els dos extrems —el dispositiu del que envia i el dispositiu del que rep— posseeixin la clau. Qualsevol servidor pel qual el missatge passi veu el soroll, no el missatge. Aquesta és la diferència tècnica amb el xifratge en trànsit, on el contingut va xifrat d'un servidor al següent, però cada servidor pel qual passa el desxifra per reenvia-lo, recuperant temporalment el text en clar.

La paradoxa del secret compartit

Hi ha un problema obvi. Perquè dues persones puguin xifrar i desxifrar missatges entre si, totes dues necessiten la mateixa clau. Però, com es posen d'acord en aquesta clau si tot el que s'envien, per definició, passa per un canal on algú podria estar escoltant? Acordar la clau en el mateix canal on després la usaran sembla impossible: si l'atacant l'escolta en acordar-la, podrà desxifrar tot el posterior. Durant decennis, la criptografia clàssica va resoldre això per la via dura: les claus es lliuraven en persona, abans de començar a usar-se, en trobades físiques. Els ambaixadors carregaven amb maletins de claus cosits al folre de l'abric.

En el correu electrònic contemporani, aquesta solució no escala. Si haguéssim d'anar físicament a casa de cada persona amb qui pretenguéssim comunicar-nos de forma xifrada, no arribaríem a parlar amb ningú. La pregunta plantejada fa cinquanta anys per la comunitat criptogràfica era aquesta: és possible que dues persones que no es coneixen i que només comparteixen un canal públic acordin, en aquest mateix canal públic, un secret que ningú que escolti el canal pugui conèixer?

L'elegància de Diffie-Hellman

El 1976, dos matemàtics anomenats Whitfield Diffie i Martin Hellman van demostrar una cosa aparentment impossible: que dues persones, parlant només per un canal públic —un canal on qualsevol pot escoltar tot el que diuen—, poden posar-se d'acord en una contrasenya secreta sense que cap oient pugui descobrir-la. Sembla màgia. No ho és: és matemàtica. L'intercanvi de claus Diffie-Hellman, com es coneix des de llavors, és la base de pràcticament tota la comunicació xifrada d'internet, i mig segle d'ús intensiu i escrutini acadèmic mundial avalen la seva solidesa. Qui vulgui veure la intuïció visual o la matemàtica pot seguir llegint. Qui prefereixi confiar que funciona també pot continuar sense perdre el fil de l'article.

Per a qui vulgui intuir-ho en una imatge, hi ha una analogia coneguda amb colors. Imagina que l'Alícia i en Bru acorden en obert un color base —diguem groc— a la vista de l'Eva, que els escolta. Cadascú tria en privat un segon color secret i barreja el seu secret amb el groc. L'Alícia obté un taronja particular; en Bru obté un verd particular. Intercanvien els resultats a la vista de l'Eva. Ara cadascú barreja el color rebut amb el seu propi secret, i tots dos arriben al mateix color final, perquè l'ordre de les barreges no importa. L'Eva ha vist el groc i les dues barreges intermèdies, però no els secrets; sense algun dels secrets no pot arribar al color final. La matemàtica real canvia els colors per exponenciacions en grups modulars o corbes el·líptiques, però la idea és la mateixa: el secret compartit es construeix en públic sense que ningú al canal pugui reconstruir-lo.

De Diffie-Hellman al protocol Signal

El xifratge d'extrem a extrem que usen avui les aplicacions de missatgeria professional descansa, gairebé sense excepció, sobre una versió elegant i endurida de l'intercanvi Diffie-Hellman. El protocol Signal, dissenyat per Trevor Perrin i Moxie Marlinspike entre 2013 i 2016, és la referència. Combina dues idees clau. La primera, l'intercanvi de claus en corbes el·líptiques (X25519), que produeix el secret compartit inicial entre dos dispositius. La segona, l'anomenat Double Ratchet —doble engranatge—, que renova les claus automàticament amb cada missatge, de manera que comprometre el dispositiu avui no permet desxifrar missatges passats, ni missatges futurs una vegada s'ha rotat l'engranatge.

En Zig, l'intercanvi X25519 que produeix el secret compartit entre dos dispositius cap en sis línies, usant la biblioteca estàndard:

const std = @import("std");
const X25519 = std.crypto.dh.X25519;

// Alicia y Bruno generan cada uno un par (privada, pública).
const par_alicia = X25519.KeyPair.generate(io);
const par_bruno  = X25519.KeyPair.generate(io);

// Cada parte recibe la clave pública de la otra y deriva el mismo secreto.
const secreto_alicia = X25519.scalarmult(par_alicia.secret_key, par_bruno.public_key) catch unreachable;
const secreto_bruno  = X25519.scalarmult(par_bruno.secret_key,  par_alicia.public_key) catch unreachable;
// secreto_alicia == secreto_bruno  (32 bytes)

I dins de std.crypto.dh.X25519, què hi ha exactament? No hi ha màgia oculta. Són dues funcions curtes que es poden llegir senceres a la pròpia biblioteca estàndard de Zig. La primera deriva la clau pública des de la privada — el «gᵃ» de l'intercanvi:

pub fn recoverPublicKey(secret_key: [secret_length]u8) IdentityElementError![public_length]u8 {
    const q = try Curve.basePoint.clampedMul(secret_key);
    return q.toBytes();
}

En el llenguatge de l'article: la clau privada es «multiplica» —en el sentit el·líptic, no en l'aritmètic elemental— pel punt base de la corba Curve25519, i el resultat se serialitza en trenta-dos bytes. L'operació clampedMul és la versió endurida d'aquesta multiplicació escalar: incorpora les salvaguardes que la comunitat criptogràfica va anar afegint al llarg d'anys per resistir famílies conegudes d'atacs. Dues línies de cos de funció.

La segona funció combina la teva clau privada amb la clau pública que l'altra part t'envia. És el «(gᵇ)ᵃ» de l'intercanvi, el que produeix el secret compartit de trenta-dos bytes que cap dels dos va arribar a transmetre:

pub fn scalarmult(secret_key: [secret_length]u8, public_key: [public_length]u8) IdentityElementError![shared_length]u8 {
    const q = try Curve.fromBytes(public_key).clampedMul(secret_key);
    return q.toBytes();
}

Dues línies més. La clau pública rebuda s'interpreta com un punt sobre la corba, i es «multiplica» per la clau privada pròpia. Per la commutativitat de l'operació de corba —anàloga a la commutativitat de la multiplicació d'exponents que vam veure en l'exemple numèric—, ambdues parts acaben amb el mateix punt serialitzat: exactament el secret compartit del qual parla l'article.

Què protegeix el xifratge d'extrem a extrem

El que l'E2EE protegeix bé, assumint una implementació correcta, és el contingut del missatge en trànsit. Un servidor intermedi que rebi i reenvii les dades xifrades veurà una successió de bytes inintel·ligibles. Un atacant amb accés al cable, al router, al punt d'accés wifi, veurà el mateix. Un proveïdor del servei que conservi còpies del trànsit no podrà llegir-lo a posteriori. Un Govern que ordeni a l'operador del servei lliurar el contingut rebrà els mateixos bytes inintel·ligibles que tenia el servidor en primer lloc.

Això, en termes pràctics, és molt. És la diferència entre escriure una carta dins d'un sobre opac i escriure-la en una postal. Les dues arriben. Només una preserva el contingut davant del carter.

Què no protegeix el xifratge d'extrem a extrem

Convé saber-ho igual de bé. L'E2EE no protegeix les metadades: el servidor segueix sabent que l'usuari A envia dades a l'usuari B, a quina hora, amb quina freqüència i des d'on, encara que no sàpiga què diu. Aquestes metadades, ja ho hem argumentat a Xifrar no és ser privat, són sovint més reveladores que el contingut. Saber que algú va trucar a un despatx d'advocats especialitzat en divorcis un divendres a les 22:00 durant trenta minuts explica una història que el contingut de la trucada mai va explicar. És la mateixa situació que veure una persona entrar i sortir diverses vegades d'una clínica oncològica: no cal sentir res del que es parla dins per imaginar el que està passant. Una sola metadada solta pot no significar res; diverses de creuades entre si dibuixen una cosa massa semblant a la veritat. L'E2EE no protegeix els extrems: si el dispositiu del receptor està compromès per un programa maliciós, el missatge es desxifra normalment per a aquest receptor i el programa maliciós el llegeix. L'E2EE no protegeix contra la identitat de l'interlocutor en si: si l'Alícia creu estar parlant amb en Bru però un atacant s'ha interposat a l'inici (un man in the middle) i el protocol no inclou verificació independent, les dues parts acaben parlant amb l'intrús pensant que parlen entre si.

Hi ha una quarta cosa que convé formular sense ambigüitat. L'E2EE no impedeix que un proveïdor que afirma oferir-lo guardi, a més, una còpia del missatge sense xifrar en els seus propis sistemes. L'afirmació «els meus missatges estan xifrats d'extrem a extrem» i l'afirmació «el proveïdor no conserva el meu contingut» no són la mateixa. Una aplicació pot complir la primera mentre incompleix la segona; ho hem vist en titulars de premsa repetidament des del 2018. L'usuari, tret que el codi del client sigui verificable, no té forma tècnica de distingir un cas de l'altre sense investigació experta. El cas més conegut en el públic general: WhatsApp xifra els missatges d'extrem a extrem en trànsit, però si l'usuari activa la còpia de seguretat a iCloud o Google Drive sense xifratge addicional, aquesta còpia s'emmagatzema llegible en infraestructura d'un tercer, i el xifratge es trenca a l'extrem del propi usuari.

La pregunta que l'operador no vol sentir

Una aplicació que afirma xifrar d'extrem a extrem pot, tècnicament, fer una de tres coses pel que fa a les claus:

  1. Les claus resideixen només en els dispositius. Es generen i resideixen exclusivament en els dispositius dels usuaris; l'operador no les coneix ni les emmagatzema. És el cas òptim.
  2. L'operador pot accedir-hi si vol. L'operador té les claus dels usuaris (o pot generar-les al seu gust) i les guarda en les seves bases de dades. Si vol o se l'obliga, pot llegir el contingut. Aquest és el cas de la majoria de serveis «al núvol».
  3. L'operador no pot accedir-hi per disseny, però controla l'accés. L'operador no té les claus, però té el control de l'aplicació que les genera. Si se l'obliga, pot enviar una actualització maliciosa que capturi les claus o el contingut abans de xifrar. Aquest és el cas de molts serveis E2EE comercials.

La pregunta operativa, per tant, no és si una cosa està xifrada, sinó qui té el control del dispositiu i del programari que gestiona les claus. A Solo2, les claus resideixen únicament en la teva Bòveda (IndexedDB xifrada amb la teva contrasenya) i el programari és codi obert verificable.

Per al lector professional

El xifratge d'extrem a extrem és una eina de sobirania digital. Però com tota eina, la seva eficàcia depèn de la mà que l'empunya i del sòl en què es recolza.

  1. On es generen les claus criptogràfiques i on resideixen físicament? Si l'operador pot accedir-hi (fins i tot temporalment, fins i tot sota formulació de recuperació), l'E2EE és nominal.
  2. Existeix verificació independent de l'interlocutor (números de seguretat, codis QR, comparació fora de banda) que impedeixi un atac d'home en el medi durant l'establiment de la conversa?
  3. El codi del client és auditable —obert, publicat, reproduïble— o exigeix confiar en la paraula del proveïdor sobre el que el client fa en realitat?
  4. Quines metadades genera i conserva el servei, i per quant de temps? Encara que el contingut sigui opac, les metadades poden reconstruir bona part de la informació sensible.

Aquestes quatre preguntes no demanen informació tècnica avançada; demanen informació que qualsevol operador honest pot respondre en la seva documentació pública. La qualitat i precisió de la resposta diu tant del producte com la resposta mateixa.


El xifratge d'extrem a extrem, ben fet, és una de les construccions més fines que la criptografia contemporània ha lliurat a la pràctica quotidiana. La idea original —dues persones poden acordar un secret en un canal públic— pertany a Whitfield Diffie i Martin Hellman, 1976; mig segle després seguim vivint en la seva conseqüència. Però, com passa amb qualsevol promesa tècnica, el seu valor depèn del compliment real, no de l'etiqueta. La pregunta del professional honest no és «està xifrat?», sinó «qui té les claus?». Les respostes tenen conseqüències distintes. Convé saber-les.

Fonts i lectura addicional

  • Diffie, W.; Hellman, M. — New Directions in Cryptography, IEEE Transactions on Information Theory, novembre de 1976. Article fundacional de la criptografia de clau pública.
  • Perrin, T.; Marlinspike, M. — The Double Ratchet Algorithm, especificació pública d'Open Whisper Systems, revisió de 2016. Base del protocol Signal i els seus derivats industrials.
  • RFC 7748 — Elliptic Curves for Security (IETF, gener de 2016). Especificació normativa de les corbes X25519 i X448 usades en intercanvis de clau moderns.
  • Ferguson, N.; Schneier, B.; Kohno, T. — Cryptography Engineering: Design Principles and Practical Applications (Wiley, 2010). Capítols sobre intercanvi de claus i protocols de xifratge autenticat.
  • Reglament (UE) 2024/1183 d'espai europeu d'identitat digital (eIDAS 2) — estableix marcs on la verificació independent de l'interlocutor adquireix suport institucional, i on la distinció entre xifratge nominal i xifratge real té conseqüències jurídiques diferents.

Lectures recents