Newsgroup: it.comp.sicurezza.crittografia
Titolo: RNG e loro velocità

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mi è venuto in mente di stilare un freddo campionario (cfr. Elio & le
storie tese) di metodi per raccogliere entropia grezza su un PC e sulla
loro relativa velocità.
Molti dei numeri che dirò saranno stime assolutamente "a occhio" giusto
per farsi un'idea e, in caso, potremo raffinarle in un secondo momento...
********
Il metodo in assoluto più vecchio è "si chiede all'utente di scrivere
testi a caso sulla tastiera"
fonte 1, la distanza temporale tra due successive pressioni di tasti:
normalmente il tick count dei PC non offre valori più precisi dei 10ms,
quindi a meno di non usare metodi "nuovi" come il RDTSC (ove
disponibile, è una soluzione poco portabile) difficilmente questa fonte
potrà avere più di 1 bit per tasto e se l'utente preme una fila di tasti
con una singola manata, probabilmente meno
fonte 2, il valore stesso del tasto premuto: considerando solo quei
tasti che siano, come minimo, diversi dagli ultimi 3 premuti (per
evitare pattern tipo: zxczxczxczxc) si può ottimisticamente pensare a 1
bit per tasto
abbiamo quindi in globale ottimistico di 2 bit/tasto, pessimistico
diciamo di 0.2 bit/tasto; i tasti verranno premuti generalmente circa 1
al secondo
rate: 0.2-2.0 bit/s
********
Il secondo metodo più vecchio: "muovi il mouse, caro utente"
gli eventi ricevuti saranno tutti del tipo (x, y) e entrambi avranno
delle delta comprese nella maggior parte dei casi in [-1,+1], per un
totale di 8 casi interessanti e 1 non interesstante (delta di (0,0): il
mouse è rimasto fermo); codificando gli 8 casi "interessanti" in simboli
di 3 bit (numerandoli in un modo qualsiasi deciso a priori) si può
ipotizzare che questi simboli di 3 bit contengano 0.1 b di entropia,
forse meno (se il mouse viene mosso in linea generalmente retta sarà
molto facile avere decine e centinaia di eventi uguali tra loro); di
contro questi eventi arriveranno cno una certa frequenza, diciamo in
modo molto conservativo 40 al secondo (in realtà è più vicino ai 400, ma
in altri momenti il mouse sarà fermo); fattore interessante di questo
metodo è che per quanto sia richiesta l'interazione dell'utente, questo
nno ha modo di "dirigere" l'operazione, in quanto non ha controllo sui
singoli "quanti" di movimento del mouse
rate: 0.4-4.0 bit/s
********
Metodi basati sul clock
per quanto questo metodo abbia una qualità piuttosto scarsa, è anche
l'unico che è sempre (in una qualche sua forma) disponibile in
praticamente OGNI architettura PC moderna, si tratta in pratica di
leggere il valore del clock più preciso disponibile ogni volta che
succede un qualche evento "non prevedibile" (se si può lavorare in
kernel-space gli eventi migliori sono gli IRQ alzati dall'hardware, ma
questo è il metodo successivo), oppure misurare il "drift" di
un'oscillatore rispetto da un'altro (i PC generalmente ne hanno almeno
uno per la frequenza di bus della CPU e uno per gli interrupt del
refresh della RAM)
rate: 0.1-10 bit/s (dipende molto dalla qualità del clock disponibile)
********
Metodi accessibili solo dal kernel (/dev/random su *nix, CAPI su Win)
qua l'affidabilità e la velocità di generazione dipende sostanzialmente
dal tipo di "interrupt" che vengono sfruttati, dal metodo stesso con cui
l'RNG è fatto
differenzierei decisamente l'affidabilità dei sistemi *nix e delle CAPI
di Windows, se non per motivi di "trasparenza" almeno sul seguente fatto:
cygwin% dd if=/dev/random of=/dev/null bs=1024 count=100000
102400000 bytes (102 MB) copied, 16.848 seconds, 6.1 MB/s
(nota: /dev/random di cygwin utilizza l'rng delle CAPI)
...e 48.8 Mb/s è decisamente oltre quanto i timing delle periferiche
hardware possano dare, quindi sicuramente è l'output di un PRNG che usa
il rumore hardware solo come seed (non che questo sia un male a priori,
per l'uso crittografico un buon sistema di questo tipo come ad esempio
Fortuna è decisamente usabile, ma noi ora stiamo cercando della vera
entropia, niente di calcolate)
freebsd% dd if=/dev/random of=/dev/null bs=1024 count=100000
102400000 bytes transferred in 3.701791 secs (27662287 bytes/sec)
anche qua un valore stranamente alto (221.3 Mb/s), ma FreeBSD usa
Yarrow, un buon sistema ma che dà un output "crittograficamente sicuro"
(in pratica è il "padre" di Fortuna, sempre di Schneier & soci) ma non
"raw" come ora stiamo cercando
insomma, ai nostri scopi di ottenre entropia "raw" in modo diretto direi
che questi metodi non sono utilizzabili, a meno di poter fare modifiche
al kernel per estrarla "prima del rimaneggiamento", cosa che
difficilmente un programma in "userland" avrà la possibilità di fare
rate: N/A
********
Rumore della scheda audio
Pro: accessibile da userland (perfino da java!), contiene vera entriopia
generata dal rumore elettronico dei chip a valle dell'ADC della scheda
Contro: non tutti i server hanno una scheda audio (soprtutto i "blade",
quelil che usano chede madri "normali" in genere la hanno on board,
quidni anche se non gli serve la hanno)
un'avvertenza importante è di alzare il volume di acquisizione del
microfono al "massimo" e di consigliare all'utente di non attaccare
niente alla porta mic (per aumentare il rumore); inoltre è bene
campionare al massimo numero disponibile di bit per sample
campionando a 16 bit/sample, anche con microfono pluggato (e quindi il
temirnale meno li bero di "muoversi liberamente" tra vari valori di
tensione) è piuttosto comune vedere rumore di fondo che si muove anche
su parecchi livelli; ad esempio sulla mia (pessima) scheda audio AC97
on-board in 2-3 secondi di campionamento 48KHz 16 bit/sample microfono
pluggato&spento ho ottenuto campioni in [-306,+360]
di cui il 99.9% in [-209,+271]
e il il  99% in [-157,+213]
e il 70% in [-30,+67]
con spettro abbastanza "bianco" (ho usato l'analizzatore di spettro del
programma Audacity)
quindi diciamo che ogni sample potrà contenere intorno ai 6 bit di entropia
dovendo però prevedere che l'utenet abbia una scheda audio anche molto
migliore della mia non considererei più di 1 bit per sample, e pensando
che il campionamento sia ai "sempre disponibili" 44KHz invece di 48, si
ottiene...
(nota: è vero che il line-in è un ingresso stereo e potrebbe avere il
doppio dell'entropia, ma è anche vero che la linea "mic" in genere ha un
pre-boost, molto utile a generare maggiore rumore ;-))
rate: 44 Kbit/s
********
Metodi "HW dedicato"
Dipende, ovviamente, dall'hardware... il più comodo è sicuramente quello
includo nelle cpu VIA C5: hanno un opcode dedicato alla generazione di
entropia, che il produttore certifica per 800Kbit/s
********
In buona sostanza il mio consiglio è questo: usare un solo sistema non
va mai bene, usate tutti quelli possibili, "distillate" l'output SEMPRE
con un hash assicurandovi di dargil in ingresso una quantità
SOVRABBONDANTE di entropia (a seconda di quanto volete sentirvi sicuri
dividete per 10 o anche per 100 le stime di cui sopra) e, dove non è
disponibile hardware dedicato, su un "comune PC" la fonte in assoluto
più veloce è la scheda audio (se anche decidete di dividere per 100 la
stima otterrete sempre 440 bit/s, cento volte di più che con i metodi
"basati sull'utente", che peraltro non sempre è alla console quando
avete bisogno di entropia!)
Nota: per fare un "CD pieno di entropia" e consderando buona
l'approssimazione di 44Kb/s della scheda audio (cosa certamente
fattibile per una scheda audio "pessima" e "rumorosa" come la mia!)
servono comunque più di 5 ore; cosa volendo anche fattibile se ilproprio
scopo è fare una coppia di CD ad uso OTP (un CD per sée l'altro da dare
DI PERSONA all'altro destinatario, entrambi da tenere sempre in
cassaforte e da usare su un PC senza accesso a nessuna rete, se nno si
vuole vanificare TOTALMENTE l'utilità (già di per sé marginale) di usare
un OTP invece che non, ad esempio, AES).
Un ricercatore universitario molto interessato alla questione RNG è
Peter Gutmann (noto anche per le sue ricerche sul recupero di dati da
HDD e da DRAM già sovrascritte più volte con altri valori).
Ad esempio questo è un capitolo da lui scritto che analizza (e, in molti
casi "distrugge") il RNG di molti software o OS, è un pochino datato, ma
sempre una buona lettura:
http://www.cypherpunks.to/~peter/06_random.pdf
Questa invece la sua homepage:
http://www.cs.auckland.ac.nz/~pgut001/
Oppure ancora la RFC 1750 "Randomness Recommendations for Security":
http://www.ietf.org/rfc/rfc1750.txt
O i pezzi disponibili online del libro "Foundations of Cryptography":
http://theory.lcs.mit.edu/~oded/frag.html
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkJ0xtoACgkQaJiCLMjyUvtcSACfWwBRDRF9hok2wACC3tmaMq5H
cagAnAjAeOIlTP1OHwlyQYMqF0LenATB
=k7CF
-----END PGP SIGNATURE-----

 102400000 bytes transferred in 3.701791 secs (27662287 bytes/sec)
