Det avhenger av definisjonen din av "kompromiss". Det viktigste er privatliv, som parcimonie og tor er løsninger for, som nevnt nedenfor.

Men la oss først se på dataintegritet.

Begrepet "ende-til-ende" sikkerhet er mest nyttig når det dekker den faktiske applikasjonen du har i tankene for dataene. Siden objektene flyttes rundt av OpenPGP HTTP Keyserver Protocol (HKP) er dekket av signaturer basert på offentlig nøkkelteknologi, kan de sjekkes av applikasjonen din (f.eks. Gpg) selv. Det vil avgjøre om signaturene er gyldige, om de gjelder andre nøkler og personer du stoler på osv. ( Oppdater: Så bare gpg (valgfritt) får sertifikatene fra nøkleserveren, det stoler ikke på at noen nøkleserver oppretter gyldigheten til nøklene. )

Anta for eksempel at du bruker gpg for å sjekke signaturer på e-post. Hvis gpg forteller deg at en gitt nøkkel ikke er kjent, henter du den fra en nøkleserver. Kanskje e-posten din forteller deg at nøkkelen er kjent, men ikke klarert, siden det ikke er en klarert bane (f.eks. Utnytte wotsap) fra de til slutt pålitelige nøklene til den som signerte e-posten ( som denne). Så du ser på signaturene, og finner nøkkelen til noen som er kjent med noen du kjenner, og som stoler på den gitte nøkkelen og laster ned den også. Hvis du ender opp med en vei du stoler på, er alt bra. Hvis noen mukker med nøklene mens du laster dem ned, får du enten ikke en klarert bane (på grunn av ødelagte eller uhjelpelige nøkler), eller (og dette vil være ganske uvanlig) får du en annen bane som kan eller kan fungerer ikke for deg. Poenget er imidlertid at du fortsatt må bruke gpg for å sjekke stiene, og evaluere "immaterielle eiendeler" i tillitsveien selv (hvor mye du stoler på folk og deres forståelse av signaturer osv.) . Men du må alltid gjøre det med PGP. Det er således "ende-til-ende" i den forstand at det er sikret hele veien fra personen som laget signaturen, til programvaren din som sjekker signaturen og dine konfigurerte tillitsrøtter, og er dermed ganske mye ideell. / p>

Sikkerheten ved transporten er ikke spesielt viktig, og bruk av TLS og tilhørende PKI og sertifikater vil legge til ekstra kompleksitet, kostnad og sprøhet i PGP-nøklerserverinfrastrukturen uten å forbedre dataintegriteten. Hvis noen rotet med transporten, kan de nekte deg service, eller gjøre noe sånt som et phishing-angrep, men du må nesten alltid takle slike problemer uansett.

Se f.eks. delen "Sikkerhetshensyn" i (utløpt, men antagelig fortsatt nyttig) Internett-utkast om emnet: draft-shaw-openpgp-hkp-00 - OpenPGP HTTP Keyserver Protocol (HKP)

Et mye mer viktig dataintegritetsproblem vil være risikoen for å bli matet med et nøye utformet "malware-sertifikat" som kan utnytte et bufferoverløpssårbarhet i gpg-klienten, eller noe sånt. Jeg har ikke hørt om noen slike utnyttelser i gpg, men de har skjedd for SSL: yaSSL Certificate Processing Buffer Overflow Sårbarhet - CNET. Dette utforskes mer på Hvilke risikoer er forbundet med å koble til en ikke-klarert server for offentlig nøkkel?

Oppdatering : En mer problematisk bekymring er personvern . Hvis du ikke vil at folk skal kunne se hvilke nøkler du søker etter, eller å rote med nøkkeloverføringene dine, vil bruk av TLS være et alternativ. Men det beskytter deg ikke mot serveren og vet hva du er interessert i.

