[e-privacy] Cifroserver 2 - la vendetta

[ale]

"Marco A. Calamari" <marcoc1 at dada.it> ha scritto:
> 
> Per capire se una cosa e' la soluzione, bisogna prima enunciare,
>   il problema, ed essere d'accordo sul quale e'.
> Altrimenti capirsi diventa difficile.
> 

Salve a tutti,
volevo cogliere lo spunto di questa discussione che ritengo interessante
per provare a raccontare un po' di quello che ne penso
(anche se queste sono le mie opinioni personali, riflettono
la discussione portata avanti all'interno di Autistici/Inventati).

Il passo quotato sopra non e' casuale: il periodo di sospettosissimo
silenzio non ci e' servito per complottare in privato nuovi e
segretissimi metodi di crittazione dei server ;) , bensi' proprio a
cercare una enunciazione corretta del nostro problema - e non mi
riferisco solamente al "sequestro" fraudolento operato dalla postale, ma
in generale all'operato di un server come il nostro. Una volta definito
precisamente il problema trovare una soluzione possibile e' molto piu'
semplice.

In effetti la maggior parte delle soluzioni di cui si e' discusso
in questa lista non e' particolarmente adeguata al nostro problema
per un semplice motivo - al di la' dell'impatto in termini di
prestazioni su di un server gia' sotto carico intenso - e cioe' che non credo
(come anche riconosceva Leandro in una mail passata) sia molto saggio
mettersi nella posizione di possiedere la chiave (singola!) di migliaia
e migliaia di caselle di posta.
Una cosa piu' intelligente sarebbe implementare un meccanismo per
cifrare _singolarmente_, con chiavi individuali, ciascuna mailbox.
Anche qui i problemi di prestazioni si sprecano, ma sarebbe tecnicamente
pensabile crittare tutti i messaggi in ingresso con una chiave asimmetrica:
l'ostacolo principale diventa a questo punto la webmail (che purtroppo e' il
sistema piu' usato dai nostri utenti), non abbiamo trovato nessun software con
le caratteristiche adeguate... almeno fino ad ora, ma continueremo a
cercare...

La crittografia del contenuto completo dei server dunque non e' un'opzione
praticabile per noi, cosa di cui del resto ci eravamo resi conto da un
po', convincendoci che non ci fossero molte alternative ad una migliore
educazione degli utenti sulla gestione personale della propria privacy.

Altra cosa e' difendersi dal tipo di intrusione come quella verificatasi
a giugno, il cui scopo era (ok, non solo) impadronirsi di alcuni file
specifici che permettessero l'intercettazione delle comunicazioni future
(e passate, magari): questi si' sono files che vanno protetti
crittograficamente, almeno per evitare che, a macchina spenta, sia
possibile accedervi - per questo essenzialmente puo' bastare un loop
device crittato, da montare (con inserimento di password a mano) all'avvio
prima di far partire i servizi interessati.

Piu' in generale, dato che comunque asserragliarsi su delle posizioni
"difensive" alla lunga e' una scelta perdente (o meglio, e' una scelta
che viste le risorse che abbiamo non possiamo intraprendere), la
direzione che mi sembra migliore e' quella del decentramento, della
dispersione, della moltiplicazione. Anziche' pretendere di "garantire"
una qualche sicurezza (cosa che siamo stati attenti a non fare mai,
ma e' probabile che in non pochi abbiano avuto questa errata impressione)
dei dati memorizzati sui server, che in definitiva ci e' impossibile,
cercare di puntare sulla "resistenza" della struttura di comunicazione
medesima in ogni eventualita'.

Spero (ma dubito!) di essere stato sufficientemente chiaro, e' difficile
riassumere compiutamente in una mail tutte le riflessioni fatte: per
questo stiamo preparando una serie di documenti che dovrebbero essere
pubblici a partire da settembre.

Spero soprattutto che questa esposizione abbia soddisfatto qualche
curiosita' (o che invece ne abbia create di nuove)!

ciao,


--
ale

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20050823/db83a2b3/attachment.pgp>