/usr/share/doc/gnupg-doc/GNU_Privacy_Handbook/it/html/c520.htm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>    Uso quotidiano di GnuPG
  </TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="Manuale GNU sulla privacy"
HREF="book1.htm"><LINK
REL="PREVIOUS"
TITLE="      Distribuire le chiavi
    "
HREF="x499.htm"><LINK
REL="NEXT"
TITLE="      Costruire la propria rete della fiducia
    "
HREF="x585.htm"></HEAD
><BODY
CLASS="CHAPTER"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Manuale GNU sulla privacy</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x499.htm"
ACCESSKEY="P"
>Indietro</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x585.htm"
ACCESSKEY="N"
>Avanti</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="CHAPTER"
><H1
><A
NAME="USO-QUOTIDIANO"
></A
>Capitolo 4.     Uso quotidiano di GnuPG
  </H1
><DIV
CLASS="TOC"
><DL
><DT
><B
>Sommario</B
></DT
><DT
><A
HREF="c520.htm#DEFINIRE-REQUISITI-SICUREZZA"
>Definire i propri requisiti di sicurezza</A
></DT
><DT
><A
HREF="x585.htm"
>Costruire la propria rete della fiducia</A
></DT
><DT
><A
HREF="x595.htm"
>Usare GnuPG legalmente</A
></DT
></DL
></DIV
><P
>    GnuPG &egrave; uno strumento complesso che coinvolge questioni
    tecniche, sociali e legali.  Da un punto di vista tecnico &egrave; stato
    progettato per venir usato in situazioni con requisiti di
    sicurezza notevolmente differenti, fatto che ha complicato la
    gestione delle chiavi.  Da un punto di vista sociale, l'uso di
    GnuPG non &egrave; una decisione strettamente personale.  Per
    utilizzare veramente GnuPG entrambe le parti coinvolte nella
    comunicazione devono usarlo effettivamente.  Infine, a partire
    all'incirca dal 1999, le leggi riguardanti la criptazione
    digitale, in particolare la legalit&agrave; dell'uso di GnuPG, variano
    da stato a stato e sono tutt'ora dibattute dai governi di molte
    nazioni.
  </P
><P
>    Il presente capitolo affronta queste tematiche.  Esso fornisce
    pratici consigli su come usare GnuPG per soddisfare alle proprie
    esigenze di sicurezza.  Suggerisce anche dei modi per promuovere
    l'uso di GnuPG come strumento per comunicazioni sicure fra s&eacute; ed
    i propri colleghi, quando questi non lo utilizzano gi&agrave;.  Infine,
    viene sottolineato lo status legale di GnuPG all'interno dello
    stato corrente delle leggi sulla criptazione nel mondo.
  </P
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="DEFINIRE-REQUISITI-SICUREZZA"
>Definire i propri requisiti di sicurezza</A
></H1
><P
>      GnuPG &egrave; uno strumento per proteggere la propria privacy.  La
      propria privacy &egrave; protetta se &egrave; possibile corrispondere con
      altri senza che nessuno possa intromettersi e legga i vostri
      messaggi.
    </P
><P
>      Il modo in cui si dovrebbe usare GnuPG dipende dalla
      determinazione e dalla ricchezza di risorse di coloro i quali
      vogliono leggere i vostri messaggi criptati.  Un ficcanaso pu&ograve;
      essere un amministratore di sistema senza scrupoli che legge a
      caso la posta altrui; pu&ograve; essere una spia industriale che sta
      provando a rubare i segreti industriali della vostra compagnia;
      pu&ograve; essere un'agenzia per il rispetto della legge che cerca di
      accusarvi.  L'utilizzo di GnuPG per proteggersi contro spioni
      casuali sar&agrave; differente dall'uso di GnuPG per proteggersi
      contro avversari determinati.  L'obiettivo, in ultima analisi,
      consiste nel rendere pi&ugrave; costoso il recupero dei dati non
      criptati di quanto valgano i dati stessi.
    </P
><P
>      La personalizzazione del proprio uso di GnuPG orbita attorno a
      quattro punti:
      <P
></P
><UL
COMPACT="COMPACT"
><LI
><P
>	    la scelta della dimensione della chiave della propria
	    coppia di chiavi pubblica/privata,
	  </P
></LI
><LI
><P
>	    la protezione della propria chiave privata,
	  </P
></LI
><LI
><P
>	    la scelta delle date di scadenza e dell'uso di sottochiavi
	    e
	  </P