@ teris-riel utvider personvernproblemet: Se for deg at noen sender deg en signert og deretter kryptert e-post. E-postklienten henter gjerne nøkkelen til signaturen. Evan ser på trafikken og ser nøkkelen fly forbi. Nå vet han 1) at du kan lese meldinger kryptert med nøkkelen han sendte til, 2) at du har lest den aktuelle meldingen, og 3) den omtrentlige tiden du leser den. Hvis denne typen bekreftelsesangrep bekymrer deg, bruk hkps og Tor for å hente nøkler, og ikke gjør det automatisk. parcimonie er et verktøy som fungerer for å løse dette problemet.

Og som en parcimonie-implementering i bash bemerker: gpg - -refresh-keys avslører hele listen over PGP-nøkler til nøkleserveren du bruker, så vel som den som hører på avlyttingen din hvis du bruker en ukryptert protokoll som HKP (som er standard for de fleste oppsett). Det er dårlig.

Så bruk noe som parcimonie.

Det er noen alternative protokoller, men å finne servere for de som inneholder nøklene du vil synes vanskelig:

• Symantecs PGP Global Directory bruker https.
• LDAP eller LDAPS (over TLS) - Og se PGP LDAP Keyserver Comparison. Men se også PGP: Public Key Servers av David E. Ross
• RFC 4387 som gir et https-alternativ. Men jeg er ikke sikker på hvor mange servere det er der ute.

Se også

• Hvordan skal jeg distribuere den offentlige nøkkelen min?
• Key Server (Wikipedia)

Det nytter ikke å bruke en sikker tilkobling til nøkkelserveren, fordi du heller ikke skal stole på nøkkelserveren.

I OpenPGP (protokollen som GnuPG implementerer) , får du tillit til en offentlig nøkkel i kraft av at den nøkkelen er signert av noen hvis offentlige nøkkel du stoler på. Dette er rekursivt, så ideen er å skaffe en nøkkelring, hver signere den neste, fra en nøkkel du kjenner absolutt (i utgangspunktet nøkkelen din, eller nøkkelen til noen du fysisk møtte og som ga deg sin offentlige nøkkel ved den anledningen ) til nøkkelen du vil bruke. Dette er en slags Public Key Infrastructure kjent som Web of Trust. De "offentlige nøklene signert av andre mennesker" er faktisk "sertifikater". Hvordan du skaffer sertifikater har ingen innflytelse på sikkerheten, siden du kun bruker sertifikater som du kan bekrefte signaturen for. Dermed kan de lagres på en offentlig server som ikke antas å være spesielt pålitelig, og overføres i klar tekst uten beskyttelse.

Faktisk sikkerhet i en WoT oppnås ved å finne flere (mange) validerende baner; en enkelt sti er ikke nok. Dette er fordi å være sikker på at nøkkel K tilhører Bob, ikke nødvendigvis innebærer at den nøkkelen K ' som er signert av Bob, virkelig tilhører den som Bob tror det gjør. I X.509 terminologi (en annen PKI-standard) er en WoT som "alle er en sertifiseringsmyndighet". Dette fungerer ikke bra fordi Bob kan være lettroende, eller kanskje tilbøyelig til å hensynsløst signere andre nøkler etter sin tredje halvliter. Dette avbøtes ved å kreve et overdefinert sett med sertifikatbaner, dvs. at nøkkelen du vil bruke er signert av mange forskjellige Bobs, under antagelse om at du lager en falsk nøkkel (dvs. en nøkkel med feil identitet, men likevel signert av andre mennesker) ville kreve for mye innsats (eller for mye øl) fra angriperen.

I det hele tatt fungerer ikke PGP verdensomspennende WoT bra. Det som fungerer bra er å utveksle nøkler gjennom ethvert usikkert medium (en nøkkelserver, enkle e-postmeldinger ...) og deretter ringe nøkkelholderen og bytte ut "fingeravtrykket" (som er en hash av nøkkelen). Noen inkluderer fingeravtrykk med offentlig nøkkel på visittkortet. I utgangspunktet en direkte sertifisering uten å gå gjennom en Bob. Slik blir OpenPGP vant til det meste, og det er greit.

