Crittografia files con openSUSE leap

Guida alla crittografia file per persone normali. 

I file che creiamo con i nostri computer sono tanto al sicuro da occhi indiscreti quanto i nostri computer sono gestiti oculatamente, tutti noi ci preoccupiamo di attacchi informatici, intrusioni in reti e computers, keyloggers e malware di varia natura, quando spesso non mettiamo in campo semplici accorgimenti che aiutano molto ad aumentare la sicurezza dei nostri dati. Aggiornamenti da sorgenti fidate, uso corretto dei permessi su macchine con più utenti, uso di password non banali rafforzano molto l’ambiente in cui creiamo e manipoliamo o dati.

Detto questo vi sono vari modi per tenere i nostri files al sicuro, uno di questi è l’uso della crittografia.

La crittografia trasforma il contenuto di un file in un apparente contenuto casuale e inintelleggibile, solo chi possiede la chiave adatta può accedere al contenuto. Questo approccio si può applicare a file, directories, partizioni o dischi interi.

In questa guida affronterò solamanete i file.

Siamo in ambiente linux (openSUSE) ed i programmi che utilizzeremo sono gnupg (gnu privacy guard) e gli strumenti offerti da Dolphin in integrazione con gnupg.

Dobbiamo doverosamente distinguere due casi, i nostri file per uso personale e quelli destinati ad altre persone, poichè si possono crittografare dei files utilizzando due sistemi:

* coppia di chiavi (pubblica/privata)

* passphrase – password

Se cifriamo i file sul nostro pc per uso “interno” usiamo la nostra chiave pubblica e per decrittare la nostra chiave privata.

Se dobbiamo inoltrare ad altri il file in oggetto e non conosciamo la sua chiave pubblica, oppure non ce l’ha dobbiamo ricorrere alla passphrase/password. (il difficile è trasmettere questa informazione in modo sicuro)

caso 1 – usiamo le nostre chiavi:

gpg –encrypt –recipient ‘chiave di cifratura’ file.pdf

verrà creato un file “file.pdf.gpg

per decifrare il file:

gpg –output files.tar.gz –decrypt files.tar.gz.gpg (verrà richiesta la passphrase che avete immesso creando la chiave)

Se non aveste ancora le vostre chiavi potete crearle così: <— indica dove va il vostro input

[email protected]:~> gpg –gen-key <—

gpg (GnuPG) 2.0.24; Copyright (C) 2013 Free Software Foundation, Inc.

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Per favore scegli che tipo di chiave vuoi:

(1) RSA and RSA (default)

(2) DSA and Elgamal

(3) DSA (firma solo)

(4) RSA (firma solo)

Cosa scegli? 1 <—–

RSA keys may be between 1024 and 4096 bits long.

What keysize do you want? (2048) <——-

La dimensione richiesta della chiave è 2048 bit

Per favore specifica per quanto tempo la chiave sarà valida.

0 = la chiave non scadrà

<n> = la chiave scadrà dopo n giorni

<n>w = la chiave scadrà dopo n settimane

<n>m = la chiave scadrà dopo n mesi

<n>y = la chiave scadrà dopo n anni

Chiave valida per? (0) <———-

Key does not expire at all

Is this correct? (y/N) y <——–

GnuPG needs to construct a user ID to identify your key.

Nome e Cognome: pippo pappo <——

Indirizzo di Email: [email protected] <——

Commento:

Hai selezionato questo User Id:

“pippo pappo <[email protected]>” <————

Modifica (N)ome, (C)ommento, (E)mail oppure (O)kay/(Q)uit? o <————-

Ti serve una passphrase per proteggere la tua chiave segreta. <– inserire passphrase, meglio lunga e complessa

 

Dobbiamo generare un mucchio di byte casuali. È una buona idea eseguire

qualche altra azione (scrivere sulla tastiera, muovere il mouse, usare i

dischi) durante la generazione dei numeri primi; questo da al generatore di

numeri casuali migliori possibilità di raccogliere abbastanza entropia.

gpg: key 11BC8313 marked as ultimately trusted

chiavi pubbliche e segrete create e firmate.

gpg: controllo il trustdb

gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model

gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u

gpg: il prossimo controllo del trustdb sarà fatto il 2022-11-27

pub 2048R/11BC8313 2017-11-29

Key fingerprint = 6001 9D36 A3C1 FE76 7861 4E9C 8938 A0E9 11BC 8313

uid [ultimate] pippo pappo <[email protected]>

sub 2048R/4D03D913 2017-11-29

E’ buona norma salvare le proprie chiavi:

gpg –armor –output file-enc-privkey.asc –export-secret-keys ‘chiave cifratura (pippo pappo nell’esempio sopra)’