></LI
><LI
><P
>	    la gestione della propria rete della fiducia.
	  </P
></LI
></UL
>

      Una dimensione della chiave scelta bene protegge dagli attacchi
      a forza bruta sferrati contro i messaggi criptati.  Proteggere
      la propria chiave privata evita che un malintenzionato possa
      semplicemente usare la propria chiave privata per decifrare
      messaggi criptati e firmare messaggi a vostro nome.  La corretta
      gestione della propria rete della fiducia evita che dei
      malintenzionati fingano di essere le persone con le quali
      usualmente si comunica.  Infine, decidere per questi elementi di
      personalizzazione rispettando i propri requisiti di sicurezza &egrave;
      il modo in cui si bilancia il lavoro extra dovuto all'uso di
      GnuPG con la privacy che esso offre.
    </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN540"
>Scegliere la dimensione della chiave</A
></H2
><P
>	La scelta della dimensione di una chiave dipende dalla chiave.
	In OpenPGP una coppia di chiavi pubblica/privata possiede,
	normalmente, pi&ugrave; di una chiave.  Al minimo possiede una chiave
	di firma principale e probabilmente una o pi&ugrave; sotto-chiavi
	addizionali di cifratura.  Utilizzando i parametri
	preimpostati per la generazione di chiavi con GnuPG, la
	chiave principale sar&agrave; di tipo DSA e le sotto-chiavi di tipo
	ElGamal.
      </P
><P
>	Per lo standard DSA sono previste chiavi fino a 1024 bit.
	Questo valore non &egrave; particolarmente alto data la tecnologia di
	fattorizzazione di oggi, ma &egrave; ci&ograve; che lo standard specifica.
	Senza esitazioni si dovrebbero quindi usare chiavi DSA da 1024
	bit.
      </P
><P
>	Le chiavi ElGamal, d'altro canto, possono essere di qualsiasi
	dimensione.  Poich&eacute; GnuPG &egrave; un sistema a chiave pubblica
	ibrido, la chiave pubblica viene usata per criptare una chiave
	di sessione da 128 bit, mentre la chiave privata &egrave; usata per
	decriptarla.  Ci&ograve; nonostante, la dimensione della chiave
	influenza la velocit&agrave; di cifratura e decifratura in quanto il
	costo di questi algoritmi cresce esponenzialmente con il
	crescere della dimensione della chiave.  Chiavi grandi,
	inoltre, richiedono pi&ugrave; tempo ad essere generate e pi&ugrave; spazio
	per essere salvate.  Infine, c'&egrave; una riduzione del ritorno di
	sicurezza che una chiave grande fornisce.  Dopo tutto, se la
	chiave &egrave; tanto grande da resistere ad un attacco a forza
	bruta, uno spione semplicemente cambierebbe metodo e
	cercherebbe di ottenere i dati in chiaro in un altro modo.
	Esempi di tali metodi alternativi sono il furto in
	appartamento e la rapina.  1024 bit &egrave; perci&ograve; la dimensione di
	chiave raccomandata.  Se si ha sinceramente bisogno di una
	dimensione di chiave maggiore, allora probabilmente si
	conoscono gi&agrave; tutte queste problematiche e ci si dovrebbe
	rivolgere pertanto ad un esperto in sicurezza di dati.
      </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN545"
>Proteggere la propria chiave privata</A
></H2
><P
>	Proteggere la propria chiave privata &egrave; il lavoro pi&ugrave;
	importante che si deve considerare quando si vuole utilizzare
	GnuPG correttamente.  Se qualcuno ottiene la vostra chiave
	privata, allora tutti i dati criptati con quella chiave
	privata possono essere decifrati e firme fatte in vostro nome.
	Se si perde la propria chiave privata, allora non sar&agrave; pi&ugrave;
	possibile decriptare documenti cifrati personalmente in futuro
	o nel passato e non sar&agrave; pi&ugrave; possibile fare alcuna firma.  La
	sola perdita della propria chiave privata &egrave; un evento
	catastrofico.
      </P
><P
>	In qualsiasi modo si utilizzi GnuPG si dovrebbe riporre in
	un posto sicuro il <A
HREF="c52.htm#REVOCATION"
>certificato di
	revoca</A
