Chiavi simmetriche e chiavi pubbliche: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
 
(16 versioni intermedie di 8 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili}}
==Installazione Pacchetti==
==Installazione Pacchetti==


Riga 7: Riga 8:
</pre>
</pre>


Come tutti saprete, per esser sicuri che i dati passanti per la rete siano lontani da sguardi indiscreti, e' necessario avvalersi della crittografia. Esistono fondamentalmente due tipi di crittografia: a chiavi simmetriche e a chiavi asimmetriche (o chiavi pubbliche).
Come tutti saprete, per esser sicuri che i dati passanti per la rete siano lontani da sguardi indiscreti, è necessario avvalersi della crittografia. Esistono fondamentalmente due tipi di crittografia: a chiavi simmetriche e a chiavi asimmetriche (o chiavi pubbliche).


==Chiavi simmetriche==
{{Box|Nota|La crittografia dei dati non ha nulla a che vedere ne con l'anonimizzazione degli stessi ne con le procedure necessarie a garantire l'identità di chi trasmette/riceve i suddetti dati.}}
La caratteristica fondamentale � l'esistenza di un'unica chiave utilizzata per codificare il testo in chiaro e per decodificare quello cifrato. C'� inoltre da dire che gli algoritmi simmetrici sono pi� veloci di quelli a chiave pubblica. Vediamo in pratica ora come si pu� crittografare un testo con blowfish.
 
== Chiavi simmetriche ==
 
=== Introduzione ===
 
La caratteristica fondamentale è l'esistenza di un'unica chiave utilizzata per codificare il testo in chiaro e per decodificare quello cifrato. Questo punto è fondamentale perché implica la necessità di fornire in maniera riservata e sicura la suddetta chiave a tutte le persone che intendono scambiarsi dati, il che può non essere un'operazione banale (inviare per esempio la suddetta chiave di cifratura attraverso un canale non sicuro come la normale mail non sarebbe ad esempio molto furbo). Oltre a ciò è opportuno notare che gli algoritmi simmetrici sono più veloci di quelli a chiave pubblica (asimmetrici).
 
=== Utilizzo ===
 
Vediamo in pratica ora come si può crittografare un testo con blowfish.


<pre>
<pre>
Riga 19: Riga 29:
OpenSSL> exit
OpenSSL> exit
</pre>
</pre>


Verifichiamo che sia realmente crittografato:
Verifichiamo che sia realmente crittografato:
Riga 25: Riga 34:
<pre>
<pre>
davide@portatile:~$ vi testoCifrato.txt
davide@portatile:~$ vi testoCifrato.txt
Salted__��X??��m�����>EEX?���&��iu?��j�1��??D�_�3
Salted__üÉX��øƒmºïÏć«´â>EEX�À¹®&¨Ùiu�÷éÁÀj¦1òŠí�?D¸_ã3
</pre>
</pre>


Riga 37: Riga 46:
</pre>
</pre>


E si pu� verificare che � tornato allo stato originale.
E si può verificare che è tornato allo stato originale.
 
== Chiavi asimmetriche ==


==Chiavi asimmetriche==
=== Introduzione ===
In questo caso la chiave usata per cifrare e decifrare non e' la stessa. Infatti una e' utilizzata solo per cifrare(la chiave pubblica) e l'altra solo per decifrare(la chiave privata). Di conseguenza le due chiavi devono essere fortemente connesse tra di loro.
 
La chiave pubblica, come dice il nome, deve esser resa pubblica a tutte le persone che vogliono parlare con me in maniera sicura. Ad esempio io posso pubblicarla sul mio sito oppure spedirla via mail. La chiave privata � solamente mia e non va assolutamente trasmessa via mail.
In questo caso la chiave usata per cifrare e decifrare non è la stessa. Infatti una è utilizzata solo per cifrare (la chiave pubblica) e l'altra solo per decifrare (la chiave privata). La chiave pubblica, come dice il nome, deve esser resa pubblica a tutte le persone che vogliono parlare con me in maniera sicura. Ad esempio io posso pubblicarla sul mio sito oppure spedirla via mail. La chiave privata è solamente mia e non va assolutamente trasmessa via mail.
 