Linux SlackWare 10
manuel@M1nD:~$ time { dd if=/dev/random of=/dev/null bs=1024 count=10000; }
0+10000 records in
0+10000 records out
real    2m28.633s
user    0m0.010s
sys     0m0.000s
Facendo un rapido conto: ~70 kBytes/sec
Ma con una generazione 10 volte inferiore di dati (e ho mosso molto il
mouse :p).
Manuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBQnUzbA9bI6HlCa2jAQiGxAf7BpPHl4UenJrAqoTMHkNvTRhHBoptc2rJ
0Pryyv3ie7a6JHw+RwGG8jlKl8y9ccQIvTbs3JfjlqTSbBMVd3IntEn4vghal+A6
EvgpjBK4SLm64kc8ODdFtzioPkGQ0cXdr67Dp8g0V5dXgMhbuAzvKcqBHkNufXfu
7AMGjo87uADAoiPiGJBObTeX6VZhyxNC7D7zekhE7CugkihQUNOI3yGlQqkMlnI5
8M+2T0pVHLpk9LJMK1Tyh6KwM3QMYK/mC8efuuQozK0ttmSfc8A50T+qyCTQ8GOj
7+3Ws0BkIPR82eGOV44uQqbTWQVd1arUffM3PVBBsWFbaIcuLeBUYw==
=Z0Fx
-----END PGP SIGNATURE-----

 mouse :p).