> della propria chiave pubblica e salvare una
	copia della propria chiave privata su un supporto protetto da
	scrittura.  Per esempio, si potrebbe masterizzare un CD-ROM e
	riporlo nella cassetta di sicurezza della propria banca in una
	busta sigillata.  In alternativa, si potrebbe salvare il tutto
	su un dischetto e nasconderlo da qualche parte in casa
	propria.  Qualsiasi cosa si pensi di fare, chiave privata e
	certificato di revoca dovrebbero essere messi su un supporto
	che garantisca il mantenimento dei dati per tanto tempo quanto
	ci si aspetta di utilizzare la chiave e si dovrebbe salvarli
	con pi&ugrave; attenzione di quanta se ne faccia per la propria
	chiave privata di uso quotidiano.
      </P
><P
>	Nel tentativo di salvaguardare la propria chiave, GnuPG non
	salva su disco la chiave privata cos&igrave; com'&egrave;. Essa viene invece
	criptata utilizzando un algoritmo di cifratura simmetrico.
	Questo &egrave; il motivo per cui si necessita di una passphrase per
	poter accedere alla chiave.  In questo modo ci sono due
	barriere che un malintenzionato deve superare per poter
	accedere alla vostra chiave privata: deve aver effettivamente
	accessso alla chiave e deve riuscire a superare la cifratura.
      </P
><P
>	Il salvataggio sicuro della propria chiave privata &egrave;
	importante, ma c'&egrave; un costo da sostenere.  Idealmente si
	dovrebbe tenere la chiave privata su un disco rimovibile e
	protetto in scrittura, come un floppy, e lo si dovrebbe
	utilizzare su una macchina con un unico utente non connessa ad
	alcuna rete.  Ci&ograve; pu&ograve; risultare sconveniente o impossibile.
	Per esempio pu&ograve; accadere che non si possieda un computer ma ci
	ritrovi costretti ad utilizzarne uno al lavoro o a scuola.
	Oppure potrebbe succedere che ci si vedrebbe costretti a
	scollegare il proprio computer da una connessione permanente
	ogni volta che si voglia usare GnuPG.
      </P
><P
>	Tutto questo non significa che non si possa o non si debba
	usare GnuPG.  Piuttosto si &egrave; deciso che i dati da proteggere
	sono abbastanza importanti da venir cifrati, ma non cos&igrave;
	importanti da richiedere un impegno ulteriore affinch&eacute; la
	prima barriera risulti pi&ugrave; robusta.  &Egrave; una questione di scelta.
      </P
><P
>	Una buona passphrase &egrave; assolutamente cruciale nell'uso di
	GnuPG.  Qualsiasi malintenzionato che riesca a guadagnare
	l'accesso alla propria chiave privata deve oltrepassare la
	cifratura della chiave privata stessa.  Invece di indovinare
	brutalmente la chiave, il malintenzionato cercher&agrave; quasi
	certamente di indovinare la passphrase.
      </P
><P
>	Il motivo per cui si prova prima con la passphrase consiste
	nel fatto che la maggior parte delle persone sceglie una
	passphrase pi&ugrave; facile da indovinare di una chiave casuale a
	128 bit.  Se la passphrase &egrave; una parola, &egrave; molto pi&ugrave; economico
	provare tutte le parole presenti nei dizionari delle lingue
	del mondo.  Anche se i caratteri della parola sono permutati,
	per esempio ``putcomter'' invece di
	``computer'', &egrave; comunque pi&ugrave; semplice provare con
	delle parole da dizionario a cui sono applicate delle regole
	di permutazione.  Lo stesso problema si applica a citazioni.
	Generalmente le passphrase basate su frasi del linguaggio
	naturale sono poveri esempi di passphrase, in quanto esiste
	poca casualit&agrave; e molta ridondanza nel linguaggio naturale.
      </P
><P
>	Una buona passphrase &egrave; quella passphrase che si riesce a
	ricordare, ma che altri difficilmente possono indovinare.
	Essa dovrebbe includere caratteri presi da tutto lo spettro
	dei caratteri stampabili presenti sulla tastiera.  Ci&ograve; include
	i caratteri alfabetici maiuscoli, numeri e caratteri speciali
	come <TT
CLASS="LITERAL"
>}</TT
> e <TT
CLASS="LITERAL"
>|</TT
>.  Bisonga
	essere creativi e spendere un po' di tempo nel considerare la
	propria passphrase; una buona scelta &egrave; importante per
	assicurare la propria privacy.
      </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN558"
