[e-privacy] Cifroserver 2 - la vendetta

[Marco A. Calamari]

On Tue, 2005-08-23 at 13:49 +0200, ale wrote:
> "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.

Ciao,

dove e' scritto che si deve sapere chi possiede la chiave
 singola (penso tu ti riferisca ai dischi) ?

Poi esistono le chiavi in sharing, parziali od a password multiple.

Ed infine, avete fatto prove per dire che una cifratura aes inciderebbe
 significativamente sulle prestazioni della macchina ? I buffer
 del filesystem di linux non vengono mica cifrati.

E, ad esempio, uno swap criptato non incide in maniera significativa.

Ma, ripeto, condividere questo tipo di informazioni servirebbe a tutti.

Io ho cifrato una pbox tipo III, processore Geode 266 mhz, equivalente
 ad un pentium I (una lumachina), e non ce se ne accorge nemmeno.

Le cache lavorano bene, ed i buffer di s.o. pure....

> 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...

Questo si che mi sembra una situazione complessa.... ma mi riservo
 di capirne di piu' in seguito.

> 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.

Non la vedei in alternativa ad altro, ma semplicemente come prima
 barriera di difesa anti raid. E' automatica e (se si fanno i backup,
 che qualcuno dovra' ben custodire, magari insieme alla chiave)
 non costa (quasi) niente
> 
> 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.

Quindi non criptare la root, ma solo alcuni filesystem ? Ed i
 certificati ? Almeno etc e var dovrebbero essere comunque criptate

> 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'.

Al solito, perche' vedere le soluzioni in alternativa, e non associate
 nell'ottica di una difesa in profondita' ?

> 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.

Bene, cosi' cancelliamo il virus ...   ;)

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

Certamente ne ha create piu' di quelle che ha soddisfatto, ma, essendo
 le discussioni precedenti avvenute non in pubblico e non avendo tu
 ancora fornito nessun particolare (le cose che si *faranno*, non quelle
 che non si faranno) non poteva essere altrimenti.

Con il massimo rispetto delle vostre posizioni "abbottonate",
 a risentirci.

Ciao.   Marco

-- 

+--------------- http://www.winstonsmith.info ---------------+
| il Progetto Winston Smith: scolleghiamo il Grande Fratello |
| the Winston Smith Project: unplug the Big Brother          |
| Marco A. Calamari marcoc at dada.it http:// www.marcoc.it     |
| DSS/DH:  8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B |
+ PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 ----------+

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20050823/3a525a83/attachment.pgp>