Uhm... Scusate, ma qualcosa mi sfugge: con questo procedimento non sono
stati generati 1024 x 10000 = ~9.7MByte, ma, facendo qualche prova anche
ora, un valore che varia di volta in volta (30-150KBytes).
Ignoro il perche', mi informero', ma magari puo' essere una feature di dd o
del kernel che interrompe il programma quando non sono piu' disponibili
abbastanza bits casuali? Ah, ho usato il kernel 2.4.30.
  Manuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBQnVrug9bI6HlCa2jAQh/PAgAuQ7Or/8gZNjgufJXM2hQg4hz25OuhDh9
d6rJOh+vQdP2UdYSMkjSXszpzTP8pDy1QLxw/LtIV7R9njUAWnhH5eE6Y4h4XC8H
hsPJ9AU8UItRtG9UrXjjZKw3sgUdahj7xJKMQUC6qOPJLb/H1zCpc2mgEC0mVu5q
OK9SZm/PsreiYfNQ6djdvEltHsYbdmP/JqgXyP2o1gJtp4e3SG1GnG9nLx7cOoul
jlVEdIcyrEsfNL3FEqA+FSK6wH56Qut0OfBJUkH/QNc8woo3uC3qStLdBWzx4aiV
HOkO2pCEb7QgPEa5nr1f09ZflGUuIsBpvcoEwbuo8zu3mT0YFWHugQ==
=hLZs
-----END PGP SIGNATURE-----

 disponibili abbastanza bits casuali? Ah, ho usato il kernel 2.4.30.
