Concepts/OpenPGP Getting Started/ca: Difference between revisions

From KDE Wiki Sandbox
(Importing a new version from external source)
(Updating to match new version of source page)
Line 52: Line 52:
== Tipus i longitud de la clau ==
== Tipus i longitud de la clau ==


<div class="mw-translate-fuzzy">
Els tipus de claus amb una àmplia implementació són DSA (només les signatures), ElGamal (només l'encriptatge) i RSA (ambdós). Aviat s'afegirà ECDSA (utilitzant corbes el·líptiques). GnuPG ofereix la creació de claus amb una longitud de 1024 a 4096 bits. Aquesta és la situació actual (any 2013).
Els tipus de claus amb una àmplia implementació són DSA (només les signatures), ElGamal (només l'encriptatge) i RSA (ambdós). Aviat s'afegirà ECDSA (utilitzant corbes el·líptiques). GnuPG ofereix la creació de claus amb una longitud de 1024 a 4096 bits. Aquesta és la situació actual (any 2013).
</div>


Les diferències en la seguretat, el temps d'execució, la mida de la signatura, i el compromís o la conveniència de certs requisits fonamentals de la norma (rfc4880) són irrellevants per a la majoria dels escenaris. L'única diferència rellevant és la següent: La targeta intel·ligent g10 només implementa RSA. Per tant, llevat que hi hagi una raó específica i important per triar un tipus de clau diferent, hem de donar prioritat a la creació de claus RSA. Les claus de 1024 bits són considerades fràgils per certs organismes governamentals avui o en un futur pròxim. Les claus de 2048 bits es consideren segures durant dècades. Però recordeu: Aquestes agències no perdran el seu temps i diners en calcular la vostra clau. És més fàcil robar-la. Per tant, si voleu una clau més llarga, ja que voleu protegir institucions d'aquest nivell, haureu de tenir cura que la clau serà difícil de robar. Això, evidentment, requereix un profund coneixement, disciplina i, probablement, una quants calers. Les raons pràctiques contra claus molt llargues són: les versions utilitzades habitualment en GnuPG no implementen claus amb una longitud superior a 2048 o 3072 bits. Les operacions amb claus asimètriques són costoses, en general. Per empitjorar les coses: L'augment doble de la mida de la clau prendrà vuit vegades més de temps per a processar-la. I es necessita molt temps per a generar claus enormes. Per a dispositius mòbils, aquesta càrrega de la CPU pot arribar a ser un problema important.
Les diferències en la seguretat, el temps d'execució, la mida de la signatura, i el compromís o la conveniència de certs requisits fonamentals de la norma (rfc4880) són irrellevants per a la majoria dels escenaris. L'única diferència rellevant és la següent: La targeta intel·ligent g10 només implementa RSA. Per tant, llevat que hi hagi una raó específica i important per triar un tipus de clau diferent, hem de donar prioritat a la creació de claus RSA. Les claus de 1024 bits són considerades fràgils per certs organismes governamentals avui o en un futur pròxim. Les claus de 2048 bits es consideren segures durant dècades. Però recordeu: Aquestes agències no perdran el seu temps i diners en calcular la vostra clau. És més fàcil robar-la. Per tant, si voleu una clau més llarga, ja que voleu protegir institucions d'aquest nivell, haureu de tenir cura que la clau serà difícil de robar. Això, evidentment, requereix un profund coneixement, disciplina i, probablement, una quants calers. Les raons pràctiques contra claus molt llargues són: les versions utilitzades habitualment en GnuPG no implementen claus amb una longitud superior a 2048 o 3072 bits. Les operacions amb claus asimètriques són costoses, en general. Per empitjorar les coses: L'augment doble de la mida de la clau prendrà vuit vegades més de temps per a processar-la. I es necessita molt temps per a generar claus enormes. Per a dispositius mòbils, aquesta càrrega de la CPU pot arribar a ser un problema important.


Per tant: A menys que tingueu una concreta i bona raó per a prendre una decisió diferent, utilitzeu claus de 2048 bits (almenys per a les claus d'ús quotidià).
Per tant: A menys que tingueu una concreta i bona raó per a prendre una decisió diferent, utilitzeu claus de 2048 bits (almenys per a les claus d'ús quotidià).


== Venciment de la clau ==
== Venciment de la clau ==

Revision as of 14:29, 6 September 2020

Other languages:

Introducció

Quan es crea una clau, prendreu diverses decisions tècniques i d'organització (si sou o no conscient), que influeixen en gran mesura sobre la seguretat i usabilitat de la vostra clau, resultant en la vida útil de la clau. Algunes d'aquestes decisions no es podran canviar després. Per diverses raons, és desitjable que les claus normals -fins i tot les més insegures- (almenys el seu nucli) disposin d'una vida útil llarga.

De manera que el present article us familiaritzarà amb els aspectes importants de la generació de claus i us ajudarà a generar una bona clau que podreu utilitzar durant molts anys. Aquest article només cobreix els conceptes que heu de conèixer, no conté una guia d'aprenentatge pas a pas per a la generació de claus, atès que han de ser fases diferents: En primer lloc entendre i planejar el que fareu i fer els preparatius necessaris. Si heu acabat, feu una ullada a l'article Generar claus OpenPGP.

Com començar

Podeu crear amb facilitat una clau per jugar una estona. Però si permeteu que els altres verifiquin la clau, us arrisqueu a llençar el treball més tard. El vostre objectiu ha de ser la creació d'una o diverses claus de vida llarga. El millor consell és: No ho intenteu tot sol si ho podeu evitar. Contacteu amb els que tenen experiència, les persones que ja han substituït una clau pròpia i apreneu-ne. Utilitzeu un sistema segur per a crear una clau, utilitzeu una clau principal estan desconnectats i doneu tant a la clau principal com a les subclaus una data de caducitat (no més d'un any). Seleccioneu una política per a la clau (que descrigui la seguretat i l'ús de la clau principal i de les subclaus) i manteniu-la estrictament. Si certifiqueu altres claus abans de tenir una política de certificació, no se certificarà per al públic (web de confiança), en comptes d'això, creeu signatures locals (no exportables). Eviteu fer coses noves abans d'entendre bé el que signifiquen.

I recordeu això:

  1. El que és còmode (gairebé sempre) sempre posa en perill la vostra seguretat.
  2. Més seguretat no sempre és millor per a la tasca encomanada. No obstant, tingueu en compte les conseqüències (en ambdues direccions).


Benvingut al món de la criptografia!


Seguretat de la clau

Si es tracta de claus, llavors la pregunta principal és: Com de segures / fiables són i el seu ús? La regla més important de la criptografia no és «fer que sigui encara més segur», però «(1) Penseu en la quantitat de seguretat que necessiteu. (2) Decidiu quin esforç tècnic sembla necessari (límit inferior) i raonable (límit superior) per complir amb aquests requisits. (3) Observeu estrictament les regles establertes (anoteu-les). (4) Si hi estan involucrades altres persones (sol ser el cas), que sàpiguen amb precisió i seguretat quins són els límits d'ús i el nivell de seguretat d'aquesta clau». La majoria de les següents consideracions tracten sobre la seguretat i la transparència de la seva seguretat i el seu significat.

Ningú peta les claus amb atacs de força bruta. Això és (fins i tot per a les claus curtes, diguem 1024 bits) simplement impossible per a tothom per sota del nivell d'una agència governamental en un país «ric», almenys durant les pròximes dècades. I no tindria sentit: És molt més fàcil robar-les. Probablement, el sistema que esteu utilitzant per llegir aquest text (si no l'heu imprès...) no és molt segur. De fet, no existeix un sistema segur per llegir el correu electrònic o les pàgines web. No cal discutir, simplement accepteu-ho. Si no ho feu, el més probable és que només us comprometeu. Una clau mai és més segura que el sistema menys segur sobre el qual s'ha utilitzat (això, per descomptat, inclou: creació). I és més segura que el sistema menys segur sobre el que s'ha emmagatzemat, només per la seva frase de contrasenya, la qual no està protegida contra un atac de força bruta, si no és realment aleatòria o amb menys de 16 caràcters de longitud (lletres minúscules/majúscules i dígits).

És perfectament correcte utilitzar OpenPGP en sistemes segurs (és a dir, ordinadors normals). Vosaltres i els vostres companys de comunicació(!) haureu de tenir en compte el nivell de seguretat. El següent nivell de seguretat són les targetes intel·ligents. No es pot robar una clau d'una targeta intel·ligent (se'n pot abusar, si algú obté el control del sistema al qual està connectat la targeta intel·ligent). El següent nivell després de les targetes intel·ligents són els sistemes segurs: Desconnecteu el vostre disc dur, tots els dits USB (i similars) i la xarxa, arrenqueu des d'un mitjà segur com un DVD Live de Linux (d'una font de confiança, és clar). En un entorn tan segur, utilitzeu només claus de seguretat alta (i potser fins i tot limitat a formats de document no perillosos com text pla o HTML).


La clau principal i les subclaus

La majoria de les claus OpenPGP almenys tenen una subclau (totes tenen exactament una clau principal). La majoria de las vegades, no us haureu de preocupar per aquesta diferència. La vostra aplicació (o més aviat, l'aplicació base, habitualment GnuPG) selecciona la més adequada de forma automàtica. La clau principal és a la que es refereix l'empremta digital, i només pot certificar la clau principal: les vostres pròpies subclaus, els ID d'usuari i els ID d'usuari d'altres claus. Les subclaus poden fer tota la resta (sobretot el desencriptatge i la signatura) si les configureu d'aquesta manera. La raó de la diferència entre aquests tipus de clau s'esmenta aquí, atès que això és molt important per a la generació de la clau: Podeu separar la clau principal secreta de les subclaus secretes (amb GnuPG, això no forma part de l'estàndard OpenPGP). Després podreu substituir les subclaus, no així la clau principal (la qual seria una nova clau, no només una clau modificada). Per tant, si creeu una clau principal fora de línia durant la generació de claus, protegida mitjançant una contrasenya molt dura, deseu almenys la frase de contrasenya de forma segura i utilitzeu la clau principal (i la seva contrasenya) només en entorns segurs, després podreu mantenir aquesta clau «per sempre» (per exemple, 20 anys). Això és important per a les claus de cada dia. Les claus de seguretat alta en realitat no necessiten aquesta separació (en general, les subclaus no calen en absolut). Haureu de crear una subclau per a cada capacitat que necessiteu: encriptatge, signatura i potser autenticació (per SSH).


Entorn segur

La clau es generada en un entorn segur i la clau secreta principal mai s'utilitza en un entorn insegur. Però, què és un entorn segur? Això depèn del nivell de seguretat de la clau. Si voleu protegir els codis de llançament d'armes nuclears, tindreu més requeriments sobre el maquinari i el programari implicat, que si el que voleu és mantenir en secret el vostre romanç.

En qualsevol cas no heu d'arrencar des del disc dur (l'ideal és desconnectar-lo), feu-ho des d'algun mitjà fiable de només lectura. Això sol ser un Linux CD/DVD. Haureu de pagar per obtenir-lo d'una font segura. Simplement descarregant alguna imatge des d'Internet i gravant-la en un suport en blanc no tindreu un entorn segur. En general, utilitzar un CD/DVD imprès (per exemple, d'una revista o comprat pel vostre compte) sembla més digne de confiança.

