Newsgroup: it.comp.sicurezza.crittografia
Titolo: Info su chiavi e sottochiavi

 rinnovate di anno in anno e vengono utilizzate nell'uso quotidiano.
2. Se creo un file PGPdisk con le chiavi di cui sopra, una volta scadute
le sottochiavi, posso sempre aprire il file PGPdisk? E se elimino queste
sottochiavi scadute, posso ancora aprirlo?
3. Come si fa a usare la chiave primaria (di cui sopra) per la firma su
altre chiavi, visto che viene utilizzata la sottochiave? Avviene in
automatico oppure posso scegliere con quale delle due firmare?
4. Come si fa ad impostare un digest di tipo SHA256?
5. Quando si crea una chiave, gpg imposta il suo utilizzo che può essere
SCEA, cioè:
S=Sign
C=Certify
E=Encrypt
A=Authenticate
Sign ed Encrypt sono chiari. A cosa servono C ed A?
Per ora può bastare! :)
Grazie,
Aldo
-- 
Aldo Latino
www.aldolat.it
*** Erase X from my address to reply in my inbox ***

 Sign ed Encrypt sono chiari. A cosa servono C ed A?
Certify abilità la proprio chiave a firmare (e quindi certificare) altre
chiavi.
Authenticate è un flag che permette che la chiave venga usata per le
autenticazioni, ad esempio con ssh. Ci sono delle bozze per questo.
In prima approssimazione potrebbe sembrare che Sign e Encrypt possano essere
i soli flag di cui si ha bisogno, in realtà avere flag più specifici
permette di scegliere *quale* sottochiave usare per fare *cosa*.
Poi chiaramente una chiave con flag Certify, in realtà "certifica" firmando
un'altra chiave. ;-)
-- 
Saluti, Federico - 
http://www.quaqo.org
Le FAQ sulla crittografia: 
http://kb.quaqo.org/criptofaq/

 4. Come si fa ad impostare un digest di tipo SHA256?
A) Da riga di comando (da inserire quindi ogni volta):
1. Per la firma da apporre ad un file di testo in formato ASCII-armored
(cioè che avvolge il testo):
gpg --digest-algo SHA256 --clearsign testo.txt
2. Per la firma staccata (detached), cioè in un file a parte:
gpg --digest-algo SHA256 --output testo.txt.sig --detach-sign testo.txt
B) Da file di configurazione (gpg.conf) si può impostare una volta per
tutte quale algoritmo di hash usare.
Inserire alla fine del file gpg.conf questa riga:
digest-algo SHA256
Stesso discorso dicasi per tutti gli algoritmi di hash: MD5, SHA1,
RIPEMD160, SHA256, SHA384, SHA512, SHA224
- --
Aldo Latino
www.aldolat.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHgV3lQ1d+zUOXxzARCDq9AJ9Bn0RePpWBcz+x4Wx0jxbWYhbNIgCfQB8m
phXv49CLN1Lve56JUAbWpEA=
=PFaE
-----END PGP SIGNATURE-----

 RIPEMD160, SHA256, SHA384, SHA512, SHA224
Occhio che è inutile impostare un hash da più di 160 bit con chiavi da 1024
bit come quelle DSA.
Ha senso solo con una chiave RSA attualmente.


 Ha senso solo con una chiave RSA attualmente.