Il punto focale di questo metodo è quello di eliminare la necessità di scambiarsi una chiave segreta, quindi di eliminare tutti i problemi connessi a quel tipo di operazione. Prima di passare all'utilizzo pratico è necessario avere le idee chiare su qualche aspetto teorico:
 
# Come già detto una sola chiave deve essere usata per criptare i dati ed una sola per decifrarli, tuttavia questo non significa che sia realmente impossibile usare la chiave dedicata alla decrittazione per criptare i dati, ma semplicemente che un messaggio può essere decriptato solo se si usano le chiavi "nel giusto ordine". Posto ad esempio che key1 sia la chiave per criptare e key2 quella per decriptare, usando key2 su un messaggio criptato con key1 si ottiene il messaggio di partenza, mentre usando key1 o key2 su un messaggio criptato attraverso key2 sarebbe impossibile ricostruire il messaggio di partenza. Ovviamente è anche impossibile usare key1 per decifarare un messaggio criptato con key1.
# I dati che si vuole inviare in modo sicuro devono essere criptati con la chiave "criptatrice" (pubblica) del ricevente e non con quella dello spedente, ecco perché la chiave per criptare deve necessariamente essere pubblica (o almeno nota alle persone dalle quali ci si aspetta di ricevere dati criptati). Questo fatto implica anche che chi spedisce non è più in grado di leggere i (suoi) dati una volta criptati con la chiave pubblica del ricevente. Chiaramente se chi spedisce è interessato a poter accedere a tali dati deve averne una copia, in chiaro oppure criptata con un sistema di cui possieda la chiave di decrittazione.
# Sebbene la chiave di decrittazione sia sconosciuta a tutti (si spera...) eccetto che al legittimo possessore, questo non significa che sia teoricamente impossibile ricostruirla autonomamente partendo dalla chiave pubblica. Chiave pubblica e privata condividono necessariamente un legame matematico, per quanto nascosto (altrimenti sarebbe impossibile decifrare a chiunque i dati di partenza), tuttavia il tempo necessario a ricostruire autonomamente tale legame, e quindi la chiave di decrittazione, è talmente elevato da rendere la suddetta operazione concretamente impossibile. Si noti che col passare degli anni si rende necessario l'uso di chiavi più lunghe a parità di sistema di criptazione usato, infatti l'aumento delle capacità di calcolo degli elaboratori comporta che a parità di lunghezza di una chiave il tempo necessario per ricostruirla si riduce.
 
=== Utilizzo ===


Vediamo ora sul lato pratico come si procede.
Vediamo ora sul lato pratico come si procede.
Riga 65: Riga 84:
<pre>
<pre>
Cosa scegli? 1
Cosa scegli? 1
La coppia DSA avr� 1024 bit.
La coppia DSA avrà 1024 bit.
Sto per generare una nuova coppia di chiavi ELG-E.
Sto per generare una nuova coppia di chiavi ELG-E.
               la dimensione minima � 768 bit
               la dimensione minima è 768 bit
           la dimensione predefinita � 1024 bit
           la dimensione predefinita è 1024 bit
   la dimensione massima consigliata � 2048 bit
   la dimensione massima consigliata è 2048 bit
Di che dimensioni vuoi la chiave? (1024)
Di che dimensioni vuoi la chiave? (1024)
</pre>
</pre>


Qui scegliamo la dimensione massima...
Qui scegliamo la dimensione massima.


Quindi decidiamo la validit� della chiave...
Quindi decidiamo la validità della chiave.


Poi si segue la procedura che fa' inserire alcuni dati e alla fine vengono create le due chiavi.
Poi si segue la procedura che fa inserire alcuni dati e alla fine vengono create le due chiavi.