Sì, ho letto qualcosa del genere. Quando il generatore termina i bit ad alta
entropia (perché ne richiedi più di quanti ne riesca a generare) inizia ad
utilizzare un PRNG (che è molto più veloce).
Cristiano

 mouse :p).
Guarda che spero bene che /dev/random ti dia entropia giù "filtrata",
quidni non ti deve interessare come l'ha raccolta (interrupt del mouse,
della scheda di rete, dell'hard disk...), non devi dividere niente per
10, al limite l'ha già fatto lui (si spera =P).
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkJ1ZjUACgkQaJiCLMjyUvuCqwCdHoOooZ9Nhhpl8VQHqUYmiRSo
LaMAoPjsFB9LaCuDF6+QHZdWTKePmP65
=NETc
-----END PGP SIGNATURE-----

 10, al limite l'ha già fatto lui (si spera =P).
Beh quel conto richiedeva che fossero stati generati ~10 MBytes di dati,
mentre poi mi sono accorto che si fermava a ~150 KBytes.
Comunque era solo una specie di statistica tra la quantita' generata e il
tempo impiegato, ho specificato che avevo rischiesto 10000 anziche' 100000
"cicli" da 1024 bytes l'uno perche' altrimenti ci avrebbe messo troppo.
Piu' che altro mi interessava sapere se questo metodo poteva esser
utilizzato per ottenere entropia raw, visto che si basa su eventi non
deterministici all'interno dell'environment.
Grazie
	Manuel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQEVAwUBQnYpIQ9bI6HlCa2jAQjTwwgAlqoMf1rH3dH64OnfKUzyzDEyJFgEA0mx
B4kkZtXEfaRZYyHH8ueWBgfkqMLyA9HSkD4BhK35ldb9kyT5idQ91LOvywhFR/tZ
rEUkO7+xEw2L3xnIg3W5LwuR6j1HGocK/K6i7JyXFYztD1xgA6+dbNYumR1vpuRa
mrg7dP+teL8i37k4V8VeoDZ50vL6HT7EeE342SU2APJA1CoDPYjKIWszZg0nUq47
d6Qyk1JGfcQ7kBdAut6bfJD2LNSmsSlBKGLzH86hjnHAsS9t+e2lh8xEo83JQ077
acJqhAJKbZS2YfAfIy3tZbrKXwSioHOSx0G4KB+1ysvYY+okZKZq4Q==
=TXpc
-----END PGP SIGNATURE-----

 deterministici all'interno dell'environment.
