Newsgroup: it.comp.sicurezza.crittografia
Titolo: 2 domande: 1) doppia chiave 2) chiave+firma

Volevo fare un paio di domande:
1)
è logico o apprezzabile dal punto di vista della sicurezza cifrare dei
dati con 2 algoritmi differenti?
Ad esempio, se un file lo cifro prima con il Blowfish (esempio) e poi il
risultato lo cifro nuovamente con lo stesso o con un altro algoritmo,
tipo AES (esempio), è una cavolata oppure ha un senso?
O la doppia cifratura con 2 algoritmi differenti non è in termini di
sicurezza migliore di un passaggio singolo ma con una chiave in bit che
è la somma della lunghezza delle chiavi dei 2 algoritmi (1 passaggio con
AES a 256 bit = 1 passaggio con Blowfish a 128 bit + 1 passaggio con AES
a 128 bit)?
2)
La cifratura di un messaggio non garantisce che il messaggio sia stato
comunque manipolato durante il suo viaggio dal mittente al destinatario.
Un hacker avrebbe potuto intercettare la sua trasmissione e, non
potendolo decifrare, averlo manipolato in modo da alterare i dati.
Pensavo quindi che una buona cosa fosse l'aggiunta di una firma digitale
alla fine di un messaggio codificato, firma che avrei aggiunto
eventualmente con un algoritmo di hashing (MD5).
Ma in questo caso un hacker non potrebbe notare l'aggiunta dell'output
dell'MD5 in coda al messaggio e ricalcolare la firma sulla base del
messaggio da lui modificato? In questa maniera, il destinatario,
controllando la firma, penserebbe che il messaggio è autentico e non
manipolato, ottenendo durante la decifratura dati senza senso...
Allora forse dovrebbe essere cifrata anche la firma, inglobandola nel
corpo del messaggio ed estrapolata poi in fase di decifratura dal
programma che gira sul computer del destinatario?
-- 
Ciao.
Leo.
WEB: 
www.leonardomiliani.com
 
E-mail: 
leon...@leonardomiliani.com

 destinatario.
Per garantire l'autenticità del messaggio, esistono molti algoritmi: CCM, 
CWC, EAX, OCB, ecc.
Altri sono inglobati negli stessi algoritmi di cifratura, come, ad esempio, 
il Phelix di cui tu stesso parlavi.
Cristiano 

 CWC, EAX, OCB, ecc.
Quali fra quelli citati, secondo le tue conoscenze, ha la maggior
facilità d'implementazione e non è troppo dipendente dall'algoritmo di
cifratura? Di non citati ho trovato l'OMAC:
http://www.nuee.nagoya-u.ac.jp/labs/tiwata/omac/omac.html
Mi pare indipendente dall'algoritmo di cifratura.


 Mi pare indipendente dall'algoritmo di cifratura.
Uso poco questo tipo di algoritmi e le implementazioni le ho sempre trovate. 
Da quel che mi ricordo sono quasi sempre costituiti da operazioni elementari 
per cui dovrebbero essere facilmente implementabili (ricordo in particolare 
l'EAX e l'OCB).
Cristiano 

 programma che gira sul computer del destinatario?
Giustissimo. Ci sono diversi sistemi di composizione tra message digest
e cifratura, anzi, ormai una buona libreria crittografica non può
prescindere da offrire una qualche opzione di Authenticated Encryption
(dove autenticazione indica in parole povere un message digest che sia
dipendente da una chiave segreta, con caratteristiche tali da essere
difficilmente forzabile ignorando la sola chiave segreta)
Il problema è che dimostrare la sicurezza della composizione tra una
cifra e un hash è piuttosto complicato, per cui si sono cercate anche
altre soluzioni:
- alcune cifre (es Phelix) gestiscono direttamente la cifratura e
l'autenticazione;
- sono stati scritti alcuni modi d'uso per una generica primitiva
crittografica che forniscano sia cifratura che autenticazione usando
una sola chiave e soprattutto usando una sola primitiva crittografica,
in questo modo basta dimostrare che la cifra sia sicura e che la
composizione sia sicura per dimostrare che il nuovo modo d'uso sia
sicuro; EAX ad esempio è un modo d'uso con una dimostrazione
matematica di sicurezza (vincolata all'unica ipotesi che la primitiva
usata sia sicura), che cifra in modo CTR e autentica in modo OMAC.
Allo stato attuale ci sono molti modi ben quotati per ottenere il
risultato che chiedi, IMHO ti conviene dare una occhiata a thread su
authenticated encryption e classic composition per avere un panorama
più completo prima di metterti a scrivere qualcosa.

 difficilmente forzabile ignorando la sola chiave segreta)
