Concepts/OpenPGP Getting Started/ca: Difference between revisions

From KDE Wiki Sandbox
(Created page with "== Frase de contrasenya, emmagatzematge segur i còpia de seguretat ==")
No edit summary
 
(44 intermediate revisions by 2 users not shown)
Line 3: Line 3:
== Introducció ==
== Introducció ==


When creating a key you make several technical and organizational decisions (whether you are aware of that or not) which heavily influence the security and usability of your key, as a result the operating life of the key. Some of these decisions cannot be changed afterwards. For several reasons it is desirable that normal keys – even rather insecure ones – (at least their core) have a long operating life.
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.


Thus this article shall make you familiar with the important aspects of key generation and help you generate a good key which you can use for many years. This article covers just the concepts you should be familiar with, it does not contain a step by step tutorial for key generation because these should be separate phases: First understand and plan what you are going to do and make the necessary preparations. If you have finished that have a look at the [[Special:myLanguage/Concepts/OpenPGP_Key_Generation|OpenPGP key generation article]].
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 [[Special:myLanguage/Concepts/OpenPGP_Key_Generation|Generar claus OpenPGP]].


== How to get started ==
== Com començar ==


You can easily create a key for playing around. But if you let others verify such a key you risk throwing work away later. Your aim should be to create one or more long term keys. The best advice is: Don't try on your own if you can avoid it. [[Special:myLanguage/KMail/Courses_Information_Openpgp|Ask experts]] if you can, people who already have replaced a key of their own and learnt from that. Use a secure system to create a key, use an offline main key and give both the main key and the subkeys an expiration date (not more than a year). Select a key policy (describing the security and usage of main key and subkeys) and stick to it. If you certify other keys before you have a certification policy, do not certify them for the public (web of trust), make local signatures instead (just for yourself). Avoid doing new things before you understand well what they mean.
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. [[Special:myLanguage/KMail/Courses_Information_Openpgp|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.


And remember this:
I recordeu això:


# ''What is comfortable (at least nearly) always threatens your security.''
# ''El que és còmode (gairebé sempre) sempre posa en perill la vostra seguretat.''
# More secure is not always better for the given task. Just be aware of the consequences (in both directions).
# Més seguretat no sempre és millor per a la tasca encomanada. No obstant, tingueu en compte les conseqüències (en ambdues direccions).




Welcome to the crypto world!
Benvingut al món de la criptografia!




== Key security ==
== Seguretat de la clau ==


If keys are involved then the main question is: How secure / reliable are them and their usage? The most important rule in cryptography is not "Make it even more secure" but "(1) Think about how much security you need. (2) Decide which technical effort seems necessary (lower limit) and reasonable (upper limit) to fulfill these requirements. (3) Strictly observe the rules you have determined (write them down). (4) If other people are involved (which usually is the case) let them know precisely and securely what the usage limits and the security level of this key are." Most of the following considerations are about the security and the transparency of their security and meaning.
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.


Nobody cracks keys by brute force attacks. That is (even for rather short keys, say 1024 bit) simply impossible for everyone beneath the level of a government agency of a "rich" country within the next decades. And it would not make sense: It's so easy to just steal them. With a huge probability the system which you are just using to read this text (if not printed...) is not very secure. De facto no system which is used for reading email or reading web pages is safe. Don't argue, just accept this. If you don't you probably just compromise yourself. A key is never more secure than the least secure system on which it has been used (this, of course, includes: created). And it is more secure than the least secure system on which it has been stored just by its passphrase which is no protection against a brute force attack if it is either not really random or less than about 16 characters long (for small and capital letters and digits).
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).


It is perfectly OK to use OpenPGP on such insecure systems (i.e. normal computers). You and your communication partners(!) just have to be aware of the security level. The next security level are smartcards. You cannot steal a key from a smartcard (you can abuse it nonetheless if you control the system to which the smardcard is connected). The next level after smartcards are secure systems: Unconnect your harddisk, all USB sticks (and the like) and the network, boot from a secure medium like a Linux live DVD (from a trusted source, of course!). Use high security keys in such a secure environment only (and maybe even limited to safe document formats like plain text or HTML).
É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).




== Main key and subkeys ==
== La clau principal i les subclaus ==


Most OpenPGP keys have at least one subkey (all have exactly one main key). You usually need not care about this difference; your application (or rather the base application, usually '''GnuPG''') selects the right one automatically. The main key is the one which the key fingerprint refers to and only the main key can certify: your own subkeys and user IDs and the user IDs of other keys. The subkeys can do everything else (mainly decryption and signing) if you configure them so. The reason the difference between these key types is mentioned here is that this is very important for key generation: You can separate the secret main key from the secret subkeys (with GnuPG; this is not part of the OpenPGP standard!). The subkeys can be replaced later, the main key cannot (that would be a new key not just a modified key). Thus if you create an offline main key at key generation which you protect by a very hard passphrase, store at least the passphrase securely and use the main key (and its passphrase) in secure environments only then you can keep this key "forever" (say 20 years). This is important for everyday keys. High security keys don't really need this separation (usually don't need subkeys at all). You should create one subkey for each capability you need: encryption, signing, and maybe authentication (for 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).