Beh, "raw" no, anche nel tuo caso (dove pare essere estratta solo se
"ragionevolmente presente" - e tieni conto che è MOLTO difficile stimare
quanta sia in effetti presente) il RNG di sistema ci fa sempre parecchi
smaneggiamenti. E tra l'altro il paper di Gutmann dice che lo "stato
interno" del RNG di PGP (come il file che hai incollato dice di essere)
non è del tutto "al sicuro" e non gode di "sicurezza in avanti" come ad
esempio offrono i design CSPRNG Yarrow e Fortuna.
Secondo me la regola è questa: se ti serve "buona entropia" epr fare una
chiave AES o cose così, vai con /dev/random, dove disponibile, ma se
vuoi fare le cose davvero per bene, usa Fortuna con tutte le fonti che
trovi (ivi compresa un po' di entropia presa da "/dev/random" in modo da
essergli sicuramente non inferiore!).
Il mio messaggio principale parlava principalmente di fonti perché
volevo parlare più di come raccoglierla "in modo diretto" che non quale
sia il sistema migliore per usarla... IMHO a prescindere da quanto il
RNG dell'OS sia "ben fatto" è bene che OGNI programma usi il suo CSPRNG
per, diciamo "normalizzare" il comportamento in caso che una o più delle
fonti esterne "vengano meno".. in modo insomma da "fallire in modo
amichevole" (gh, questa viene meglio in inglese, in italiano suona male =P).
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkJ2EoUACgkQaJiCLMjyUvsuawCg5kzhDoGR0EIP0QuonExLPibq
uKYAoMY+GYcpuK79tbcxjL22UoQ6t4AN
=J+HZ
-----END PGP SIGNATURE-----

  [X.509 available]
Linux Reg. User: #263663 / Machine: #216144 (Arch Linux/Wombat)
On the Web: 
http://www.quaqo.org
 - My OpenPGP KeyID: 0x5539D8E4
On ICQ: 48618109 - On Jabber: 
qu...@jabber.org/@jabber.linux.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFChI03ZXjZQFU52OQRAssSAKCTL9UvE/Qt2rO3/e+7DJ//9zlOUQCbBvLL
sYPZ6dscoYTJsBInYJL9asI=
=iTaj
-----END PGP SIGNATURE-----

 fonti di entropia.
Che vuoi dire?
Cristiano

  [X.509 available]
Linux Reg. User: #263663 / Machine: #216144 (Arch Linux/Wombat)
On the Web: 
http://www.quaqo.org
 - My OpenPGP KeyID: 0x5539D8E4
On ICQ: 48618109 - On Jabber: 
qu...@jabber.org/@jabber.linux.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFChM9ZZXjZQFU52OQRAqK7AKCFC3JFiPMzCGyL9YhnrtmB8EzxZgCg4F3L
I9QG8BuEo1CZxpswehewjXE=
=iyTm
-----END PGP SIGNATURE-----

 fonti di entropia.
In FreeBSD, da quando usa Yarrow (FreeBSD 5.0) /dev/random e
/dev/urandom sono lo "stesso" device (basato appunto sul CSPRNG Yarrow).
Questo è sicuramente "comodo" dal punto di vista delle applicazioni
sicure che sanno che non verranno bloccate per tempi anche lunghi in
attesa di entropia. Inoltre con il sistema di Yarrow (che credo sia lo
stesso di Fortuna) per raccogliere l'entropia un altro vantaggio è che
la procedura di raccolta (aggiungere in un hash, singolo nel caso di
Yarrow, uno a scelta tra 32 nel caso di Fortuna) è così rapida che hanno
potuto "disseminare" di raccolta MOLTI più punti del kernel di prima e
quindi, alla fine, avere anche "più entropia vera" che con il sistema
vecchio.
Per le caratteristiche stesse di Yarrow finché l'entropia è sufficiente
la "segretezza" dell'uscita NON dipende dalla forza degli algoritmi
crittografici usati, quando invece questa viene a mancare si è comunque
"protetti" dalla sicurezza crittografia degil algoritmi.
Non vedo l'ora che passino a Fortuna... che come Yarrow ha l'enorme
vantaggio della snellezza di raccolta e della sicurezza crittografica
dell'uscita ma, in più, non ha per design alcun bisogno di un complesso
e NECESSARIAMENTE impreciso stimatore di entropia...
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkKFyYAACgkQaJiCLMjyUvuIgACguM8buaecXD4iLld5LhnfLO9D
X70An1ZUdztSvG32WrImaTKTETuclf2R
=Lkaz
-----END PGP SIGNATURE-----

 Se questo è vero, mi sembra che sia un sistema molto subdolo e pericoloso.