>Scegliere la data di scadenza e usare le sotto-chiavi.</A
></H2
><P
>	Per default, quando si crea una nuova coppia di chiavi,
	vengono generate una chiave di firma principale DSA ed una
	sotto-chiave di cifratura ElGamal.  Ci&ograve; risulta inconveniente
	in quanto i ruoli giocati dalle due chiavi sono differenti e
	si potrebbe perci&ograve; volere che le chiavi abbiano una differente
	durata.  La chiave di firma principale viene usata per fare le
	firme digitali e raccoglie le firme delle altre persone che
	hanno confermato la vostra identit&agrave;.  La chiave di cifratura
	viene usata solo per decifrare i documenti criptati che si
	ricevono.  Tipicamente una firma digitale possiede un tempo di
	vita lungo, cio&egrave; eterno, in quanto non si vuole perdere le
	firme applicate alla propria chiave per la raccolta delle
	quali si &egrave; lavorato duramente.  D'altro canto, la sotto-chiave
	di cifratura dovrebbe essere cambiata periodicamente per
	un'ulteriore sicurezza, poich&eacute;, se una chiave di cifratura
	viene violata, il malintenzionato pu&ograve; leggere tutti i
	documenti cifrati con quella chiave sia nel futuro che nel
	passato.
      </P
><P
>	Accade quasi sempre che non si desidera avere una data di
	scadenza per la propria chiave principale.  Ci sono due
	ragioni per le quali si potrebbe scegliere il contrario.  La
	prima &egrave; che si intende usare la chiave per un periodo
	limitato.  Per esempio la si potrebbe usare per un evento,
	come una campagna politica, dopo il quale non sarebbe pi&ugrave;
	utile.  Un'altra ragione consiste nel fatto che se si dovesse
	perdere il controllo della chiave senza possedere un
	certificato di revoca con il quale revocarla, avendo un data
	di scadenza sulla chiave principale ci si assicura che alla
	fine essa cadr&agrave; comunque in disuso.
      </P
><P
>	Cambiare le sotto-chiavi di cifratura &egrave; semplice ma pu&ograve;
	risultare sconveniente.  Se si genera una nuova coppia di
	chiavi con una data di scadenza per la sotto-chiave, alla fine
	tale chiave scadr&agrave;.  Appena prima della scadenza si aggiunger&agrave;
	allora una nuova sottochiave e si render&agrave; nota la propria
	chiave pubblica aggiornata.  Chi desidera corrispondere con
	voi dovr&agrave;, una volta che la sotto-chiave &egrave; scaduta, recuperare
	la chiave aggiornata in quanto non sar&agrave; pi&ugrave; in grado di
	cifrare con la chiave scaduta.  Ci&ograve; pu&ograve; essere sconveniente a
	seconda di come si distribuisce la chiave.  Fortunatamente,
	per&ograve;, non saranno necessarie altre firme in quanto la nuova
	sotto-chiave sar&agrave; stata firmata mediante la vostra chiave di
	firma principale, la quale, verosimilmente, &egrave; gi&agrave; stata
	convalidata dai vostri corrispondenti.
      </P
><P
>	Questa sconvenienza pu&ograve; o meno valere la sicurezza aggiunta.
	Proprio come &egrave; possibile fare di persona, un malintenzionato
	pu&ograve; tuttavia leggere tutti i documenti criptati con la
	sotto-chiave scaduta [se riuscisse ad entrarne in possesso,
	<I
CLASS="EMPHASIS"
>ndt</I
>].  Cambiare le sotto-chiavi protegge
	solo i documenti futuri.  Per leggere i documenti cifrati con
	la nuova sotto-chiave, un malintenzionato avrebbe bisogno di
	cominciare un nuovo attacco utilizzando una qualsiasi delle
	tecniche adottate la prima volta nei vostri confronti.
      </P
><P
>	Per concludere, ha senso avere solo una sotto-chiave di
	cifratura valida in un mazzo.  Non c'&egrave; nessun guadagno in
	termini di sicurezza nell'avere due o pi&ugrave; sotto-chiavi attive.
	Pu&ograve; certamente esserci un numero qualsiasi di chiavi scadute
	in un mazzo, in modo tale che documenti cifrati in passato
	possano ancora essere decifrati, ma &egrave; sufficiente che solo una
	sotto-chiave sia attiva in un dato momento.
      </P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN566"
