Concepts/OpenPGP Getting Started/ca: Difference between revisions

From KDE Wiki Sandbox
(Created page with "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 e...")
No edit summary
 
(16 intermediate revisions by 2 users not shown)
Line 22: Line 22:
== Seguretat de la clau ==
== 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.
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).
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).
Line 31: Line 31:
== La clau principal i les subclaus ==
== 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 desencriptat 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).
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).




Line 52: Line 52:
== Tipus i longitud de la clau ==
== 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).
Els tipus de claus ben admesos són DSA (només les signatures), ElGamal (només l'encriptatge), RSA (ambdós) i ECDSA (utilitzant corbes el·líptiques). GnuPG ofereix la creació de claus amb una longitud des de 1024 fins a 4096 bits (a partir del 08/2020).


The differences in security, execution time, signature size, and being required or just considered optional by the standard (rfc4880) are irrelevant for most scenarios. The one relevant difference is: The g10 smartcard supports RSA only. Thus generate an RSA key unless you have concrete and good reason for a different decision. 1024 bit keys are considered breakable by certain well known government agencies today or in the near future. 2048 bit keys are considered safe for decades. But remember: These well known agencies would not waste their time and money by computing your key. They would steal your key. Thus if you want a larger key in order to be safe against this kind of opponent then make sure that they cannot steal it. This obviously requires profound knowledge, discipline and probably some money. The practical reasons against very long keys are: Commonly used versions of GnuPG do not support keys with more than 2048 or 3072 bit respectively length. Operations with asymmetric keys are costly in general. To make it worse: Operation with twice the key size take eight times as long. And it takes long to generate huge keys. For mobile devices this CPU load can become a problem.
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.
 
Thus: Unless you have concrete and good reason for a different decision stick to 2048 bit (at least for everyday keys).


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 ==


The main key can set (and change) the expiration date for itself and its subkeys. The only "disadvantage" of an expiration date for others is that they have to update the key to keep it usable. But keys shall be updated regularly anyway so you may consider that an advantage as well. The main advantage of an expiration date (for the main key, too) is that keys which are not used any more can easily be recognized as such. The "official" way is another, of course. If a key is abandoned then a revocation certificate should be published. But this may be impossible (key or passphrase lost and no certificate created before (or lost, too)) or you may simply forget to do so (or to publish it everywhere). The "right" validity period is a compromise between reducing disturbance by expired keys (on both sides; remember that you need a secure environment to change the expiration date with an offline main key) and the time which a key still appears valid. One year may be a good choice.
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ó ==
== Certificat de revocació ==


A revocation certificate is a file (or print-out) which you may create preventively to later revoke a whole key in case you have no access to the secret main key any more. This is a huge advantage if you have not just lost access to the key but someone else has! The disadvantage is: You should protect this file / print-out similarly well as the secret main key itself. It can be serious damage if you have only one (suitable) key, need it urgently and someone else destroys it right then. Obviously a main key revocation is forever (cannot be superseded by a newer self-signature).
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).


If you (or someone else you really trust) have another key which is secure enough then you may add this key as a designated revoker to yours (you need not publish this). A designated revoker can revoke another key. Of course, the signature for the designated revoker must be available when this shall be used. If you have not given it to the other person and lost it together with your key then this is useless. If you prefer security over availability then you may make friend A your designated revoker, encrypt this signature for friend B and ask friend C to store it.
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 ==
== Frase de contrasenya, emmagatzematge segur i còpia de seguretat ==


You should think about where you will store the passphrase for the main key and the revocation certificate file or print-out. Secure passphrases are hard to remember. You will most probably have to write it down. You really should not use a passphrase you have ever typed on an insecure system (and, of course, you really should not ever do so in the future). You should choose something like rsbBwNl137LcWP33RI: 18 chars consisting of lower and upper case letters and digits. Don't use special chars or umlauts. You gain little security (if you cannot remember 18 random chars then you probably cannot remember 15, too) but may get problems if you are ever forced to use the key on a rescue system (text mode Linux) with "wrong" keyboard settings. You improve security if you memorize a part of the passphrase and write down just the rest or if you write down both halves of it separately and store them in different places (one in your wallet, the other one at home). But if you store an 18 chars passphrase in two parts and an attacker gets one of them then the remaining 9 chars are not a secure protection any more. If you have created a revocation certificate then you have to store that in a safe place, too.
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.