Le chiavi DSA2 (definite nell'RFC4880) possono avere dimensione
superiore ai 1024 bit delle DSA e possono certificare checksum di
dimensione maggiore ai 160 bit.
Come giustamente dicevi tu, le vecchie DSA da 1024 bit, non certificano
checksum di dimensione maggiore di 160 bit.
Ciao,
un TJL73 e i tempi che cambiano...
-- 
"Mentre sali le scale, sii gentile con chi incontri:
 potresti incontrarlo nuovamente mentre le stai scendendo."
                                                     -- Proverbio cinese

 Sign ed Encrypt sono chiari. A cosa servono C ed A?
Ehm... sai che me lo sono chiesto anch'io... e, forse, una volta, mi
sono anche risposto... ma ora non ricordo, con precisione...
Che dice l'RFC4880, in merito?  O:-)
Ciao,
un TJL73 sveglio per miracolo...
-- 
"Quando tutto il resto fa fiasco, leggi le istruzioni."
                            -- Assioma di Cahn - da "La legge di Murphy"

 dimensione maggiore ai 160 bit.
(snip)
Mi risulta che òe chiavi DSA2 di cui parli siano ancora in fase di
definizione; ero rimasto alla bozza di dicembre scorso... Già hanno
pubblicato? Link?
Comunque GPG > 1.4.3 e PGP negli ultimi mesi supportano quasi del tutto la
penultima bozza.


 tutto la penultima bozza.
Sģ... la v1.4.8 rispetta la RFC4880... quindi, AFAIK, supporta in tutto
e per tutto la gestione delle chiavi DSA2.
Ciao,
un TJL73 e la corsa all'oro...
-- 
"C'e` rimedio? Allora perche' ti preoccupi?"
"Non c'e` rimedio? Ed allora perche' ti preoccupi?"
                                                          -- SP (Toccio)

 e per tutto la gestione delle chiavi DSA2.
Ri-confermo, sono sicuro che l'attuale implementazione di DSA2 sia operativa
dalla 1.4.4.



|
| Sono, ovviamente, ben accetti commenti, ottimizzazioni, suggerimenti e
| segnalazioni d'errore.
L'ho letta e a un certo punto mi sono perso... -.-'
ma ti prometto che ci passerò ancora! :D
Ho trovato un piccolo errore di battitura:
| ma utilizzerà la privata principale per la certificazione
del'estensione di validità
"del'estensione" --> "dell'estensione"
Ciao!
- --
Aldo Latino
www.aldolat.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHg9jbQ1d+zUOXxzARCPT4AJwK74yagBhVTzCboA7vPhlcP0HlkwCZAfv4
rRgQXnMz2KoOkMbWf9pDEvk=
=gtFu
-----END PGP SIGNATURE-----


Ho letto ed ho trovato tutto molto ingegnoso. In linea di principio mi
sembra corretto.
Mi pare di capire che tutto questo lavoro viene fatto _esclusivamente_ per
non ledere il WoT, giusto?
Quali complicazioni derivano invece dal generare un portachiavi "normale",
tenerlo su un supporto sicuro, montarlo su un sistema sicuro, etc...?


 "del'estensione" --> "dell'estensione"
Lo segno tra le cose da correggere. Tnx.
Ciao,
un TJL73 e gli effetti collaterali...
-- 
"Colui che sorride quando le cose vanno male
 ha gia` trovato qualcuno a cui dare la colpa." 
                             -- Legge di Jones - da "La legge di Murphy"

 tenerlo su un supporto sicuro, montarlo su un sistema sicuro, etc...?
Il non poterlo assolutamente utilizzare su sistemi non sicuri.
So che quelli da te citati sono tutti requisiti *indispensabili*... ma,
a volte, č necessario poterne far uso in ambienti non "certificatamente
sicuri" e questo puň essere un metodo per evitare che la chiave
principale (quella implicata nel WoT) venga compromessa.
Diciamo che puň tornare utile generare una "chiave evento" per poterla
utilizzare, ad esempio, durante un periodo in cui non si puň avere
accesso ad un sistema sicuro (vacanza, soggiorno studio, lavoro fuori
sede, ...). In questo modo, la chiave principale (quella certificata) č
sempre la stessa, mentre le chiavi secondarie (da essa certificate)
saranno delle chiavi a scadenza breve (una settimana, un mese) che,
durante il "periodo evento" potranno essere eventualmente rinnovate e al
termine, potranno essere lasciate scadere.
Inoltre, in casi estremi (furto dei dispositivi e/o dei supporti),
potrebbe aiutare a non dover revocare e ricreare tutto, con le
inevitabili spiacevoli conseguenze del caso.
Insomma... lo vedrei, piů che altro, come un "rinforzo" del sistema...
di quelle cose che "male non fanno".
Tutto questo, perň, non deve *assolutamente* indurci ad abbassare il
livello di guardia altrove, rischiando di compromettere la sicurezza nel
suo complesso.
Disponibile al confronto ulteriore.
Ciao,
un TJL73 e i suoi 2 centesimi e mezzo...
-- 
"I gatti sono stati destinati ad insegnarci
 che in natura non tutto ha uno scopo."
                                                     -- Garrison Keillor

 entro l'anno dovrebbe uscire la versione definitiva.
Essendo contemplata nella RFC4880, l'avevo erroneamente e scontatamente
data per definitiva... ma direi che non era cosě.  -_-
Ciao,
un TJL73 che si sente piccolo, inutile, offeso e depresso...         ;o)
-- 
"Se ogni tanto ti senti piccolo, inutile, offeso e depresso,
 ricorda sempre che una volta sei stato il piu' veloce e vittorioso
 spermatozoo del tuo gruppo."

 un TJL73 che si sente piccolo, inutile, offeso e depresso...         ;o)
??????? :-O


 Diciamo che, fondamentalmente, lo scopo finale dovrebbe essere quello.
(snip)
Vista in questo scopo è senz'altro molto interessante.
Per un utilizzo prettamente crittografico è utile, come dici te fino ad un
certo punto: se i miei segreti sono compromessi, la validità della firma
delle altre chiavi del WoT diventa l'ultimo dei problemi (pur sempre un
problema).
Invece risulta un ottimo metodo per un utilizzo end-user di PGP e del WoT;
alla luce della tua spiegazione sarebbe quasi interessante proporlo come
vera e propria caratteristica. Che ne pensi?
Intendo una cosa che GPG possa gestire automaticamente.


 Intendo una cosa che GPG possa gestire automaticamente.
Dubito che possano prenderla in considerazione... ma, se dovesse
accadere, ne sarei ben felice...  ^_^
E', però, una procedura talmente delicata (a livello di sicurezza) che
chi la intraprende deve esserne ben consapevole... per un uso "comune",
la procedura standard, credo sia più che sufficiente.
Automatizzare il tutto, potrebbe mettere alcuni nell'impossibilità di
saper gestire la propria chiave nel tempo.
Ciao,
un TJL73 che preferisce le procedure manuali agli automatismi...
-- 
"Ho talmente pochi ammiratori che ogni volta che ne incontro uno
 mi faccio fare un autografo."
                                                        -- Paolo Cananzi


Ciao,
un TJL73 e la punta del cornetto...
-- 
"Io sono un uomo che non deve chiedere mai.
 Di solito imploro."
                                                                -- Comix

 Probabilmente, il tuo newsreader non visualizza le "signature"...
ROTFL!!!!!!!! :-D


TJL73 wrote:
[...]
Tutta la storia di creare più chiavi e revocarle/farle scadere ad uso
ultimato, è quello che faccio solitamente io, ma non mi sono mai posto il
problema di scorporarle dalla chiave originale.
In effetti è una cosa interessante, ci penserò su per il futuro. :-)
Vedo che anche tu proponi di utilizzare una chiave per ogni funzione
(certificazione, firma, cifratura): è sempre per il discorso: revoco la
chiave per la cifratura, ma le firme continuano a essere valide; revoco la
firma, le certificazioni restano valide?
Insomma rendere tutto indipendente?
Inoltre, attualmente, alla luce anche della discussione sugli standard
dell'altro giorno, secondo te (che sei più preparato di me, io sono
ristretto a GPG/Linux) una chiave RSA, con due sottochiavi RSA, è più
compatibile rispetto a una chiave DSA2?
Intendo se uno volesse evitare di usare DSA 1024bit / SHA-1.
Ci vorrebbe quasi un Lapo con le ultime sui nuovi metodi di crittoanalisi.
Ma dov'è? :-)


 Ma dov'è? :-)
Non lo so... qui ci vorrebbe un bel thread incrociato con la
partecipazione almeno di Lapo, Cristiano e Carlo Luciano Bianco...
Credi potremo ottenerlo?  ^_^
Ad ogni modo, come ho sempre dichiarato, non mi sento per nulla un
"crittologo"... non credo di essere in grado di addentrarmi nel
difficile aspetto matematico dell'argomento. Seguo più il lato pratico
della cosa.
Ciao,
un TJL73 competente a metà...
-- 
"Il competente e` un uomo che sbaglia secondo le regole."
                                                          -- Paul Valery

 un TJL73 competente a metà...
-- 



GnuPG 4069 RSAv4 key: \_____________________________________________
UID:0xE361F839--Fingerprint:9516BCF66B8F12E0C3C3154C61788B6DE361F839

 (scherzo)
:-))


 anche fatto risentire, non troppo tempo fa... ;-))