Ho scritto un programma di cifratura basato su algoritmi di tipo a
flusso (stream cipher), che, come ho detto in altri post, preferisco
rispetto a quelli a blocchi.
Ho implementato l'RC4 per la sua velocità e semplicità d'uso per livelli
di sicurezza bassi e 2 algoritmi presentati all'Ecrypt, vale a dire il
Salsa20 e l'HC-256. Del Salsa mi piace la struttura con nonce che, da
quel che ho potuto capire, introduce un ulteriore livello di sicurezza
nella cifratura, mentre dell'HC-256 ho apprezzato la velocità. Ho anche
implementato un sistema di autenticazione digitale basato sull'HMAC-MD5
con chiave segreta differente da quella utilizzata per la cifratura del
file in chiaro. Il risultato finale mi sembra discretamente buono, visto
che sia il Salsa che l'HC-256 li sfrutto con chiavi e IV a 256 bit e
l'HMAC-MD5 lavora sull'MD5 a 128 bit.
Che ne pensi? L'HMAC-MD5 a 128 bit mi abbassa il livello di sicurezza
globale a 128 bit oppure questo non tocca il livello dell'algoritmo (256
bit)?


 bit)?
MD5 non è una funzione particolarmente robusta e la composizione
classica tra mac e cifre non è più considerata il modo migliore di
fornire autenticazione, comunque questo ulteriore passaggio non
influisce sulla qualità della cifratura ma solo dell'autenticazione,
se poi le primitive crittografiche che usi forniscono esse stesse
autenticazione il controllo diventa ridondante e la qualità dell'uno
non influisce sull'altro.
Almeno, in teoria, poi la crittografia è un campo abbastanza complesso
e in cui gli errori concettuali o pratici purtroppo non saltano subito
all'occhio come in altri campi (i dati cifrati e i tag sembrano sempre
più o meno randomici...).
Non conoscendo bene le cifre che usi (a parte l'RC4) non posso darti
più di tanti consigli, se non quello di continuare a guardare esempi
pratici di crittosistemi su testi fondamentali come quelli che furono
consigliati sul ng qualche tempo fa, magari nelle versioni più
aggiornate (o scaricare qualche lezione di crittografia dalle
principali università inglesi o americqne, se hai familiarità con
l'inglese) per cercare di avere una visione d'insieme su un
crittosistema il più possibile simile a ciò che stai implementando.

 programma che gira sul computer del destinatario?
Non siamo punto e a capo?

 Non siamo punto e a capo?
Beh, aumenterei i controlli da far eseguire sul mio messaggio ma darei
la certezza al mio cliente che:
1) il messaggio è originale;
2) la firma è stata posta effettivamente da me e dopo aver cifrato il
messaggio.
-- 
Ciao.
Leo.
Web: 
www.leonardomiliani.com
E-mail: 
leon...@leonardomiliani.com
Scegli software opensource - Choose opensource software

 messaggio.
....
Ci sono già terze parti certificanti le firme elettroniche e sicurezze
davvero serie date da sistemi che utilizzano smartcard, oltre che pin e pw.
Poi tutto, in teoria, è aggirabile. E' solo una questione legale di
inversione di onere della prova a svantaggio di chi, avendo firmato, voglia
disconoscere, poi, la firma elettronica: è sulle spalle di chi appare essere
il firmatario che ricade il non facile compito di dimostrare la falsità
della firma.