== Secure environment ==
== Entorn segur ==


The key shall be generated in a secure environment and the secret main key shall never be used in an insecure environment. But what is a secure environment? That depends on the security level of the key. If you want to secure nuclear weapons release codes you will have higher requirements to the hardware and software involved than if you just want to keep your affair secret.
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ç.


At any rate you should not boot from your harddisk (ideally disconnect it) but from some trustworthy read-only medium. This is usually a Linux CD/DVD. You should pay attention to getting this from a safe source. Just downloading some image from the Internet and burning it to a blank doesn't make a secure environment up. In general a pressed CD/DVD (e.g. from a magazine or bought on its own) seems more trustworthy.
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.


Hardware is important, too. If you use a system which was known in advance to be used for the generation of valuable keys somebody might like the idea to add a hardware keylogger. Pay attention to rather trivial attacks: Prevent everybody else from seeing you typing your passphrase (even through windows) and from seeing your slip of paper with the passphrase. Reboot the system after key creation or (better) power it off and keep it so for three minutes.
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.




== User IDs ==
== Els ID d'usuari ==


User IDs are formally just arbitrary strings but expected to consist of a name, an optional comment, and an email address. This structure allows email software to find the suitable key for a recipient address (which most programs require you to confirm for obvious reasons). An OpenPGP public key (more precise: certificate) must have a user ID but can have as many as you like. Thus you can use the same key for several email addresses (which makes sense only if these addresses shall be used at the same security level). Combining addresses has advantages and disadvantages. The main advantage is that you need less keys and thus you and others have less work with certifications. The main disadvantages are that you can revoke user IDs but they keep visible forever and that such a combined key allows to make a trivial connections between different roles of you which you may not want connected: private person, business, other organizations (associations, political parties, whatever). You may want to keep these groups separate. And there are even reasons to keep addresses from the same group separate: reputable addresses (firstname.lastname@example.com), anonymous addresses (heejei7u@example.org), fun addresses (superman17@example.org). It also may be that you have no reason to ever use OpenPGP with certain addresses; such addresses should not be part of a user ID, of course. The decision to add an address to a key and publish that key is forever. But it is easy to add an address later. Thus consider this well before you generate the key. In case of doubt start with fewer addresses.
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.


It makes sense to have a special user ID without an email address. With most email addresses you cannot be sure to have them forever. If you revoke a User ID because you don't use the address any more then you lose all the certifications for this user ID. But you will never lose your name (even if you marry or the like there is usually little reason to revoke that user ID). So you keep the certifications for this ID at any rate. And you can use the comment for this ID for a statement about the key itself: "everyday key with secure offline main key and key policy"
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».




== Key type and length ==
== Tipus i longitud de la clau ==


The well supported key types are DSA (signatures only), ElGamal (encryption only) and RSA (both); ECDSA (elliptic curves) is going to be added soon. GnuPG offers the creation of keys with a length from 1024 to 4096 bit. This is the current situation (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 ==


== Key expiration ==
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ó.


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.


== Certificat de revocació ==


== Revocation certificate ==
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).


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).
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.
 
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.




== 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 sage 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: http://yourdomain.example.org/openpgp/0x12345678__policy.1.html 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 (--keyserver) 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: http://yourdomain.example.org/openpgp/0x12345678.asc
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 hkp://pool.sks-keyservers.net or one of the more local pools hkp://eu.pool.sks-keyservers.net (Europe), hkp://na.pool.sks-keyservers.net (North America) or hkp://sa.pool.sks-keyservers.net (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 gpg.conf (due to design flaws AES256 and AES192 are less secure than AES(128) is currently believed to be...):
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>:


  personal-cipher-preferences AES,AES256,AES192,CAST5,3DES
  {{Input|1=<nowiki>
personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1
personal-cipher-preferences AES256,AES192,AES,CAST5,3DES
cert-digest-algo SHA512
personal-digest-preferences SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1
default-preference-list AES,AES256,AES192,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP
cert-digest-algo SHA512
default-preference-list AES256,AES192,AES,CAST5,3DES,SHA512,SHA384,SHA256,SHA224,RIPEMD160,SHA1,ZLIB,BZIP2,ZIP
</nowiki>}}


== Altres lectures ==
== Altres lectures ==
Line 107: Line 108:
* [[Special:myLanguage/KMail/gpg|KMail gpg]]
* [[Special:myLanguage/KMail/gpg|KMail gpg]]


* [[Special:myLanguage/Concepts/OpenPGP_For_Beginners|Primers passos amb OpenPGP]]
* [[Special:myLanguage/Concepts/OpenPGP_For_Beginners|OpenPGP per a novells]]


* [[Special:myLanguage/Concepts/OpenPGP_For_Advanced_Users|OpenPGP per a usuaris avançats]]
* [[Special:myLanguage/Concepts/OpenPGP_For_Advanced_Users|OpenPGP per a usuaris avançats]]

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"