Copyrigtht © 1986 Universita' di Firenze. All rights reserved.
Free license available.
Indice:
4.1 Introduzione.
4.2 Caratteristiche principali.
4.3 Messaggi SHTTP.
Per incoraggiare il commercio elettronico su Internet, le industrie si sono mosse per stabilire uno standard di sicurezza per il World Wide Web. Il consorzio per il WWW ha pensato di scegliere come standard di base per l'autenticazione e la crittografia l' SHTTP. Il consorzio è composto da: Digital Equipment Corp., AT&T, MCI Communications Corp., IBM, Novell Inc., Netscape Communications Corp., National Center for Supercomputing Applications (NCSA), e la Microsoft Corp. SHTTP ha già raccolto il supporto dalla Novell, Digital, CompuServe, Spry Inc., NCSA, Spyglass Inc., e Microsoft. Netscape invece sta promuovendo il suo protocollo SSL come alternativa di protocollo sicuro per il Web. Comunque anche Netscape, che detiene il 90% del mercato dei browser su Internet con Netscape Navigator, ha annunciato di voler supportare lo standard SHTTP. La forza dell' SHTTP è nella sua flessibilità e nel fatto che da anni sta continuamente evolvendo attraverso dei miglioramenti e rifiniture. SSL è più generico e non rivolto alle applicazioni poichè lo standard SSL vuole diventare un protocollo che offre servizi a livello più basso. Alla Microsoft si pensa all'SSL come una pratica soluzione per avere sicurezza fra client e server nell'immediato, mentre SHTTP è vista come la soluzione più giusta nel lungo periodo. La Microsoft dichiara comunque che supporterà entrambi gli standard, prendendo SSL come integrazione al protocollo di rete TCP/IP dentro Windows.
Lo standard definitivo non esiste ancora, l'analisi di questo protocollo procede per trovare la miglior configurazione di tutte le opzioni.
Analizzeremo il Secure HyperText Transfer Protocol (versione 1.2) che è un estensione dell' HyperText Transfer Protocol (HTTP), protocollo di base del World Wide Web. S-HTTP è stato progettato da E. Rescorla e A. Schiffman della EIT (Enterprise Integrated Technologic Inc.) per realizzare connessioni HTTP sicure. S-HTTP fornisce servizi sicuri applicabili per:
Il protocollo lascia massima flessibilità nella scelta
dei meccanismi di gestione della chiave, politiche di sicurezza
e algoritmi di crittografia e supporta opzioni di negoziazione
fra le parti per ogni transazione. Non è richiesta
la chiave pubblica per il client. SHTTP contiene HTTP, poichè
permette ai messaggi di essere incapsulati in vari modi. L'incapsulazione
può essere ricorsiva e il messaggio può subire diverse
trasformazioni. SHTTP fornisce inoltre linee di testa per funzioni
di gestione amministrativa come trasferimento delle chiavi e dei
certificati.
La World Wide Web (WWW) è un sistema ipermediale distribuito
che ha acquistato vasto successo fra gli utenti di Internet. Il
protocollo di applicazione del WWW client/server è l'HTTP.
Alcune applicazioni di WWW richiedono la capacità di autenticare
ogni scambio fra client e server. In questa direzione l'HTTP,
non supporta appropriati meccanismi di crittografia. L' SHTTP
fornisce meccanismi di comunicazione sicura fra la coppia client/server
di HTTP utile per le operazioni commerciali e altre applicazioni
su rete. E' disegnato per coesistere con messaggi HTTP e per essere
facilmente integrato con le applicazioni HTTP. SHTTP fornisce
una serie di meccanismi di sicurezza ai client e ai server HTTP,
fornendo una gamma di potenziali caratteristiche che coprono tutte
le possibili applicazioni sul World-Wide-Web.
4.2 Caratteristiche principali.
Vediamo le caratteristiche principali dei meccanismi di sicurezza dell'SHTTP. Il protocollo fornisce capacità simmetriche al client e al server (stesso trattamento in richiesta e risposta) mentre mantiene il modello di implementazione dell'HTTP. SHTTP contiene dei formati standard di crittografia, in particolare: PKCS-7 e MOSS. PKCS-7 è un formato di incapsulazione di messaggi crittografati, definito dai laboratori RSA. E' preferito agli altri modi di crittografia permessi dal SHTTP per la vasta possibilità di negoziazione delle opzioni. PKCS-7 è definito con la notazione ASN.1 dell' OSI come una sequenza di sei tipi diversi combinabili fra di loro:
SHTTP non richiede per il client la certificazione della chiave
(o la chiave pubblica). Questo è importante perchè
significa che le transazioni private possono avvenire senza che
gli utenti abbiano stabilito chiavi pubbliche. SHTTP fornisce
transazioni sicure end-to-end, al contrario dell'HTTP nel quale
i meccanismi di autorizzazione avvengono quando il client tenta
l'accesso e gli viene negato. Nel SHTTP pochi dati sono trasmessi
in chiaro sulla rete. Fornisce piena flessibilità degli
algoritmi di crittografia, modelli e parametri. La negoziazione
delle opzioni è usata per permettere al client e al server
di accordarsi su come far avvenire le transazioni (ad es. se è
necessaria la firma, la cifratura del messaggio o entrambi), e sugli algoritmi
di crittografia da usare (RSA o DSA per la firma, DES o RC2 per la crittografia,
di cui si danno maggiori informazioni nell'appendice).
La creazione di un messaggio SHTTP è composta da tre elementi:
Per creare il messaggio SHTTP, il mittente integra le preferenze del mittente e del destinatario. Il risultato di questa integrazione è una serie di miglioramenti della sicurezza da applicare ai messaggi e alle chiavi.
Il recupero dei messaggi in SHTTP può essere pensato come una funzione che riceve in input:
Per recuperare il messaggio il destinatario legge le testate per
vedere quali trasformazioni sono state fatte al messaggio, poi
toglie le trasformazioni usando il materiale che riguarda le preferenze,
tenendo conto di quali miglioramenti erano stati applicati.
4.3.1 Modi di operare del SHTTP.
La protezione dei messaggi può avvenire in tre modi: firma, autenticazione e crittografia. Per ogni messaggio può essere possibile la firma, l'autenticazione, la crittografia o una combinazione di questi tre modi.
L'autenticazione è realizzata mediante la testata Content-MAC-Info: per verificare l'autenticità del messaggio spedito e indirettamente la sua integrità, SHTTP fornisce il calcolo del Message Authentication Code (MAC), un calcolo basato su funzioni hash. Questo meccanismo è anche utile per la non ripudiabilità delle transazioni.
Vediamo come operano la crittografia e la firma: possono essere fatte attraverso la testata di Content-Privacy-Domain. Ad esempio se si considera per 'Privacy-Domain' il valore PKCS-7, la sicurezza mediante crittografia opera come una 'busta' sotto PKSC-7. Viene cifrato il contenuto usando un sistema DEK con le informazioni sulla chiave specificate nella linea di testa 'Prearranged-Key-Info'. Quando occorre la firma si usa l'opzione 'SignedData' oppure 'SignedAndEnvelopedData'. In caso di firma, una certificazione appropriata deve essere unita al messaggio oppure mandata indipendentemente al mittente. Per generare i dati cifrati e firmati occorre generare prima una firma con 'SignedData' e poi cifrare i dati con 'EncryptedData', poichè il PKCS-7 non supporta una modalità per cifrare e firmare i dati contemporaneamente.
Sono realizzati meccanismi di gestione di chiavi multiple e la
possibilità di mandare messaggi confidenziali a utenti
che non posseggono coppie di chiavi pubblica/privata. Infatti
SHTTP definisce due modi di trasferimento della chiave: uno usando
la chiave pubblica del destinatario; nel secondo modo si cifra
il contenuto usando una chiave transitoria, le cui informazioni
sono specificate in una linea di testa.
4.4 Formato del messaggio SHTTP.
La sintassi di un messaggio SHTTP è conforme a quella di un messaggio HTTP, questo per incrementare l'integrazione di sistemi che usano HTTP. SHTTP infatti sfrutta alcune linee di testa dell'HTTP che sono legate alla sicurezza. Il messaggio SHTTP, che sostituisce il messaggio HTTP, è composto da una linea di richiesta, o di stato, seguita da una testata secondo le specifiche RFC-822 e infine un contenuto incapsulato che può essere un messaggio SHTTP, o HTTP, o dati. Per linea di richiesta si intende una richiesta sicura trattata con SHTTP: il client dovrà indicare di voler usare il protocollo SHTTP sostituendo alla linea che indica il protocollo HTTP la linea Secure *Secure-HTTP/1.2. Allo stesso modo il server risponderà con la linea di stato: Secure-HTTP/1.1 200 OK sia che la richiesta abbia successo sia che la richiesta fallisca, per impedire eventuali analisi dei risultati per ogni richiesta.
Si definiscono una serie di nuove linee di testa per SHTTP. Di queste linee solo Content-Privacy-Domain e Content-Type sono obbligatorie mentre le altre sono opzionali. Oltre a queste linee ci sono le linee di testata dell'HTTP che vengono incapsulate dentro il messaggio SHTTP. Il corpo del messaggio è separato dalla testata da due ritorni a capo. Analizziamo alcuni campi della testata:
4.4.1 Il contenuto del messaggio.
Il contenuto del messaggio dipende molto dai valori dei campi del Content-Privacy-Domain e del Content-Transfer-Encoding.
Se Content-Privacy-Domain=PKCS-7 e Transfer-Encoding=8BIT, il contenuto è il messaggio.
Se Content-Privacy-Domain=PKCS-7 e Transfer-Encoding=BASE64, il contenuto è preceduto da una linea:
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
e seguito da una linea:
-----END PRIVACY-ENHANCED MESSAGE-----
con il contenuto in una rappresentazione in blocchi di 64 bit: ciò significa che l'alfabeto di sostituzione utilizzato lavora su blocchi di 8 caratteri contemporaneamente, escludendo così attacchi basati sulla frequenza.
Se Content-Privacy-Domain=MOSS, il contenuto è descritto in RFC1847.
Se i miglioramenti della sicurezza sono rimossi ci aspettiamo
di ritrovare una normale richiesta HTTP. Inoltre, se il contenuto
è un altro messaggio S-HTTP, ciò si può vedere
come una serie di 'buste' in cui inserire il messaggio. Tolte
poi tutte le buste, il contenuto finale sarà una richiesta
(o una risposta) in HTTP. Oltre alle linee dell'SHTTP altre linee
di testata dell'HTTP sono mantenute con lo stesso significato
che avevano nel HTTP.
Il client e il server negoziano quali miglioramenti vogliono usare, non usare o richiedere obbligatoriamente in riferimento alle preferenze crittografiche. La negoziazione di queste opzioni può avvenire in due posizioni:
La negoziazione si riferisce sia alle preferenze crittografiche, che alle opzioni sulle chiavi da usare per migliorare la sicurezza del messaggio. Durante la negoziazione entrambe le parti esprimono le loro preferenze e richieste riguardo ai miglioramenti da adottare. La scelta finale dipenderà dalle capacità implementate nel client e nel server e dalla particolare applicazione richiesta. Un blocco di negoziazione delle opzioni è una sequenza di specifiche che possono essere divise in quattro parti:
Consideriamo ad esempio la testata di negoziazione:
SHTTP-Symmetric-Content-Algorithms: recv-optional=DES-CBC,RC4
può essere letto come: ' puoi usare DES-CBC o RC4 per cifrare'.
Il formato generale per le linee di testa usate nella negoziazione considera separatamente il mittente e la destinazione. Per il ricevente, ad esempio l'opzione 'recv-optional' indica che i miglioramenti della sicurezza saranno applicati, ma, i messaggi senza sicurezza saranno processati lo stesso. In caso di opzione 'recv-required' non saranno processati messaggi senza i meccanismi di sicurezza. Infine con l'opzione 'recv-refused' non saranno processati i messaggi con meccanismi di sicurezza. Per l'origine l'opzione 'orig-optional' significa che se incontra una destinazione che rifiuta la sicurezza, l'origine non metterà in atto meccanismi di sicurezza. Nel caso di 'orig-required' l'origine genererà sempre meccanismi di sicurezza al contrario di 'orig-refused' dove l'origine non genera mai meccanismi di sicurezza. Nel caso di comunicazione fra origine e destinazione di agenti incompatibili sarà a discrezione delle parti decidere se mantenere o meno la connessione.
Tutte le linee di testa descritte si riferiscono al formato di un messaggio, nel caso di più messaggi devono essere ripetute per ogni messaggio. Consideriamo alcune linee di testa riferite alla negoziazione fra le parti.
SHTTP-Privacy-Domains: orig-required=pkcs-7; recv-optional=pkcs-7,MOSS
Indica che le parti generano messaggi in PKCS-7 e possono leggere messaggi in PKCS-7 o MOSS. L'ordine indica la priorità delle preferenze, cioè in ricezione si preferisce messaggi cifrati in PKCS-7 che in MOSS.
SHTTP-Certificate-Types: recv-optional=X.509; orig-required=X.509.
Questo indica quale tipo di certificazione di chiave pubblica è considerata valida. I valori accettabili sono 'X.509' e X.509v3.
SHTTP-Key-Exchange-Algorithms: recv-required=RSA; orig-optional=Inband,RSA.
Questa linea indica quale algoritmo può essere usato per lo scambio delle chiavi. Valori possibili sono: 'RSA' , 'Outband', 'Inband' o Krb[4|5]. RSA si riferisce al sistema sviluppato dai laboratori dell'RSA. Outband riguarda una specie di accordo su valori esterni presenti ad esempio in una base di dati. Inband realizza una assegnazione diretta della chiave ad un nome simbolico. Kerberos funziona usando il sistema granting-ticket: l'utente che vuole accedere richiede al server Kerberos di autenticazione la concessione di un ticket per l'accesso. Il server, verificato nel proprio database che il ticket richiesto e l'autenticazione ottenibile dall'utente corrispondano, concede il servizio richiesto.
SHTTP-Signature-Algorithms: orig-required=RSA; recv-required=RSA
Questo indica i tipi di algoritmi di firma digitale che possono essere usati. I valori permessi sono : 'RSA' e 'NIST-DSS'.
SHTTP-Privacy-Enhancements: orig-required=sign
orig-optional=encrypt
Questa testata indica i miglioramenti alla sicurezza da applicare. Valori possibili sono 'sign', encrypt' e 'auth' o combinazioni di questi che indicano se il messaggio deve essere firmato, cifrato o autenticato.
Oltre alle linee di testa prima descritte, ne esistono altre che
non abbiamo considerato, per brevità e per non appesantire
troppo il testo. Riguardo alla negoziazione, esistono dei valori
di default per i parametri della testata. I valori di default
sono:
recv-optional=PKCS-7, MOSS
recv-optional=X.509
recv-optional=RSA,Inband
recv-optional=RSA
recv-optional=RSA-MD5
recv-optional=DES-CBC
recv-optional=DES-ECB
recv-required=encrypt; recv-optional=sign, auth recv-optional=X.509
Da inserire insieme a queste linee di negoziazione ci sono
anche altre linee di testata che si riferiscono a parametri non
negoziabili. Alcune di queste linee sono: Certificate-Info
che permette al mittente di mandare la certificazione della chiave
pubblica usata in un messaggio; Key-Assign, rappresenta
il messaggio usato per lo scambio della chiave: in questa linea
viene associato un nome simbolico alla chiave. Un server può
legare un gruppo di linee di testata per la negoziazione in un
link HTML attraverso una singola linea di testata S-HTTP chiamata
Cryptopts. Oltre alle linee di testa non negoziabili dell'SHTTP
esistono anche due linee dell'HTTP: Security-Scheme e
Nonce-Echo. Security-Scheme deve essere presente
nel messaggio HTTP generato e indica il protocollo e la versione
usata.Valore permesso: 'S-HTTP/1.2'.
Ci sono vari problemi se il client e il server non supportano SHTTP o se supportano versioni diverse.Se un server riceve una richiesta in chiaro che doveva essere cifrata, il server risponde con un errore: 'SecurityRetry 420' e nelle linee di testa della risposta indica i miglioramenti alla riservatezza richiesti.
Oltre alle modifiche ora viste, per migliorare la sicurezza occorre creare delle estensioni per l'HyperText Markup Language (HTML) e per l'Universal Resource Locators (URL) poichè è necessario rendere sicuri i collegamenti (hyperlinks). Per l'uso del protocollo SHTTP occore definire un nuovo URL 'shttp', l'uso di questo nuovo URL permette di sfruttare le capacità dell' SHTTP.
Mentre prepariamo un messaggio sicuro, il browser dovrebbe visualizzare
lo stato di transazione sicura, cosi come quando si legge una
firma o un messaggio cifrato il browser dovrebbe indicare da dove
proviene il messaggio (l'identità di chi firma). Errori
di autenticazione o di decifratura in un messaggio SHTTP dovrebbero
essere indicati in modo diverso da un semplice errore.
Consideriamo alcuni esempi di uso di SHTTP. Se una società ha una pagina con il listino prezzi in modo che i compratori possano controllare gli attuali prezzi, questa pagina può essere spedita senza necessit€ di sicurezza poiché è uguale per tutti i clienti. Il server potrebbe voler firmare il documento per assicurare i clienti della veridicità dell'offerta. Per maggior sicurezza, il server può autenticare il messaggio per prevenire variazioni del documento volontarie o accidentali. Se un cliente decide di fare un acquisto con un ordine, si può richiedere la cifratura del messaggio ma non la firma del cliente. In questo caso, il client genera una chiave transitoria in modo casuale per cifrare la richiesta. Poi il client sceglie la chiave pubblica del server (se ne esiste più di una) per cifrare la chiave transitoria generata. Infine la chiave transitoria e il messaggio cifrato di richiesta sono mandati al server. Quando il server decifra la chiave transitoria e la richiesta, può rispondere alla richiesta. Il server può decidere di cifrare e firmare la conferma dell'ordine fatto attraverso la linea:
Privacy-Enhancements: sign, encrit.
Consideriamo una serie di richieste e risposte in SHTTP. Usando un client con capacità SHTTP si può fare una richiesta HTTP ad un server che restituisce un messaggio di risposta con informazioni sulla certificazione, i miglioramenti alla privacy richiesti e il link al messaggio SHTTP da proteggere, ad esempio: shttp://www.setec.com/secret. Per raggiungere questo messaggio "secret" si usa una richiesta HTTP della forma:
GET /secret HTTP/1.0
Security-Scheme: S-HTTP/1.2
User-Agent: Web-O-Vision 1.2beta
Accept: *.*
Key-Assign: Inband,1,reply,des-ecb;7878787878787878
Con l'aggiunta del Key-Assign il server può cifrare il
messaggio di risposta anche se non c'è una chiave pubblica.
La richiesta prima vista viene incapsulata in un messaggio SHTTP:
Secure * Secure-HTTP/1.1
Content-Transfer-Encoding: base64
Content-Type: application/http
Content-Privacy-Domain: PKCS-7
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
............................................ BXBVlsAhKkkusk1kCf/GbXSAphdSgG+d6LxrNZwHbBFOX6A2hYS63Iczd5bOVDDW Op2gcgUtMJq6k2LFrs4L7HHqRPPlqNJ6j5mFP4xkzOCNIQynpD1rV6EECMIk/T7k 1JLSAAAAAAAAAAAAAA==
-----END PRIVACY-ENHANCED MESSAGE-----
Il messaggio compreso fra i delimitatori è un messaggio
di PKCS-7 cifrato secondo RSA. Al ricevimento della richiesta,
il server decifra il messaggio, cerca il documento richiesto ed
è pronto per la risposta. Una risposta del server in HTTP
potrebbe essere:
HTTP/1.0 200 OK
Security-Scheme: S-HTTP/1.2
Content-Type: text/html
Messaggio riservato in:
< A href=" ./ segreto.html "
CRYPTOPTS="Key-Assign : Inband, alice1, reply, des-ecb ; 020406080a0c0e0f ;
SHTTP-Privacy-Enhancements : recv-required=auth">
questa pagina <\A>
Questo messaggio HTTP viene incapsulato come un messaggio SHTTP assumendo la forma:
Secure * Secure-HTTP/1.1
Content-Transfer-Encoding: base64
Content-Type: application/http
Prearranged-Key-Info: des-ecb,697fa820df8a6e53,inband:1
Content-Privacy-Domain: PKCS-7
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
............................................. 5RH4MuJRajDmoEjlrNcnGl/BdHAd2JaCo6uZWGcnGAgVJ/TVfSVSwN5nlCK87tXl nL7DJwaPRYwxb3mnPKNq7ATiJPf5u162MbwxrddmiE7e3sST7naSN+GS0ateY5X7 AAAAAAAAAAA=
-----END PRIVACY-ENHANCED MESSAGE-----
Fra i delimitatori è posto il messaggio PKCS-7 cifrato con la scelta casuale DEK, che può essere decifrato attraverso:
DES-DECRYPT(inband:1,697fa820df8a6e53)
dove 'inband:1' è la chiave scambiata nella linea di Key-Assign della richiesta iniziale. Consideriamo ora, un altro esempio in cui il miglioramento richiesto è l'autenticazione del messaggio. Continuando l'esempio precedente, supponiamo che l'utente voglia accedere alla pagina HTML; per fare questo si crea un messaggio HTTP (secondo lo standard HTTP):
GET /segreto.html HTTP/1.0
Security-Scheme: S-HTTP/1.2
User-Agent: Web-O-Vision 1.1beta
Accept: *.*
Questo messaggio viene incapsulato in un messaggio SHTTP, e diventa:
Secure * Secure-HTTP/1.2
Content-Transfer-Encoding: base64
Content-Type: application/http
MAC-Info:2ffc120b,rsa-md5,1425a951f1bbf3bd8d6dc7d07ab731bb,inband:alice1
Content-Privacy-Domain: PKCS-7
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
MIAGCSqGSIb3DQEHAYBjR0VUIC9wcml6ZS5odG1sIEhUVFAvMS4wClNlY3VyaXR5 LVNjaGVtZTogUy1IVFRQLzEuMQpVc2VyLUFnZW50OiBXZWItTy1WaXNpb24gMS4x YmV0YQpBY2NlcHQ6ICouKgoKAAA=
-----END PRIVACY-ENHANCED MESSAGE-----
I dati fra i delimitatori sono la rappresentazione della richiesta.
- Documento draft del mese di Maggio '96 sulle specifiche di SHTTP: ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-03.txt .
-ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-02.txt .
- Informazioni della EIT sul progetto Secure HTTP : http://www.eit.com/projects/s-http/
Implementazioni disponibili:
- E' disponibile SafetyWEB, della Spry Inc., all'indirizzo http://www.spry.com .
- Secure HTTP e SSL Toolkit commercializzato da Terisa: "http://www.terisa.com/prod/prod.html"
- Versioni dei Web server sicuri di IBM per le maggiori piattaforme:
http://www.ics.raleigh.ibm.com/
.
Links utili su SHTTP e crittografia:
- Secure HTTP: Safe Transactions for the World-Wide-Web: presentazione all'Interop '94 di Allan Schiffman. http://www.eit.com/presentations/shttp-ams/index.html
- Notizie sulla sicurezza su Internet: "http://www.netsurf.com/nsf/v01/01/nsf.01.01.html"
- W3C, World Wide Web Consortium: http://www.w3.org/hypertext/WWW/Consortium/Prospectus/Overview.html
- Netscape Communications Corp.: http://home.netscape.com
- EIT; http://www.eit.com (Enterprise Integrated Technologic Inc.).
- IETF; http://www.ietf.org/ .
- Links sui temi della sicurezza e crittografia: http://www.zurich.ibm.ch/Technology/Security/sirene/outsideworld/security.html
- Informazioni della Spry C. su Internet Security: http://server.spry.com/secure.htm
- WWW Frequently Asked Question: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html .
- Requisiti per un protocollo di trasferimento sicuro: http://www-ns.rutgers.edu/www-security/sdtp-req/draft-sdtp-requirements-00.txt
- Security Extensions per HTML: ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shtml-01.txt
- Netscape security page: http://home.mcom.com/info/security-doc.html.
- Pagine del W3C Working Group sui sistemi di pagamento: http://www.w3.org/pub/WWW/Payments/
- Indice dei documenti Internet-Drafts correnti: http://www.ietf.cnri.reston.va.us/1id-abstracts.html
- Indice degli RFCs: http://ds.internic.net/ds/dspg1intdoc.html
- FAQ e Newsgroups sulla sicurezza: http://theory.lcs.mit.edu/~rivest/crypto-security.html#NewsGroups http://rschp2.anu.edu.au:8080/cipher.html.
- ftp.funet.fi:/pub/crypt/hash/mds/md5
- ftp.funet.fi:/pub/crypt/hash/sha
- Kerberos: disponibile al sito ftp.funet.fi:/pub/unix/security/login/kerberos
(incluso Kerberos5).