Translations:Concepts/OpenPGP Getting Started/14/da: Difference between revisions

From KDE Wiki Sandbox
(Importing a new version from external source)
 
(Importing a new version from external source)
 
Line 1: Line 1:
De fleste OpenPGP-nøgler har mindst en undernøgle (de har alle præcis én hovednøgle). Som regel behøver du ikke at bekymre dig om forskellen: dit program (eller rettere det underliggende program, som regel "GnuPG") vælger automatisk den rigtige. Hovednøglen der den, som nøglens fingeraftryk refererer til, og kun hovednøglen kan certificere dine egne undernøgler og bruger-ID'er og andre nøglers bruger-ID'er. Undernøglerne kan gøre alt andet (hovedsaligt kryptering og signering) hvis du konfigurerer dem således. Årsagen til at nævne forskellen imellem disse nøgletyper er, at den har stor betydning under generering af nøgler. Med GnuPG kan du separere hovednøglen fra undernøglerne (dette er ikke en del af OpenPGP-standarden!) Undernøglerne kan senere erstattes, men det kan hovednøglen ikke (det ville være en ny nøgle, ikke blot en modificeret nøgle). Ved nøglegenereringen kan du således oprette en hovednøgle off-line, som du kan beskytte med en meget stærk adgangskode, gemme i det mindste adgangskoden sikkert og så bruge hovednøglen (og dens adgangskode) i sikre omgivelser; kun således kan du beholde denne nøgle "altid" (lad os sige 20 år). Dette er vigtigt for dagligdagsnøgler. Nøgler med høj sikkerhed her egentlig ikke brug for denne adskillelse (som regel behøver du slet ikke undernøgler). Du bør oprette en undernøgle til hver af de funktioner, du har brug for: kryptering, signering og måske .autentifikation (til SSH)
De fleste OpenPGP-nøgler har mindst en undernøgle (de har alle præcis én hovednøgle). Som regel behøver du ikke at bekymre dig om forskellen: dit program (eller rettere det underliggende program, som regel "GnuPG") vælger automatisk den rigtige. Hovednøglen der den, som nøglens fingeraftryk refererer til, og kun hovednøglen kan certificere dine egne undernøgler og bruger-ID'er og andre nøglers bruger-ID'er. Undernøglerne kan gøre alt andet (hovedsaligt kryptering og signering) hvis du konfigurerer dem således. Årsagen til at nævne forskellen imellem disse nøgletyper er, at den har stor betydning under generering af nøgler. Med GnuPG kan du separere hovednøglen fra undernøglerne (dette er ikke en del af OpenPGP-standarden!) Undernøglerne kan senere erstattes, men det kan hovednøglen ikke (det ville være en ny nøgle, ikke blot en modificeret nøgle). Ved nøglegenereringen kan du således oprette en hovednøgle offline, som du kan beskytte med en meget stærk adgangskode, gemme i det mindste adgangskoden sikkert og så bruge hovednøglen (og dens adgangskode) i sikre omgivelser; kun således kan du beholde denne nøgle "altid" (lad os sige 20 år). Dette er vigtigt for dagligdagsnøgler. Nøgler med høj sikkerhed her egentlig ikke brug for denne adskillelse (som regel behøver du slet ikke undernøgler). Du bør oprette en undernøgle til hver af de funktioner, du har brug for: kryptering, signering og måske .autentifikation (til SSH)

Latest revision as of 13:57, 8 July 2013

Information about message (contribute)
This message has no documentation. If you know where or how this message is used, you can help other translators by adding documentation to this message.
Message definition (Concepts/OpenPGP Getting Started)
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).

De fleste OpenPGP-nøgler har mindst en undernøgle (de har alle præcis én hovednøgle). Som regel behøver du ikke at bekymre dig om forskellen: dit program (eller rettere det underliggende program, som regel "GnuPG") vælger automatisk den rigtige. Hovednøglen der den, som nøglens fingeraftryk refererer til, og kun hovednøglen kan certificere dine egne undernøgler og bruger-ID'er og andre nøglers bruger-ID'er. Undernøglerne kan gøre alt andet (hovedsaligt kryptering og signering) hvis du konfigurerer dem således. Årsagen til at nævne forskellen imellem disse nøgletyper er, at den har stor betydning under generering af nøgler. Med GnuPG kan du separere hovednøglen fra undernøglerne (dette er ikke en del af OpenPGP-standarden!) Undernøglerne kan senere erstattes, men det kan hovednøglen ikke (det ville være en ny nøgle, ikke blot en modificeret nøgle). Ved nøglegenereringen kan du således oprette en hovednøgle offline, som du kan beskytte med en meget stærk adgangskode, gemme i det mindste adgangskoden sikkert og så bruge hovednøglen (og dens adgangskode) i sikre omgivelser; kun således kan du beholde denne nøgle "altid" (lad os sige 20 år). Dette er vigtigt for dagligdagsnøgler. Nøgler med høj sikkerhed her egentlig ikke brug for denne adskillelse (som regel behøver du slet ikke undernøgler). Du bør oprette en undernøgle til hver af de funktioner, du har brug for: kryptering, signering og måske .autentifikation (til SSH)