And, of course, you should have reliable backups of your key. It is nice if you need not be afraid that somebody has stolen your key but it is probably very unpleasant if you cannot decrypt your data any more. If you have a secure passphrase then you may even put a backup of your secret main key on your web site.
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 ==
== Política de la clau i política de l'URL ==


You should write a document (plain text or HTML) which describes the intended usage and security of your key and (maybe added later) your criteria for certifying the keys of other people. You can write one or more URLs at which this document can (later) be found into the key and in every signature you make. This key component is called a policy URL. It is a good idea to publish only user ID signatures which contain this policy URL(s). It is important that the users of your key can check whether a certain document belongs to a policy URL (the web server download is not safe, not even over HTTPS). Thus you should change the policy URL every time you change the document and mention the URL well visible in the document. You may use this pattern: <tt><nowiki>http://yourdomain.example.org/openpgp/0x12345678__policy.1.htm</nowiki>l</tt> This document should have a detached signature (or a cleartext signature if it is plain text) by the offline main key. You should link the detached signature from the document.
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ó: <tt><nowiki>http://vostredomini.exemple.org/openpgp/0x12345678__policy.1.htm</nowiki>l</tt> 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 ==
== Servidor de claus preferit ==


Like the policy URL a key server URL can be written into the key. You should decide which key server shall be authoritative for your key so that the users of your key know where they have to search for the "officially current version" of your key. This should be the key server which you upload key updates to first. This should be the one you configure in the GnuPG config file (<code>--keyserver</code>) for key searches and uploads. This address should mainly be available for a long time and have only few and short outages. You may even use your own web site: <tt><nowiki>http://yourdomain.example.org/openpgp/0x12345678.asc</nowiki></tt>
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 (<code>--keyserver</code>) 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: <tt><nowiki>http://vostredomini.exemple.org/openpgp/0x12345678.asc</nowiki></tt>


Availability is improved if a server pool (with the same DNS address) is used. If you have no better idea then you may use <tt>hkp://pool.sks-keyservers.net</tt> or one of the more local pools <tt>hkp://eu.pool.sks-keyservers.net</tt> (Europe), <tt>hkp://na.pool.sks-keyservers.net</tt> (North America) or <tt>hkp://sa.pool.sks-keyservers.net</tt> (South America). See http://sks-keyservers.net/overview-of-pools.php
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 <tt>hkp://pool.sks-keyservers.net</tt>, o un dels consorcis locals <tt>hkp://eu.pool.sks-keyservers.net</tt> (Europa), <tt> hkp://na.pool.sks-keyservers.net</tt> (Amèrica del nord) o <tt>hkp://sa.pool.sks-keyservers.net</tt> (Amèrica del sud). Veure http://sks-keyservers.net/overview-of-pools.php




== Preferències de l'algorisme ==
== Preferències de l'algorisme ==


You can also write into your key (for others) and into your config file (for your actions) in which order you prefer the cipher and digest algorithms. You should do this before you generate the key (this is easier than changing it afterwards). It makes sense to avoid SHA-1. Please be aware that you cannot prevent that GnuPG creates SHA-1 signatures with your key (because that is the only digest required by the standard). You may want to put lines like these in your <tt>gpg.conf</tt>:
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 <tt>gpg.conf</tt>:


  {{Input|1=<nowiki>
  {{Input|1=<nowiki>

Latest revision as of 21:40, 20 December 2021

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 ben admesos són DSA (només les signatures), ElGamal (només l'encriptatge), RSA (ambdós) i ECDSA (utilitzant corbes el·líptiques). GnuPG ofereix la creació de claus amb una longitud des de 1024 fins a 4096 bits (a partir del 08/2020).

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

Retrieved from "https://wikisandbox.kde.org/index.php?title=Concepts/OpenPGP_Getting_Started/ca&oldid=470327"