>Gestire la propria rete della fiducia</A
></H2
><P
>	Cos&igrave; come per la protezione della propria chiave, anche la
	gestione della propria rete della fiducia rappresenta un altro
	aspetto dell'uso di GnuPG che richiede la ponderazione di
	sicurezza a sfavore della semplicit&agrave; di utilizzo.  Se si sta
	utilizzando GnuPG per proteggersi contro spioni e falsari
	casuali, allora ci si pu&ograve; permettere di avere relativamente
	una buona fiducia delle firme di altre persone.  Viceversa, se
	si &egrave; preoccupati che possa esserci un malintenzionato ben
	determinato nel voler invadere la propria privacy, allora si
	dovrebbe avere molta meno fiducia nelle firme altrui e si
	dovrebbe spendere molto pi&ugrave; tempo nella verificarle personale.
      </P
><P
>	Qualsiasi siano i propri requisiti di sicurezza, per&ograve;, si
	dovrebbe <I
CLASS="EMPHASIS"
>sempre prestare attenzione</I
>
	quando si firmano le chiavi degli altri.  &Egrave; egoistico firmare
	una chiave possedendo la sola confidenza nella validit&agrave; della
	chiave sufficiente a soddisfare i propri requisiti di
	sicurezza.  Altre persone, con richieste di sicurezza pi&ugrave;
	stringenti, potrebbero voler dipendere dalla propria firma.
	Se non possono dipendere da voi, ci&ograve; indebolisce la rete della
	fiducia e rende pi&ugrave; difficoltosa la comunicazione per gli
	utenti di GnuPG.  Si utilizzi la stessa cura nel firmare
	chiavi che si vorrebbero altri usassero quando si dipende
	dalle loro firme.
      </P
><P
>	In pratica gestire la propria rete della fiducia si riduce a
	concedere fiducia agli altri e nell'aggiustare le opzioni
	<CODE
CLASS="OPTION"
>--marginals-needed</CODE
>
	e <CODE
CLASS="OPTION"
>--completes-needed</CODE
>.
	Qualsiasi chiave si firmi personalmente verr&agrave; considerata
	valida, ma, tranne che per piccoli gruppi, non sarebbe pratico
	firmare di persona la chiave di ogni corrispondente con i
	quali si desideri comunicare.  Si dovr&agrave; pertanto concedere
	della fiducia agli altri.
      </P
><P
>	Risulta probabilmente saggio essere precisi nel concedere la
	propria fiducia e quindi usare le opzioni per regolare
	l'attenzione che GnuPG debba porre nella convalida delle
	chiavi.  Come esempio concreto ci si potrebbe fidare
	totalmente solo di alcuni stretti amici, che si sa essere
	attenti nella firma delle chiavi, e fidarsi solo marginalmente
	di tutti gli altri presenti nel proprio mazzo di chiavi.  Di
	coseguenza si potrebbe impostare
	<CODE
CLASS="OPTION"
>--completes-needed</CODE
> a <TT
CLASS="LITERAL"
>1</TT
> e
	<CODE
CLASS="OPTION"
>--marginals-needed</CODE
> a <TT
CLASS="LITERAL"
>2</TT
>.
	Se si &egrave; pi&ugrave; preoccupati per la sicurezza, si potrebbero
	scegliere dei valori pari a <TT
CLASS="LITERAL"
>1</TT
> e
	<TT
CLASS="LITERAL"
>3</TT
> o <TT
CLASS="LITERAL"
>2</TT
> e
	<TT
CLASS="LITERAL"
>3</TT
> rispettivamente.  Se invece si &egrave; meno
	preoccupati di eventuali attacchi alla propria privacy e si
	desidera solo un po' di ragionevole confidenza circa la
	validit&agrave; delle chiavi, si possono impostare i valori
	<TT
CLASS="LITERAL"
>1</TT
> e <TT
CLASS="LITERAL"
>1</TT
>.  In generale, se
	i valori per queste opzioni sono grandi, ci&ograve; implica che un
	numero maggiore di persone dovranno cospirare contro di voi
	per veder convalidare una chiave che non appartiene
	effettivamente alla persona alla quale si pensa appartenga.
      </P
></DIV
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="x499.htm"
ACCESSKEY="P"
>Indietro</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="book1.htm"
ACCESSKEY="H"
>Partenza</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="x585.htm"
ACCESSKEY="N"
>Avanti</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Distribuire le chiavi</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Costruire la propria rete della fiducia</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
gnupg-doc 2003.04.06+dak1-1ubuntu1 / usr / share / doc / gnupg-doc / GNU_Privacy_Handbook / it / html / c520.htm