E anche tu hai ragione. :-)


 tua chiave pubblica nel suo portachiavi.
Ok. Quindi c'avevamo visto giusto.


 Che ne pensi di tutto il "sistema"?
Ehm... Dato che... cough... cough... nei ritagli di tempo... ehm...
appena posso... beh... in teoria mi starei occupando della
traduzione in inglese della pagina, rischio di non essere del tutto
imparziale neanche su questo... ;-))) 
Battute a parte, il "sistema" mi sembra ottimo. Poi, sta al singolo
utente decidere se è una cosa di cui ha realmente bisogno, in base
alle sue esigenze specifiche di sicurezza. 
Al momento attuale, uso GnuPG solo sulla mia macchina, tenendo il
portachiavi su un disco cifrato con TrueCrypt. Pertanto, tengo
semplicemente la mia chiave principale nel portachiavi con le altre.
In futuro, però, potrebbe capitarmi di dover usare GnuPG su macchine
di cui non mi posso fidare (in un internet café, ad esempio). In tal
caso, metterei sulla mia chiavetta USB un portachiavi con le sole
sottochiavi per firma e cifra, secondo la procedura di TJL73. Così,
alla peggio, revocherei solo quelle senza perdere le firme sulla
chiave principale. 


 Ma dov'è? :-)
Ho sentito il buon Lapo, è effettivamente impegnatissimo.
Ah, lo capisco.