{{Box|Nota|La passphrase che viene richiesta e' consigliabile sceglierla particolarmente lunga e complicata.}}
{{Box|Nota|La passphrase che viene richiesta è consigliabile sceglierla particolarmente lunga e complicata.}}


Per vedere le chiavi nel nostro portachiavi si utilizza il comando:
Per vedere le chiavi nel nostro portachiavi si utilizza il comando:
Riga 91: Riga 110:
</pre>
</pre>


Se voglio esportare la mia chiave pubblica posso procedere cos�:
Se voglio esportare la mia chiave pubblica posso procedere così:


<pre>
<pre>
Riga 122: Riga 141:
</pre>
</pre>


Cos� io posso prendere il testo e salvarlo.
Così io posso prendere il testo e salvarlo.


Quando voglio importare una chiave pubblica:
Quando voglio importare una chiave pubblica:
Riga 136: Riga 155:
</pre>
</pre>


Dove Prova e' il commento per la chiave pubblica del nostro destinatario. (Vedi sopra).
Dove <code>Prova</code> è il commento per la chiave pubblica del nostro destinatario. (Vedi sopra).


Bene. Proviamo a decifrarla con la chiave privata, fingendoci il destinatario.
Bene. Proviamo a decifrarla con la chiave privata, fingendoci il destinatario.
Riga 152: Riga 171:


Bene, visto che funziona, facciamo un passo avanti. Con la nostra
Bene, visto che funziona, facciamo un passo avanti. Con la nostra
chiave privata si pu� inoltre "firmare".Cos� sono sicuro
chiave privata si può inoltre "firmare". Così sono sicuro
della provenienza dell'e-mail. Spesso le due tecniche vengono combinate:
della provenienza dell'e-mail. Spesso le due tecniche vengono combinate:
prima la mail viene cifrata con la chiave pubblica del destinatario, poi
prima la mail viene cifrata con la chiave pubblica del destinatario, poi
Riga 158: Riga 177:
provenienza della mail al destinatario. Infatti le mail che hanno
provenienza della mail al destinatario. Infatti le mail che hanno
la firma digitale non possono essere ripudiate, ovvero il mittente non
la firma digitale non possono essere ripudiate, ovvero il mittente non
potr� negare di aver mandato suddetta mail.
potrà negare di aver mandato suddetta mail.




Riga 167: Riga 186:
''di gad--''
''di gad--''


Non capisco propio perch� hai usato openssl per la cifratura a chiavi simmetriche � gpg per quella con chiavi asimmetriche. Per precisione � meglio dire che anche con openssl puoi criptare con la chiave pubblica. Ti riporto un esempio:
Non capisco proprio perché hai usato openssl per la cifratura a chiavi simmetriche e gpg per quella con chiavi asimmetriche. Per precisione è meglio dire che anche con openssl puoi criptare con la chiave pubblica. Ti riporto un esempio:


<pre>
<pre>
#generi la chiave privata di lunghezza 1024 con l'algoritmo di cifratura des3
# generi la chiave privata di lunghezza 1024 con l'algoritmo di cifratura des3


openssl genrsa -out rsaprivatekey.pem -des3 1024
openssl genrsa -out rsaprivatekey.pem -des3 1024


#crei la chiave pubblica
# crei la chiave pubblica


openssl rsa -in rsaprivatekey.pem -pubout -out rsapublickey.pem
openssl rsa -in rsaprivatekey.pem -pubout -out rsapublickey.pem


#a questo punto hai la coppia di chiavi. Usi la chiave pubblica x criptare il testo
# a questo punto hai la coppia di chiavi. Usi la chiave pubblica x criptare il testo


openssl rsautl -encrypt -pubin -inkey rsapublickey.pem -in testodacifrare.txt -out testocifrato.txt
openssl rsautl -encrypt -pubin -inkey rsapublickey.pem -in testodacifrare.txt -out testocifrato.txt


#lo riporti in chiaro applicando la chiave privata
# lo riporti in chiaro applicando la chiave privata


openssl rsautl -decrypt -inkey rsaprivatekey.pem -in testocifrato.txt -out testoinchiaro.txt
openssl rsautl -decrypt -inkey rsaprivatekey.pem -in testocifrato.txt -out testoinchiaro.txt
Riga 190: Riga 209:
'''''Osservazione sul commento di gad:'''''
'''''Osservazione sul commento di gad:'''''


Sembra che con RSA si possa cifrare una quantit� di dati molto limitata (dipende dalla lunghezza della chiave, comunque si parla di 117 byte per chiavi di 1024 bit) quindi nella maggior parte dei casi pratici l'esempio sopra non pu� essere applicabile direttamente.
Sembra che con RSA puro si possa cifrare una quantità di dati molto limitata (dipende dalla lunghezza della chiave, comunque si parla di 117 byte per chiavi di 1024 bit) quindi nella maggior parte dei casi pratici l'esempio sopra non può essere applicabile direttamente.
Solitamente infatti si usa RSA per cifrare una chiave casuale che viene usata per cifrare il file con un algorimo simmetrico. Sembra che non sia possibile fare questo in modo banale con openssl (occorre fare diversi passaggi e distribuire le informazioni in file separati, per un esempio vedere [http://www.dmst.aueb.gr/dds/secimp/crypto/indexw.htm] al paragrafo "Case Study: Public Key Cryptography") a meno di non utilizzare la codifica S/MIME di cui parli sotto.
Solitamente infatti si usa RSA per cifrare una chiave casuale che viene usata per cifrare il file con un algoritmo simmetrico. Sembra che non sia possibile fare questo in modo banale con openssl (occorre fare diversi passaggi e distribuire le informazioni in file separati, per un esempio vedere http://www.dmst.aueb.gr/dds/secimp/crypto/indexw.htm al paragrafo "Case Study: Public Key Cryptography") a meno di non utilizzare la codifica S/MIME di cui parli sotto.


Scusate se il commento non � inserito nel modo pi� ortodosso ma passavo di qui per caso.
Scusate se il commento non è inserito nel modo più ortodosso ma passavo di qui per caso.


'''''Fine dell'osservazione sul commento di gad:'''''
'''''Fine dell'osservazione sul commento di gad:'''''


Sono d'accordo con te quando dici che pgp � il pi� usato, perch� supportato da quasi tutti i client email. Comunque anche openssl comprende un protocollo specifico per criptare le email. Il protocollo S/MIME � Secure Multipurpose Internet Mail Extensions. Dunque i due software sono funzionalmente equivalenti, tranne per un aspetto rilevante: il modello di fiducia.
Sono d'accordo con te quando dici che pgp è il più usato, perché supportato da quasi tutti i client email. Comunque anche openssl comprende un protocollo specifico per criptare le email. Il protocollo S/MIME – Secure Multipurpose Internet Mail Extensions. Dunque i due software sono funzionalmente equivalenti, tranne per un aspetto rilevante: il modello di fiducia.


La differenza fondamentale tra i due sistemi � che mentre PGP utilizza una gestione "utente-centrica" delle chiavi pubbliche (il cosiddetto web of trust), S/MIME impiega una struttura gerarchica di certificazione (le Certification Authorities o CA).
La differenza fondamentale tra i due sistemi è che mentre PGP utilizza una gestione "utente-centrica" delle chiavi pubbliche (il cosiddetto web of trust), S/MIME impiega una struttura gerarchica di certificazione (le Certification Authorities o CA).


S/MIME ha un modello di fiducia gerarchico, in cui "autorit� di certificazione" certificano l'identit� degli utenti (e questa � la struttura adottata anche dalla legislazione italiana), PGP adotta un sistema a rete, in cui gli utenti si certificano a vicenda: ogni utente mantiene la lista di chiavi pubbliche dei suoi corrispondenti (viene chiamata keyring), ognuna delle quali viene firmata con la propria chiave privata.
S/MIME ha un modello di fiducia gerarchico, in cui "autorità di certificazione" certificano l'identità degli utenti (e questa è la struttura adottata anche dalla legislazione italiana), PGP adotta un sistema a rete, in cui gli utenti si certificano a vicenda: ogni utente mantiene la lista di chiavi pubbliche dei suoi corrispondenti (viene chiamata keyring), ognuna delle quali viene firmata con la propria chiave privata.


� possibile scambiarsi i keyring: alle chiavi importate (e quindi firmate dal proprietario) � possibile assegnare diverse gradazioni di "fiducia" che permettono di costruire il cosiddetto web of trust (l'equivalente della struttura gerarchica dei certificati). ... bla, bla , bla
È possibile scambiarsi i keyring: alle chiavi importate (e quindi firmate dal proprietario) è possibile assegnare diverse gradazioni di "fiducia" che permettono di costruire il cosiddetto web of trust (l'equivalente della struttura gerarchica dei certificati). ... bla, bla , bla


Vi riporto anche un esempio di utilizzo:
Vi riporto anche un esempio di utilizzo:


<pre>
<pre>
#cripti l'email con la chiave publica estrata dal certificato
# cripti l'email con la chiave pubblica estratta dal certificato
openssl smime -encrypt -in mail.txt -des3 -out mail.enc cert.pem
openssl smime -encrypt -in mail.txt -des3 -out mail.enc cert.pem
#decripta l'email usando la chiave privata
# decripta l'email usando la chiave privata
openssl smime -decrypt -in mail.enc -recip cert.pem -inkey privatekey.pem -out mail .txt
openssl smime -decrypt -in mail.enc -recip cert.pem -inkey privatekey.pem -out mail .txt
#etc...
# etc...
</pre>
</pre>


P.S.: Spero che con questo contribuito ho aggiunto qualcosa in + al articolo che cmq � ottimo.
P.S.: Spero, con questo contribuito, di aver aggiunto qualcosa in più all'articolo.
 
== Link ==
 
* [http://www.gnupg.org/gph/it/concetti.html Manuale GNU sulla privacy: Concetti] - Per approfondire i concetti di algoritmi simmetrici, asimmetrici o ibridi.
 
{{Autori
|Autore = [[Utente:TheNoise|TheNoise]]
}}
 
[[Categoria:Crittografia]]

Versione attuale delle 14:57, 6 gen 2014

Debian-swirl.png Versioni Compatibili

Tutte le versioni supportate di Debian

Installazione Pacchetti

Prima di iniziare a parlare di crittografia e chiavi, installiamo l'occorrente con un semplice: 

# apt-get install gnupg openssl

Come tutti saprete, per esser sicuri che i dati passanti per la rete siano lontani da sguardi indiscreti, è necessario avvalersi della crittografia. Esistono fondamentalmente due tipi di crittografia: a chiavi simmetriche e a chiavi asimmetriche (o chiavi pubbliche).

Info.png Nota
La crittografia dei dati non ha nulla a che vedere ne con l'anonimizzazione degli stessi ne con le procedure necessarie a garantire l'identità di chi trasmette/riceve i suddetti dati.


Chiavi simmetriche

Introduzione

La caratteristica fondamentale è l'esistenza di un'unica chiave utilizzata per codificare il testo in chiaro e per decodificare quello cifrato. Questo punto è fondamentale perché implica la necessità di fornire in maniera riservata e sicura la suddetta chiave a tutte le persone che intendono scambiarsi dati, il che può non essere un'operazione banale (inviare per esempio la suddetta chiave di cifratura attraverso un canale non sicuro come la normale mail non sarebbe ad esempio molto furbo). Oltre a ciò è opportuno notare che gli algoritmi simmetrici sono più veloci di quelli a chiave pubblica (asimmetrici).

Utilizzo

Vediamo in pratica ora come si può crittografare un testo con blowfish. 

davide@portatile:~$ openssl
OpenSSL> bf -in testoInChiaro.txt -out testoCifrato.txt
enter bf-cbc encryption password:
Verifying - enter bf-cbc encryption password:
OpenSSL> exit

Verifichiamo che sia realmente crittografato: 

davide@portatile:~$ vi testoCifrato.txt
Salted__üÉX��øƒmºïÏć«´â>EEX�À¹®&¨Ùiu�÷éÁÀj¦1òŠí�?D¸_ã3

Bene. Ora proviamo a riportarlo in chiaro: 

davide@portatile:~$ openssl
OpenSSL> bf -d -in testoCifrato.txt -out testoDiNuovoInChiaro.txt
enter bf-cbc decryption password:
OpenSSL> exit

E si può verificare che è tornato allo stato originale.

Chiavi asimmetriche

Introduzione

In questo caso la chiave usata per cifrare e decifrare non è la stessa. Infatti una è utilizzata solo per cifrare (la chiave pubblica) e l'altra solo per decifrare (la chiave privata). La chiave pubblica, come dice il nome, deve esser resa pubblica a tutte le persone che vogliono parlare con me in maniera sicura. Ad esempio io posso pubblicarla sul mio sito oppure spedirla via mail. La chiave privata è solamente mia e non va assolutamente trasmessa via mail.

Il punto focale di questo metodo è quello di eliminare la necessità di scambiarsi una chiave segreta, quindi di eliminare tutti i problemi connessi a quel tipo di operazione. Prima di passare all'utilizzo pratico è necessario avere le idee chiare su qualche aspetto teorico:

  1. Come già detto una sola chiave deve essere usata per criptare i dati ed una sola per decifrarli, tuttavia questo non significa che sia realmente impossibile usare la chiave dedicata alla decrittazione per criptare i dati, ma semplicemente che un messaggio può essere decriptato solo se si usano le chiavi "nel giusto ordine". Posto ad esempio che key1 sia la chiave per criptare e key2 quella per decriptare, usando key2 su un messaggio criptato con key1 si ottiene il messaggio di partenza, mentre usando key1 o key2 su un messaggio criptato attraverso key2 sarebbe impossibile ricostruire il messaggio di partenza. Ovviamente è anche impossibile usare key1 per decifarare un messaggio criptato con key1.
  2. I dati che si vuole inviare in modo sicuro devono essere criptati con la chiave "criptatrice" (pubblica) del ricevente e non con quella dello spedente, ecco perché la chiave per criptare deve necessariamente essere pubblica (o almeno nota alle persone dalle quali ci si aspetta di ricevere dati criptati). Questo fatto implica anche che chi spedisce non è più in grado di leggere i (suoi) dati una volta criptati con la chiave pubblica del ricevente. Chiaramente se chi spedisce è interessato a poter accedere a tali dati deve averne una copia, in chiaro oppure criptata con un sistema di cui possieda la chiave di decrittazione.
  3. Sebbene la chiave di decrittazione sia sconosciuta a tutti (si spera...) eccetto che al legittimo possessore, questo non significa che sia teoricamente impossibile ricostruirla autonomamente partendo dalla chiave pubblica. Chiave pubblica e privata condividono necessariamente un legame matematico, per quanto nascosto (altrimenti sarebbe impossibile decifrare a chiunque i dati di partenza), tuttavia il tempo necessario a ricostruire autonomamente tale legame, e quindi la chiave di decrittazione, è talmente elevato da rendere la suddetta operazione concretamente impossibile. Si noti che col passare degli anni si rende necessario l'uso di chiavi più lunghe a parità di sistema di criptazione usato, infatti l'aumento delle capacità di calcolo degli elaboratori comporta che a parità di lunghezza di una chiave il tempo necessario per ricostruirla si riduce.

Utilizzo

Vediamo ora sul lato pratico come si procede.

Per generare una chiave usiamo gpg: 

davide@portatile:~$ gpg --gen-key
gpg (GnuPG) 1.2.4; Copyright (C) 2003 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Per favore scegli che tipo di chiave vuoi:
   (1) DSA e ElGamal (default)
   (2) DSA (firma solo)
   (4) RSA (firma solo)
Cosa scegli?

Scegliamo la prima opzione, in quanto le altre due consentono solamente di firmare. 

Cosa scegli? 1
La coppia DSA avrà 1024 bit.
Sto per generare una nuova coppia di chiavi ELG-E.
               la dimensione minima è  768 bit
          la dimensione predefinita è 1024 bit
  la dimensione massima consigliata è 2048 bit
Di che dimensioni vuoi la chiave? (1024)

Qui scegliamo la dimensione massima.

Quindi decidiamo la validità della chiave.

Poi si segue la procedura che fa inserire alcuni dati e alla fine vengono create le due chiavi.

Info.png Nota
La passphrase che viene richiesta è consigliabile sceglierla particolarmente lunga e complicata.


Per vedere le chiavi nel nostro portachiavi si utilizza il comando: 

davide@portatile:~$ gpg --list-keys
/home/davide/.gnupg/pubring.gpg
-------------------------------
pub  1024D/84050639 2005-01-18 Paolo Rossi (Prova) <paolo.rossi@libero.it>
sub  1024g/C02A6DF1 2005-01-18

Se voglio esportare la mia chiave pubblica posso procedere così: 

davide@portatile:~$ gpg --armor --export Paolo Rossi  
(l'opzione --armor mi indica che voglio esportare la chiave in formato ASCII)
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.4 (GNU/Linux)

mQGiBEHs9lYRBADL2Pke4aVfdx62B25cRvV8A78V6lw6kS50kx2eeFiKdjRmfpr1
c7pZJEjUCYtiWkKCZnOiEJfnN3YPCEAugNJyD/VSS1Jw9Chlhtga43q1BI3AgoIi
1yNQQ0q67kA6i2KEgoou9h4xPae3OVFWDfp2C+qivJ4W2psWEv+CP0GRvwCgtTMm
OUHvCR8k6mznh4iK/WAlDTcEAI4m3TWNAsmY4iXA8gtFh4S1Zmg2h7w+e2HzbXjQ
91ZdzjxN27dN/2q6t42/YQSBPlNmtQgSOY4OcK+BPg8ugzveAC6rBm1ZDgxmhq1b
NVWn4gOxlq2gl0l/xQbTfyyMZ/V+KfpoN8kH/kzP3olrKxfqirH/9qrcQY3zgStM
ZL9QA/9Bys3TwZD2FnIIdjlHTDQs40KEzc/4i4Ks9VBTZrUgHnnZOyHK+DvH9QTZ
8WXaJNgXEB/uU8weNoZX94ncqdW3d5DfyP5999Z5sXUlm4lRwWKKijMgIp6gOf8O
MwVtAEBBjd7sAFmpsZZ2bktL1799FmixHeZtxGuw3ul0dWf6CLYAAAArUGFvbG8g
Um9zc2kgKFByb3ZhKSA8cGFvbG8ucm9zc2lAbGliZXJvLml0PoheBBMRAgAeBQJB
7PZWAhsDBgsJCAcDAgMVAgMDFgIBAh4BAheAAAoJEIMe3VSEBQY5NMYAmwU+KCnA
f/rlTbddLQpZTigt5PXEAJ0eIaBK0h9HdkuHConBDz5edDXwwrkBDQRB7PZYEAQA
qQKvxUlAPVpXdwkFCnEmD0/xveEi0Edwgi5vKqlL17HgpSZDgQel7y1GnDd2ENLs
OleKXFJ/02k/+fnUAcn2jMzjWo8jgchW+AUc1hL8xhoQV/LFBiXJQUBRg3BwT1Y3
z1I8xP31tRWbt3CPa9Yi5k3T8I0N/Kfvg1CAPAAgGrcABAsD/3N5RszeKjvCsHzg
yfrcjF2ZndHEvkHYNEpGLCglXT9+N84KO6+OJpe8K9943PyxVgds2li4fjvwlA4k
L01dvKqJqndoDTcr/lAM6ML0LTM1YKTnk4LPNgQj1E1g6nVQ2rPLJ7yYzitfNiLT
Nn+5kIrtLcHYGOhd66sTddaeUqa9iEkEGBECAAkFAkHs9lgCGwwACgkQgx7dVIQF
BjkWLgCePHfhrb1j3zOhFyqb2bpePWD2Pc0An1lbk7jMMo4U1FGONcHm3pM2VDhB
=UFTN
-----END PGP PUBLIC KEY BLOCK-----

Così io posso prendere il testo e salvarlo.

Quando voglio importare una chiave pubblica: 

davide@portatile:~$ gpg --import chiaveMario.gp

Vediamo ora come si usa: 

davide@portatile:~$ gpg --encrypt --output testoSegreto.txt --recipient Prova testoInChiaro.txt

Dove Prova è il commento per la chiave pubblica del nostro destinatario. (Vedi sopra).

Bene. Proviamo a decifrarla con la chiave privata, fingendoci il destinatario. 

davide@portatile:~$ gpg --decrypt --output decifrato.txt testoSegreto.txt

Ti serve una passphrase per sbloccare la chiave segreta
dell'utente: "Paolo Rossi (Prova) <paolo.rossi@libero.it>"
chiave ELG-E di 1024 bit, ID C02A6DF1, creata il 2005-01-18 (key ID principale 84050639)

gpg: cifrato con la chiave ELG-E di 1024 bit, ID C02A6DF1, creata il 2005-01-18
      "Paolo Rossi (Prova) <paolo.rossi@libero.it>"

Bene, visto che funziona, facciamo un passo avanti. Con la nostra chiave privata si può inoltre "firmare". Così sono sicuro della provenienza dell'e-mail. Spesso le due tecniche vengono combinate: prima la mail viene cifrata con la chiave pubblica del destinatario, poi con la mia chiave privata, dando la certezza praticamente assoluta della provenienza della mail al destinatario. Infatti le mail che hanno la firma digitale non possono essere ripudiate, ovvero il mittente non potrà negare di aver mandato suddetta mail.


-- Autore: darco

Commenti

di gad--

Non capisco proprio perché hai usato openssl per la cifratura a chiavi simmetriche e gpg per quella con chiavi asimmetriche. Per precisione è meglio dire che anche con openssl puoi criptare con la chiave pubblica. Ti riporto un esempio: 

# generi la chiave privata di lunghezza 1024 con l'algoritmo di cifratura des3

openssl genrsa -out rsaprivatekey.pem -des3 1024

# crei la chiave pubblica

openssl rsa -in rsaprivatekey.pem -pubout -out rsapublickey.pem

# a questo punto hai la coppia di chiavi. Usi la chiave pubblica x criptare il testo

openssl rsautl -encrypt -pubin -inkey rsapublickey.pem -in testodacifrare.txt -out testocifrato.txt

# lo riporti in chiaro applicando la chiave privata

openssl rsautl -decrypt -inkey rsaprivatekey.pem -in testocifrato.txt -out testoinchiaro.txt


Osservazione sul commento di gad:

Sembra che con RSA puro si possa cifrare una quantità di dati molto limitata (dipende dalla lunghezza della chiave, comunque si parla di 117 byte per chiavi di 1024 bit) quindi nella maggior parte dei casi pratici l'esempio sopra non può essere applicabile direttamente. Solitamente infatti si usa RSA per cifrare una chiave casuale che viene usata per cifrare il file con un algoritmo simmetrico. Sembra che non sia possibile fare questo in modo banale con openssl (occorre fare diversi passaggi e distribuire le informazioni in file separati, per un esempio vedere http://www.dmst.aueb.gr/dds/secimp/crypto/indexw.htm al paragrafo "Case Study: Public Key Cryptography") a meno di non utilizzare la codifica S/MIME di cui parli sotto.

Scusate se il commento non è inserito nel modo più ortodosso ma passavo di qui per caso.

Fine dell'osservazione sul commento di gad:

Sono d'accordo con te quando dici che pgp è il più usato, perché supportato da quasi tutti i client email. Comunque anche openssl comprende un protocollo specifico per criptare le email. Il protocollo S/MIME – Secure Multipurpose Internet Mail Extensions. Dunque i due software sono funzionalmente equivalenti, tranne per un aspetto rilevante: il modello di fiducia.

La differenza fondamentale tra i due sistemi è che mentre PGP utilizza una gestione "utente-centrica" delle chiavi pubbliche (il cosiddetto web of trust), S/MIME impiega una struttura gerarchica di certificazione (le Certification Authorities o CA).

S/MIME ha un modello di fiducia gerarchico, in cui "autorità di certificazione" certificano l'identità degli utenti (e questa è la struttura adottata anche dalla legislazione italiana), PGP adotta un sistema a rete, in cui gli utenti si certificano a vicenda: ogni utente mantiene la lista di chiavi pubbliche dei suoi corrispondenti (viene chiamata keyring), ognuna delle quali viene firmata con la propria chiave privata.

È possibile scambiarsi i keyring: alle chiavi importate (e quindi firmate dal proprietario) è possibile assegnare diverse gradazioni di "fiducia" che permettono di costruire il cosiddetto web of trust (l'equivalente della struttura gerarchica dei certificati). ... bla, bla , bla

Vi riporto anche un esempio di utilizzo: 

# cripti l'email con la chiave pubblica estratta dal certificato
openssl smime -encrypt -in mail.txt -des3 -out mail.enc cert.pem
# decripta l'email usando la chiave privata
openssl smime -decrypt -in mail.enc -recip cert.pem -inkey privatekey.pem -out mail .txt
# etc...

P.S.: Spero, con questo contribuito, di aver aggiunto qualcosa in più all'articolo.

Link



Guida scritta da: TheNoise Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized

Estratto da "https://guide.debianizzati.org/index.php?title=Chiavi_simmetriche_e_chiavi_pubbliche&oldid=33725"