De fleste ser ut til å snakke om PGP-nøkler når de faktisk snakker om PGP-sertifikater . ( Kapittel 1 i dokumentet Introduksjon til kryptografi i PGP 6.5.1-dokumentasjonen bruker ikke uttrykket "PGP-nøkkel", men "PGP-sertifikat".)

Akkurat som X .509-sertifikater, sikkerhetsverdien til PGP-sertifikatet ligger i signaturen (e) og forbrukerens evne til å binde undertegneren til en enhet den kjenner og stoler på. Hovedforskjellen mellom X.509- og PGP-sertifikater er at et X.509-sertifikat bare kan ha én signatur og utsteder (derav en del av et hierarki), mens PGP-sertifikater regelmessig kan oppdateres med ekstra signaturer, og hevder bindingen mellom publikum nøkkel og identitet. ( Så vidt jeg vet er PGP-sertifikater alltid i det minste selvsignerte, noe som ikke garanterer mye. EDIT, takket være @nealmcb)

Få sertifikatet over en sikker transportmekanisme ville ikke legge til mye (som @nealmcb sa). Det som betyr noe er å være i stand til å kunne kjede den tilbake, ved hjelp av signaturene, muligens via mellomprodukter, til en undertegner du kjenner og stoler på. Selvfølgelig, akkurat som med X.509, må det være et "sprang av tro" (eller "diktert" bedriftens tillit) når du kommer til toppen.

Hvis keyserver.ubuntu.com serverte nøklene sine over TLS (forutsatt et X.509-sertifikat) , vil du absolutt vite at PGP-sertifikatet du lette etter ikke har blitt kompromittert mellom serveren og deg (forutsatt at du stoler på den utstedende CA for sertifikatet). Imidlertid, hvis du stoler på nøkkelen på grunn av dette, vil du ende opp med å blande to modeller: det er ikke fordi en nøkkelserver er vert for et PGP-sertifikat, at det kommer med noen påstand om hvordan du skal stole på innholdet. Nøkkelservere er bare repositorier av sertifikater.

Faren din her kommer i form av spoofing av den eksterne plasseringen, og dette vil mest sannsynlig skje via DNS, noe som ikke hjelper ved å bytte til HTTPS.

Jeg vil si at det beste alternativet her er å laste ned regelmessig, men bekreft manuelt med mottakeren at nøkkelen er riktig.

Dette er noen lange svar, så jeg vil prøve å være kort: en sikker tilkobling gir to fordeler:

• Data er skjult for en tredjepart
• Data er autentisert, så det kan ikke endres av en tredjepart

Sjelden (men muligens i noen tilfeller) blir henting av en offentlig kryptografinøkkel ansett som sensitiv hvis den blir utsatt. Det kan være et problem om Eve kommer til å vite altfor mye bare ved å finne ut at Alice og Bob har byttet nøkkel, men for alle grunnleggende formål trenger vi ikke å skjule noe for en tredjepart, så vi trenger ikke kryptere den.

Den offentlige nøkkelen du laster ned bekreftes av det kryptografiske fingeravtrykket som allerede ville blitt utvekslet for å være sikkert. Ettersom autentisering er innebygd i nøklene (så mye som du allerede kjenner fingeravtrykket), vil et ekstra lag med autentisering utover det være overflødig.

Når GPG-nøkler overføres med ren tekst, er det fortsatt sikre. Enten det blir transportert med SSL, privat kurer eller sprøytesmerter på siden av en vegg, er autentiseringen en integrert del av nøkkelen, og den offentlige eksponeringen utgjør nesten aldri noen risiko.

Kort sagt: Jeg kan bli lurt fordi den ikke bruker HTTPS.

fordi: HTTP kan "omskrives" on-the-fly (MITM), og derfra kan angriperen gi en falsk GPG-server til meg.