Da un punto di vista "semantico" è sicuramente qualcosa di pericoloso ma
secondo me, globalmente, è molto MENO PEGGIO che non avere un uso
estremamente lento e "bloccante".
Secondo me l'usare un CSPRNG, per un kernel, è un'ottimo "compromesso":
è certamente MOLTO più sicuro di quello che la maggior parte delle
applicazioni userebbero, permette ad applicazioni che hanno bisogno di
molta entropia di prenderla da un luogo "sicuro" senza essere intimorite
dalla bassa frequenza a cui viene "generata" (e anche qui, quasi
sicuramente è comunque migliore di quella che le applicazioni stesse
genererebbero).
Non ostante questo, però, sostengo che una applicazione che ha bisogno
SERIO di casualità deve ASSOLUTAMENTE implementare il PROPRIO generatore
(che ovviamente deve essere fatto "con tutti i crismi"), di cui ha
totale controllo, e usare quello del kernel come "una delle tante
fonti", magari la principale, ma non l'unica: questa è una regola
generale di quando si fa qualcosa di sicuro, bisogna dipendere il meno
possibile (possibilmente, per niente) dal mondo esterno, quindi se serve
entropia è giusto prenderla da /dev/random (dopotutto il kernel ha
accesso a molte più fonti che non quelle a cui può accedere il programma
stesso) ma usando un generatore locale al programma (e generatori
modello Fortuna occupano VERAMENTE POCO come codice) si "tiene al
sicuro" da eventuali implementazioni non funzionanti o meno sicure del
kernel, o altro.
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkKFy3oACgkQaJiCLMjyUvtH7QCgsxnHrzS9klYN49oWZFtHtAZj
xaEAnj13CaU/NU3epQX64kDLbFecKouO
=HeKy
-----END PGP SIGNATURE-----

 /dev/urandom sono lo "stesso" device (basato appunto sul CSPRNG Yarrow).
Dimenticavo i link del caso:
http://www.freebsd.org/cgi/man.cgi?query=random&sektion=4
Inoltre questo messaggio di Mark Murray del 5 agosto 2004 dice che si
sta "preparando" per passaer a Fortuna:
http://article.gmane.org/gmane.os.freebsd.current/52729
  Lapo
- --
L a p o   L u c h i n i
l a p o @ l a p o . i t
w w w . l a p o . i t /
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - 
http://enigmail.mozdev.org
iEYEARECAAYFAkKF09AACgkQaJiCLMjyUvvW+QCgzPx+xzQIU441xjzs4sa51ge1
GssAoK7IO0YMIj/eYhe5cCLtsSFP177/
=cOFv
-----END PGP SIGNATURE-----

  [X.509 available]
Linux Reg. User: #263663 / Machine: #216144 (Arch Linux/Wombat)
On the Web: 
http://www.quaqo.org
 - My OpenPGP KeyID: 0x5539D8E4
On ICQ: 48618109 - On Jabber: 
qu...@jabber.org/@jabber.linux.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFChdaHZXjZQFU52OQRAm6ZAJ45iYXcf42NpuVW50CEbcYOGgsjSACZAaFZ
hCbc1mCgkWM7Wg8LIxK5oYc=
=xyn2
-----END PGP SIGNATURE-----

  [X.509 available]
Linux Reg. User: #263663 / Machine: #216144 (Arch Linux/Wombat)
On the Web: 
http://www.quaqo.org
 - My OpenPGP KeyID: 0x5539D8E4
On ICQ: 48618109 - On Jabber: 
qu...@jabber.org/@jabber.linux.it
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFChdbLZXjZQFU52OQRAqGNAKCqUgPxpdBdMoKviDga1QMU6tKFgACfU41f
5X2CyowczYgIIIyBPmebzzY=
=OyWK
-----END PGP SIGNATURE-----