El maquinari també és important. Si utilitzeu un sistema que ja se sap que s'utilitza per a la generació de claus valuoses, a algú li podria agradar la idea d'afegir-hi un capturador de teclat. Poseu atenció en els atacs més trivials: Eviteu que ningú us vegi quan escriviu la contrasenya (fins i tot a través de les finestres) i el vostre paper amb la contrasenya. Reinicieu el sistema després de la creació de la clau o (millor), apagueu-lo i manteniu-lo així durant tres minuts.


Els ID d'usuari

Els ID d'usuari formalment només són cadenes arbitràries però s'espera que constin d'un nom, un comentari opcional, i una adreça de correu electrònic. Aquesta estructura permet que el programari de correu electrònic cerqui la clau adequada per a una adreça de destinatari (que la majoria dels programes requereixen que confirmeu per raons òbvies). Una clau pública OpenPGP (més precís: certificat) ha de contenir un ID d'usuari, però pot contenir-ne tants com vulgueu. Per tant, podeu utilitzar la mateixa clau per a diverses adreces de correu electrònic (el que només té sentit si aquestes adreces s'utilitzen en el mateix nivell de seguretat). La combinació d'adreces té avantatges i desavantatges. El principal avantatge és que es necessitareu menys claus i per tant tothom tindrà menys feina amb les certificacions. Els principals desavantatges són que podeu revocar els ID d'usuari però mantenir-los sempre visibles, i una clau combinada permet fer connexions trivials entre diferents rols amb els que és possible que no vulgueu connectar: persona privada, empresa, altres organitzacions (associacions, partits polítics, el que sigui). És possible que vulgueu mantenir aquests grups per separat. Fins i tot hi ha raons per mantenir separades les adreces del mateix grup: adreces de reconegut prestigi (nom.cognom@example.com), adreces anònimes (laura7u@exemple.org), adreces divertides (superman17@exemple.org). També podríeu no tenir cap raó per utilitzar mai OpenPGP amb certes adreces. Aquestes adreces no han de perquè formar part d'un ID d'usuari. La decisió d'afegir una adreça a una clau i publicar-la és per sempre. Però és fàcil afegir una adreça més endavant. Per tant, considereu-ho bé abans de generar la clau. En cas de dubte comenceu amb menys adreces.

No té sentit tenir una ID d'usuari especial sense una adreça de correu electrònic. Amb la majoria de les adreces de correu electrònic no estareu segur de tenir-los per sempre. Si revoqueu una ID d'usuari, ja que no utilitzareu més l'adreça, llavors perdreu totes les certificacions per aquesta ID d'usuari. Però mai perdreu el vostre nom (fins i tot si us caseu o similars, generalment hi ha poques raons per revocar la ID d'usuari). De manera que en tot cas manteniu les certificacions per aquesta ID. I podeu utilitzar el comentari per a aquesta ID d'una declaració sobre la clau: «Clau diària amb clau principal i política de la clau desconnectada».


Tipus i longitud de la clau

Els tipus de claus amb una àmplia implementació són DSA (només les signatures), ElGamal (només l'encriptatge) i RSA (ambdós). Aviat s'afegirà ECDSA (utilitzant corbes el·líptiques). GnuPG ofereix la creació de claus amb una longitud de 1024 a 4096 bits. Aquesta és la situació actual (any 2013).

Les diferències en la seguretat, el temps d'execució, la mida de la signatura, i el compromís o la conveniència de certs requisits fonamentals de la norma (rfc4880) són irrellevants per a la majoria dels escenaris. L'única diferència rellevant és la següent: La targeta intel·ligent g10 només implementa RSA. Per tant, llevat que hi hagi una raó específica i important per triar un tipus de clau diferent, hem de donar prioritat a la creació de claus RSA. Les claus de 1024 bits són considerades fràgils per certs organismes governamentals avui o en un futur pròxim. Les claus de 2048 bits es consideren segures durant dècades. Però recordeu: Aquestes agències no perdran el seu temps i diners en calcular la vostra clau. És més fàcil robar-la. Per tant, si voleu una clau més llarga, ja que voleu protegir institucions d'aquest nivell, haureu de tenir cura que la clau serà difícil de robar. Això, evidentment, requereix un profund coneixement, disciplina i, probablement, una quants calers. Les raons pràctiques contra claus molt llargues són: les versions utilitzades habitualment en GnuPG no implementen claus amb una longitud superior a 2048 o 3072 bits. Les operacions amb claus asimètriques són costoses, en general. Per empitjorar les coses: L'augment doble de la mida de la clau prendrà vuit vegades més de temps per a processar-la. I es necessita molt temps per a generar claus enormes. Per a dispositius mòbils, aquesta càrrega de la CPU pot arribar a ser un problema important.

Per tant: A menys que tingueu una concreta i bona raó per a prendre una decisió diferent, utilitzeu claus de 2048 bits (almenys per a les claus d'ús quotidià).

Venciment de la clau

Es pot establir (i modificar) la data de venciment per a la clau principal i les seves subclaus. L'únic «desavantatge» -per als altres- d'una data de venciment és que han d'actualitzar la clau per a mantenir-la usable. Però de totes maneres les claus s'actualitzen periòdicament, així que també ho podeu considerar un avantatge. El principal avantatge d'una data de venciment (per a la clau principal) és que les claus que no s'utilitzen es poden reconèixer més fàcilment com a tals. La forma «oficial» és una altra, per descomptat. Si una clau és abandonada, llavors s'ha de publicar un certificat de revocació. Però això pot ser impossible (s'ha perdut la clau o la contrasenya, o no s'ha creat anteriorment un certificat -o també s'ha perdut-) o potser simplement us oblideu de fer-ho (o de publicar-lo en algun lloc). El període de validesa «correcte» és un compromís entre la reducció de la pertorbació per a les claus que han expirat (en ambdós costats, recordeu que necessiteu un entorn segur per a canviar la data de venciment amb una clau principal fora de línia) i el temps que una clau encara serà vàlida. Un any pot ser una bona opció.


Certificat de revocació

Un certificat de revocació és un fitxer (o còpia impresa), que podeu crear de forma preventiva per a revocar posteriorment tota una clau en cas de no tenir accés més a la clau principal secreta. Aquest és un gran avantatge si perdeu l'accés a la clau, però algú més hi ha accedit! El desavantatge és: Haureu de protegir el fitxer/impressió de forma similar, així com la pròpia clau principal secreta. La seva pèrdua pot causar un dany significatiu si només teniu una clau (adequat), la necessiteu amb urgència i algú la destrueix en aquest moment. És evident que una revocació de la clau principal és per sempre (no es pot substituir per una auto-signatura més recent).

Si vosaltres (o algú en qui confieu) té una altra clau que és prou segura, llavors podreu afegir aquesta clau com a revocadora designada a la vostra (no cal publicar-la). Una revocadora designada pot revocar una altra clau. Per descomptat, la signatura per a la revocadora designada haurà d'estar disponible quan s'utilitzi aquesta. Si no l'heu donat a una altra persona i després la perdeu amb la vostra clau, això és inútil. Si preferiu la seguretat sobre la disponibilitat, llavors podeu fer al vostre amic un revocador designat, encripteu aquesta signatura per a l'amic B i pregunteu a l'amic C per emmagatzemar-la.


Frase de contrasenya, emmagatzematge segur i còpia de seguretat

Heu de pensar on emmagatzemareu la frase de contrasenya per a la clau principal i el fitxer o impressió del certificat de revocació. Les frases de contrasenya segures són difícils de recordar. El més probable és que l'hagueu d'escriure. Realment no hauríeu d'utilitzar una frase de contrasenya una vegada l'heu escrit en un sistema insegur (i, per descomptat, en realitat no ho heu de fer mai). Heu de triar alguna cosa com rsbBwNl137LcWP33RI: 18 caràcters que consisteixen de lletres en majúscules i minúscules així com dígits. No utilitzeu caràcters especials o dièresis. Guanyeu poca seguretat (si no podeu recordar 18 caràcters a l'atzar, llavors probablement tampoc en recordareu 15), però podeu tenir problemes si mai us veieu obligats a utilitzar la clau en un sistema de rescat (el mode de text de Linux) amb l'arranjament del teclat «equivocat». Millorareu la seguretat si memoritzeu una part de la frase de contrasenya i escriviu només la resta o si escriviu les dues meitats de manera separada i les emmagatzemeu en llocs diferents (un a la vostra cartera, l'altre a casa). Però si emmagatzema una frase de contrasenya de 18 caràcters en dues parts i un atacant n'aconsegueix una, llavors els 9 caràcters restants ja no són capaços de proporcionar una protecció adequada. Si heu creat un certificat de revocació, llavors també l'haureu d'emmagatzemar en un lloc segur.

I, per descomptat, haureu de tenir còpies de seguretat fiables de la vostra clau. És bo el no tenir por que algú hagi robat la vostra clau, però probablement és molt desagradable si no es poden desencriptar més les dades. Si teniu una frase de contrasenya segura, llavors fins i tot podeu posar una còpia de seguretat de la vostra clau principal secreta al vostre lloc web.


Política de la clau i política de l'URL

Haureu d'escriure un document (text pla o HTML) que descrigui la intenció d'ús i la seguretat de la vostra clau i (potser afegir més tard) els criteris per a la certificació de les claus d'altres persones. Hi podeu escriure un o diversos URL des d'on després podreu trobar la clau i cada signatura que realitzeu. Aquest component de la clau s'anomena un URL de política. És una bona idea publicar només els ID d'usuari de les signatures que contenen aquestes URL de política. És important que els usuaris de la vostra clau poden comprovar si un determinat document pertany a un URL de política (el servidor web de descàrrega no és segur, ni tan sols a través de HTTPS). Per tant heu de canviar l'URL de política cada vegada que canvieu el document i mencioneu l'URL visible en el document. Podeu utilitzar aquest patró: http://vostredomini.exemple.org/openpgp/0x12345678__policy.1.html Aquest document haurà de tenir una signatura separada (o una signatura de text pla si és en text pla) feta per la clau principal fora de línia. Ara heu d'enllaçar aquesta signatura separada amb el document.


Servidor de claus preferit

Igual que l'URL de política, un URL del servidor de claus es pot escriure dins la clau. Heu de decidir quin servidor de claus s'ha d'autoritzar per a la vostra clau de manera que els usuaris de la vostra clau coneguin on cercar la «versió oficial actual» de la vostra clau. Aquest ha de ser el servidor de claus on publiqueu els canvis a la clau. S'ha de configurar al fitxer de configuració de GnuPG (--keyserver) per a les cerques i publicacions de claus. Aquesta adreça haurà d'estar disponible durant molt de temps i només tenir unes poques i curtes interrupcions. Fins i tot podeu utilitzar el vostre propi lloc web: http://vostredomini.exemple.org/openpgp/0x12345678.asc

La disponibilitat es millora si s'utilitza un grup de servidors (amb la mateixa adreça DNS). Si no teniu una idea millor podreu utilitzar hkp://pool.sks-keyservers.net, o un dels consorcis locals hkp://eu.pool.sks-keyservers.net (Europa), hkp://na.pool.sks-keyservers.net (Amèrica del nord) o hkp://sa.pool.sks-keyservers.net (Amèrica del sud). Veure http://sks-keyservers.net/overview-of-pools.php


Preferències de l'algorisme

També podeu escriure dins la vostra clau (per a altres) i dins el fitxer de configuració (per a les vostres accions) sobre en quin ordre preferiu els algorismes de xifrat i les sumes de comprovació. Ho heu de fer abans de generar la clau (és més fàcil que canviar-ho després). Té sentit per evitar el SHA-1. Si us plau, tingueu en compte que no podeu evitar que GnuPG crei signatures SHA-1 amb la vostra clau (ja que és l'únic algorisme per calcular les sumes de comprovació proporcionades de sèrie). Pot ser voldreu posar unes línies com aquestes al vostre fitxer gpg.conf:

personal-cipher-preferences AES256,AES192,AES,CAST5,3DES
personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1
cert-digest-algo SHA512
default-preference-list AES256,AES192,AES,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP

Altres lectures