Se invece vogliamo usare la cifratura solo con passphrase allora il comando per cifrare sarà:

gpg –symmetric –cipher-algo aes256 file.pdf

verrà richiesta la passphrase e creato il file file.pdf.gpg

per decifrarlo:

gpg –decrypt file.pdf.gpg > file.pdf

verrà chiesta la passphrase.

Questa è la guida da riga di comando che può essere usata sempre, comunque la nostra distro preferita, openSUSE ci viene in aiuto fornendo tramite il filemanager dolphin un comodo strumento “da mouse”, Kleopatra con cui gestire le chiavi ed effettuare le operazioni cifratura / verifica e decifratura. Se Kleopatra non fosse già installato lo si può fare comodamente da YaSt→ gestione pacchetti, oppure in un terminale :

sudo zypper in kleopatra

Una volta installato seguire il piccolo wizard di configurazione, veramente intuitivo che magari copriremo in un aggiornamento successivo di questa guida.

In dolphin, cliccando con il tasto destro del mouse sul file che intendiamo crittografare selezioniamo dal menu contestuale la voce “cifra file”.

Selezionaimo la chiave pubblica del destinatario oppure “cifra con password” se non abbiamo la chiave del destinatario o non la ha, ma in questo caso dovremmo trovare un modo sicuro di far avere al destinatario la passphrase per la decodifica.

Verrà chiesta la passphrase di cifratura (e la sua conferma), la nostra passphrase di kleopatra ed infine verrà visualizzata una finestra di conferma cifratura.

analogamente per decifrare un file sempre nel menù contestuale selezionare “decodifica/verifica” verrà verificata la firma e proposto se salvare o meno.

 

10 commenti su “Crittografia files con openSUSE leap

  • dicembre 5, 2017 at 11:26 am
    Permalink

    Citazione: “Se cifriamo i file sul nostro pc per uso “interno” usiamo la nostra chiave pubblica e per decrittare la nostra chiave privata”.
    Mi sfugge il fatto di dover usare la crittografia a doppia chiave per cifrare dati in locale che, a quanto scrivi, resteranno in locale.

    Ezio

  • dicembre 5, 2017 at 11:29 am
    Permalink

    Che poi è proprio il concetto di partenza sbagliato. GPG usa AES (o simile) per cifrare il contenuto del file, a SINGOLA chiave. La crittografia a DOPPIA chiave viene usata per trasmettere tra i due interlocutori la SINGOLA chiave di AES.

  • dicembre 5, 2017 at 11:41 am
    Permalink

    Citazione: “Selezionaimo la chiave pubblica del destinatario oppure “cifra con password” se non abbiamo la chiave del destinatario o non la ha, ma in questo caso dovremmo trovare un modo sicuro di far avere al destinatario la passphrase per la decodifica”.
    Abbiamo letto tutto un articolo per arrivare alla fine che si scopre che comunque la password la dobbiamo trasmettere in chiaro (o di persona o al telefono), quindi a che occorre imparare GPG (o PGP)??
    Sarebbe stato molto più educativo spiegare come cifrare file a chiave singola (con tutti i pro e contro) e poi utilizzare la chiave doppia per evitare i contro di cui sopra (e cmq ci sono e contro anche sulla doppia chiave).

    • Alexander Liveriero Lavelli
      dicembre 5, 2017 at 12:54 pm
      Permalink

      Ciao, qui non sono d’accordo, possiamo sempre iniziare a far girare la nostra chiave pubblica e a farci dare la chiave pubblica dei nostri interlocutori, nel tempo avremo una raccolta di persone con cui comunicare (o a cui spedire files) in modo sicuro.
      Ho indicato la procedura per sensibilizzare sul fatto che comunicare (o trasmettere) in modo sicuro include un impegno “bidirezionale” per farti avere un file cifrato in mopdo sicuro, devo cifrarlo con latua chiave pubblica, tu lo apri con la tua chiave privata…
      Certo, altrimenti non ha senso…

      😉

  • dicembre 5, 2017 at 12:13 pm
    Permalink

    Secondo me l’articolo è da rifare da capo a piedi… ho pure spiegato il perchè, almeno per quelle che sono le mie conoscenze (potrei anche essere in torto 😀 )

    • dicembre 5, 2017 at 12:34 pm
      Permalink

      Ogni consiglio è ben accetto, riferisciti direttamente all’autore dell’articolo 🙂

    • dicembre 5, 2017 at 12:40 pm
      Permalink

      Ezio Tonetto, ho visto, mi potresti scrivere, anche in privato, le parti che ritieni errate,come vedi ho tenuto un approccio volutamente non tecnico, ma sul mero utilizzo “desktop” non è un trattato di crittografia.

Lascia un commento

This site uses Akismet to reduce spam. Learn how your comment data is processed.