Newsgroup: it.comp.os.linux.sys
Titolo: GPG - Info veloce

Ciao a tutti.
Ho creato una coppia di chiavi (pubblica e privata) per fare alcuni
test.
La pubblica se ho ben capito mi serve per poter cifrare i messaggi,
quindi posso darla a cani e porci. La privata, invece, mi serve per
decifrare i messaggi e la devo tenere al sicuro.
Però, sapete dirmi come fare il dump della chiave privata?
Non so dove viene salvata e dovrei portarmela dietro su chiavetta o
comunque trasferirla a chi di dovere. Inoltre, se proteggessi la
chiave privata con una password da 32 caratteri completamente random
(come l'md5 fatto sul timestamp) potrei stare comunque abbastanza al
sicuro anche nel caso trasmettessi questa chiave via mail? (senza
ovviamente trasmettere anche la password)
Non so se esistono dei bruteforce validi, inoltre ho impostato 7
giorni di validità della chiave, pertanto la compromissione di chiave
+ password dovrebbe avvenire entro 7 giorni.
E' abbastanza sicuro come metodo?

 E' abbastanza sicuro come metodo?
Perche' dovresti trasferirla a qualcun altro?
Si`, credo potrebbe andare, purche' la passphrase non sia facilmente
ricavabile da dati del file della chiave (
p.es
. l'md5 del file non
sarebbe una buona idea) e poi comunque per maggior sicurezza
comprimerei il file mettendoci una password. Il che vuol dire che dopo
7 giorni non la vuoi/puoi piu` utilizzare? Pero` comunque continuo a
non riuscire a capire il razionale di tutto cio`. Normalmente la
chiave (pubblica) si mette su un keyserver.
Andrea

 + password dovrebbe avvenire entro 7 giorni.
Alla scadenza delle chiave questa mica si "autodistrugge" eh...
La scadenza serve solo per indicare in che lasso di tempo la chiave e
valida (questo serve più che altro per quanto riguarda la firma
digitale) una volta superata tutto quello che avrai sarà un warning di
PGP che ti avvertirà che la chiave è scaduta ma questo non toglie il
fatto che potrà benissimo essere ancora usata per decrittare i
messaggi (stessa cosa per le chiavi revocate sui keyserver, il fatto
che sia revocata non implica che possa essere ancora usata. Ti
notifica solo che "non è più valida/non è più fidata").
Ciao
Aandrea

 Esatto.
Grazie.
Meno male che avevo messo le mani avanti.
Penso di aver detto principalmente delle stupidaggini, ma comunque
credo sarebbe bene garantire anche l'autenticita` del messaggio
cifrato, in modo che il destinatario possa verificare che chi dice di
essere il mittente effettivamente lo sia e per questo dovrebbe essere
opportuno che il mittente firmasse (con chiave privata, no?) il
messaggio cifrato.
Andrea

 pubblica.
Io ho la necessità di cifrare, su un mio server, alcune stringe senza
possibilità che un malintenzionato sia in grado di leggerle.
Pensavo quindi di far generare al server, per ciascun cliente, una
coppia di chiavi. La chiave pubblica se la tiene il mio server e la
userà
per cifrare le successive comunicazioni, la chiave privata, invece,
sarà protetta da una password completamente random (caratteracci
lettere grandi, piccole, simboli, senza alcun criterio di
generazione).
La chiave segreta (protetta) sarà inviata al cliente tramite mail,
magari
su una casella creata appositamente il cui accesso si può fare solo
tramite protocolli sicuri, mentre la password per l'utilizzo della
chiave
segreta sarà inviata tramite raccomandata con ricevuta di ritorno.
L'utente quindi farà l'accesso ad un pannello via web protetto con
HTTPS
e certificato rilasciato da verisign, con username/password (che non
han
niente a che vedere con le chiavi di cui sopra) ed al momento di
decifrare
la stringa, dovrà inserire (copia/incolla) la chiave segreta in una
apposita
form e successivamente inserire a mano la password ricevuta tramite
raccomandata.
Dovrebbe essere sicuro come metodo. Un malintenzionato, se bucasse il
software, non vedrebbe altro che la stringa cifrata e la rispettiva
chiave
pubblica, ma non potrebbe farci nulla.
Se dovesse intercettare la mail (quasi impossibile perchè oltre a
transitare tramite
SSL la casella sarà creata quasi sicuramente sul server locale quindi
non
transiterebbe via internet tra server e server) avrebbe la chiave
segreta
utile per la decifratura, ma non avrebbe la chiave.
L'unica combinazione possibile per decifrare la stringa sarebbe:
- ottenere username e password di accesso al pannello
- ottenere la stringa cifrata e la chiave pubblica
- ottenere la chiave privata
- ottenere la password
- farlo entro 7 giorni dalla generazione delle chiavi, perchè dopo 7
giorni elimino tutto,
sia dal database, sia dal keyring sul server, invalidando chiave
pubblica, privata e password.
Oppure, dovrebbe avere accesso all'interno server, cosa difficile
perchè si accede solo tramite
certificati con password e solo da un mio ip e monitorare i comandi
eseguiti dal server per
l'esecuzione di gpg necessari a decriptare la stringa.
Mi pare un qualche cosa di inverosimile da attuare....
Il mio problema ora è:
come trasmetto la chiave segreta al cliente in un formato ASCII?
E viceversa, posso far usare una chiave segreta in formato ascii per
decriptare una stringa senza dover
obbligatoriamente salvare il tutto nel keyring?
Avrei bisogno di qualche cosa a linea di comando, tipo:
cat stringa_criptata | gpg -d < chiave_segreta_ascii
se po fa?

 Però, sapete dirmi come fare il dump della chiave privata?
  Scusa?  Chiave privata in gpg?  gpg usa una passphrase, che non è
salvata da nessuna parte.  Te la devi custodire tu, è come le password
dei vari servizi di autenticazione che usi sui server.  Non è che ti
stai confondendo con ssh-keygen o con openssl?  Loro si che generano e
gestiscono chiavi private e pubbliche DSA e RSA.
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 possibilità che un malintenzionato sia in grado di leggerle.
Perchè non provi a utilizzare una tecnica di secret sharing?
Il server si tiene una chiave, il client ne ha un'altra e solo con tutte 
e due contemporaneamente riesci a decifrare le stringhe.
Però forse non ho capito bene il tuo problema...
-- 
"Mai sottostimare la larghezza di banda di un camioncino che sfreccia a
razzo sull'autostrada" 
Andrew S. Tanenbaum
python -c "print 'bG9ybWF5bmFAZ21haWwuY29t'.decode('base64')"

 gestiscono chiavi private e pubbliche DSA e RSA.
http://it.wikipedia.org/wiki/GNU_Privacy_Guard
gpg usa una coppia di chiavi per cifrare e decifrare i messaggi, e,
volendo,
queste chiavi possono essere protette tramite passphrase per una
maggiore
sicurezza.

 Però forse non ho capito bene il tuo problema...
Ho un applicativo PHP che deve salvare dei dati cifrati in maniera
estremamente sicura.
In caso di compromissione del server, dello script php o di qualsiasi
altra cosa, i dati
cifrati devono essere inutilizzabili.
Parallelamente, alcune persone devono accedere a questi dati e poterli
decifrare, mediante
una loro chiave, sempre tramite il sito in php.
Per questo pensavo di cifrare tutto lato php, generare una chiave,
consegnarla al cliente tramite
posta elettronica in maniera pseudo-sicura e consegnare la passphrase
per l'utilizzo di tale
chiave privata tramite raccomandata cartacea.
L'utente si collega al sito, inserisce la sua chiave segreta,
inserisce la passphrase e visualizza
i dati.
Non mi vengono in mente altre idee per poter cifrare e decifrare i
dati senza tenere sul server una
chiave che vada bene per entrambe le operazioni. Banalmente, una
cifratura a chiave sincrona non
va bene, perchè se mi bucano il server mi prendono anche la chiave che
decifra.

 salvata da nessuna parte. 
Eh?
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 decifra.
Quanto a quello, se ti bucano il server e sono appena-appena furbi,
intercettano la passphrase e ti inchiappettano lo stesso...


 cifrati devono essere inutilizzabili
In passato ho avuto a che fare con un problema simile (carte di credito) 
e ho utilizzato uno schema come quello che ti dicevo (http://
en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
 oppure 
http://tinyurl.com/
y2onppj).
L'applicazione con cui avevo a che fare distribuiva le chiavi su vari 
server, ma nulla ti vieta di distribuirne una anche ad un client.


 gestiscono chiavi private e pubbliche DSA e RSA.
E secondo te come funziona il sistema della chiave pubblica/privata con
gpg ?
Comunque la passphrase serve solo per leggere la chiave privata salvata
su computer. In teoria potresti anche tenere salvta in chiaro la chiave
privata e non dover usare nessuna passphrase.

 Del tipo?
ssss
Ma non penso sia adatto al tuo caso.
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 su computer. 
Se vogliamo essere proprio dei temperacazzi, gpg supporta sia crittografia
simmetrica che asimmetrica, quindi la passphrase può essere quella di
protezione della propria chiave privata, ma può anche essere la chiave per
una crittografia come AES.
Es.
gpg -c  < infile > outfile


 
Temperiamo, temperiamo.
E gi� che ci siamo: quando crittografiamo NON vuol dire sempre e solo
che applichiamo RSA all'input, ma solo alla chiave dell'algoritmo
simmetrico che effettivamente ha cifrato il messaggio.
E quando firmiamo, in realt� cifriamo (con la nostra privata) l'hash
(MD5, SHA1) del messaggio. Cos� il destinatario con la nostra chiave
pubblica pu� riottenere l'hash calcolato dal mittente.

 decifra.
Riassumendo.. se ho capito bene
Diciamo che i dati vengono caricati in MySQL attraverso 
AES_ENCRYPT()/AES_DENCRYPT() o simili.. (cifratura con algoritmo 
simmetrico a 128 bit)
e qui si pone il problema di come passare la key_str per 
cifrare/decifrare il tutto.
poi vorresti far connettere gli utenti attraverso un certificato PKCS#12 
e fin qui.. anche se a sto punto tanto varrebbe utilizzare una smart card.
ora, il problema pi� evidente � che se l'utente deve conoscere una pass* 
di qualche tipo dovrai comunque passarla attraverso una form dal client 
al server il ch� rende l'intercettazione piuttosto banale in caso di 
server compromesso, il ch� � anche inutile visto che gi� all'atto della 
connessione si entra in possesso del certificato client che per 
l'appunto ci certifica l'identit� dell'utente (nel caso di smart-card).
l'unica soluzione ovvia sarebbe quella di offuscare il codice PHP 
impedendo che un eventuale attaccante possa accedere alla key_str 
utilizzata da AES_ENCRYPT()/AES_DENCRYPT() evitando di scrivere 
minchiate con include/fopen ecc...
Ovviamente v� studiata una politica di accessi decente

   No.  Per criptare e/o firmare dati o messaggi usi la tua passphrase,
Veramente la passphrase consente di accedere alla chiave privata...

 l'appunto ci certifica l'identit dell'utente (nel caso di smart-card).
Si ma bucare un server ed ottenere accesso shell è di qualche ordine
di grandezza più difficile che bucare uno script php tramite qualche
sql injection e cose simili.
se mi bucano il server, cazzi del cliente. Io però ho bisogno di
sapere
che, sulla carta, il metodo ipotizzato sia sicuro. In pratica, non
posso fare
un sistema che è sbagliato sin dalle fondamenta.
In parole povere, supponiamo di avere 10 utenti diversi.
Per ciascuno di questi 10 utenti, il server deve salvare dei dati in
maniera
criptata. Preferirei fare 1 chiave per ciascun utente.
Poi, ciascun utente, inserendo la sua chiave e la SUA passphrase (che
saranno
generate inizialmente dal mio server) potrà decrittare la stringa.
Se ci dovesse essere qualche sql injection, una banale SELECT
ritornerà i dati
crittati, e non essendoci la chiave necessaria a decrittarli, i dati
sarebbero inutilizzabili.
Resta solo l'ipotesi di hackeraggio brutale del server, in cui un
utente prende ed entra.
In tal caso, come giustamente dice Skull, mezzo secondo e ti loggano
il traffico.
Questa casistica, però, è assai improbabile che si verifichi, perchè
ssh sarà protetto
da certificati con rispettiva password ed accesso solo da LAN locale,
pertanto dovrebbero
entrare sfruttando una qualche vulnerabilità bella grossa di PHP o
Apache, e se ne vedono
sempre meno oggigiorno.
So di non poter progettare un sistema sicuro al 100%, ma non è nemmeno
il mio obiettivo.
Devo però tutelarmi sostanzialmente da bug nel codice PHP, in cui
eventuali injection che
dovessero ritornar fuori tutti i record del database non rendano
visibili ed utilizzabili le chiavi
di decifratura.
Per questo motivo, scarto a priori una sharedkey, che dovrebbe essere
salvata sul server, pertanto,
php con codice criptato oppure no, avrebbe la chiave bella visibile
una volta in esecuzione, e basterebbe
un bug del cappero per renderla visibile.
Come suggerite di procedere? Anche altre alternative a GPG andrebbero
bene, anzi, se ci fosse qualche
cosa di integrato in php sarebbe meglio. L'importante è che sul server
non ci sia salvato nulla che possa
permettere la decifratura delle stringhe.

 di decifratura.
e' qui che ti perdi... in caso di sql-injection i dati sono già in 
chiaro sennò l'utente come farebbe a leggerli?
Ammenoché non ti inventi il modo di trasferire i dati cifrati da server 
a client e successivamente decrittarli tramite un javascript o un applet 
ma francamente qui si rischia di entrare nel ridicolo..

 o che sia archiviata in un HSM, idem se parliamo di "FILE".
Ma chi l'ha detto che devo salvare i dati in chiaro?
Io non ci devo fare nulla con questi dati, li devo giusto salvare.
non mi serviranno mai in chiaro.
Quindi, banalmente, potrei fare una tabella mysql con due colonne:
ID | Stringa
Dove ID è un autoincrement, Stringa è un campo BLOB che conterrà
tutta la stringa CIFRATA.
Una volta salvata, non me ne può fregar di meno del contenuto,
l'importante
è che in caso di injection, tale stringa rimanga codificata, quindi
non posso
usare una chiave condivisa.
Dal momento che la stringa viene salvata codificata e che sul server è
presente la sola chiave pubblica dei miei clienti (quindi il server,
di suo,
non è in grado di decodificare nulla in nessun modo), il cliente,
quando
vuole leggere la stringa deve inserire prima la sua chiave privata,
poi la passphrase.
Può inserire entrambe tramite una form html che faccia il post ad una
pagina PHP.
Tutto il sito sarà su HTTPS pertanto non ci saranno problemi in caso
di intercettazioni,
il post viene fatto sul server stesso, quindi anche qui, a meno che
non ci sia un
malintenzionato che sia riuscito a bucare il server ed a mettersi in
ascolto, non ci
dovrebbero essere problemi.
Tali dati non saranno salvati in sessioni, quindi, teoricamente, sul
server non saranno
mai salvati nemmeno in file temporanei, ma sarà tutto in ram.
In pratica un qualche cosa di questo tipo:
- cliente fa il post di chiave + passphrase
- php esegue gpg o sistema analogo
- php spara fuori l'output e fa unset di tutte le variabili non
lasciando tracce.
Per quale motivo dovrei essere obbligato ad usare una secret key
condivisa ?
In tal caso cifrerei con AES ed il problema non sussisterebbe, ma io
NON voglio
usare una chiave da salvare sul server e che php deve sempre
conoscere.
(anche perchè non salvandola, non potrei nemmeno criptare i dati,
quindi php
ne dovrebbe essere sempre al corrente)

Tagliamo la testa al toro e ti illustro un sistema semplice e sicuro:
Una tabella con i dati crittati:
Tabella BLOB
BLOBID   : Identificativo
BLOBNAME : Nome del BLOB
BLOBVAL  : Stringa crittografata
BLOBHASH : Hash di controllo
Una tabella con gli utenti che possono accedere al sistema:
Tabella USER
USERID   : Identificativo
USERNAME : Username di accesso
USERPW   : Password
USERPUB  : Chiave pubblica dell'utente
Una tabella con le varie chiavi per decrittare il dato
Tabella KEYS
BLOBID   : Identificativo Blob
USERID   : Identificativo Utente
BLOBKEY  : Chiave crittata per decrittare il blob
Quando devi salvare un dato l'utente fa login con il proprio account, il
server genera una chiave di crittografia casuale (KEY) che tiene solo in
memoria, critta il dato con questa chiave mediante un algoritmo simmetrico
come AES, salva il dato crittografato nella tabella BLOB in BLOBVAL e l'hash
del dato in BLOBHASH. Poi con la chiave pubblica dell'utente (USERPUB)
critta la chiave precedentemente generata (KEY) e salva il dato crittato
nella tabella KEYS in BLOBKEY (ovviamente mettendo i corrispondenti
riferimenti USERID e BLOBID).
Se altri utenti devono essere in grado di decrittare quel dato (
p.es
. degli
operatori) non farai altro che creare altre triplette in KEYS per gli altri
utenti, crittando l'unica chiave simmetrica con le chiavi pubbliche dei vari
utenti.
In questo modo puoi anche avere un utente generico "SERVER" la cui chiave
GPG privata sta solo in cassaforte (e che ti serve per poter recuperare
eventuali dati in caso di necessitą).
Quando un utente vuole accedere al dato salvato, viene letto il record
BLOBKEY corrispondente al BLOBID e USERID dalla tabella KEYS, *lato*
*client* tale valore viene decrittato usando la chiave privata dell'utente e
passato al server che usa la chiave per decrittare il blob, verificando poi
l'hash per controllare che la chiave fosse giusta.


 l'hash per controllare che la chiave fosse giusta.
Ciò implica un qualche software sul pc del cliente.
Altrimenti, come faccio a decrittare lato client?
Nel mio caso è il server che deve decrittare, perchè il cliente
gli passa chiave e passphrase.
In pratica tu mi stai dicendo di crittare il dato sensibile con
AES, e proteggere la chiave necessaria a decrittare il dato
crittandola ulteriormente tramite la chiave pubblica del cliente.
Sistema perfetto, ma:
1) il cliente come genera una coppia di chiavi? Non posso tirare in
ballo
il cliente, deve fare tutto il mio software.
2) il cliente, come decritta la chiave AES? Deve avere un software
installato..
La verifica del hash di controllo, serve solo per avere la certezza
che il dato
decrittato sia fedele a quello originale giusto? E' solo un check per
assicurarsi
che tutto sia andato a buon fine, se ho ben capito.

 che tutto sia andato a buon fine, se ho ben capito.
Sì, e anche perché non hai modo di sapere se un dato decrittato con AES è
stato decrittato correttamente.


 Con Javascript.
P.es.
http://www.hanewin.net/encrypt/
http://www.mozilla.org/projects/security/


 pubblica o con semplice passphrase.
Forse abbiamo fatto confusione con i termini.
I miei utenti sono i clienti.
Ho questi passaggi:
visitatore del sito -> lascia dei dati -> server critta -> cliente
decritta
Per ovvi motivi il vistatore non può essere tirato in mezzo.
Va sul mio sito, scrive "ciao mondo", il server si inventa una chiave
AES da 32 caratteri,
e la usa per crittare la stringa messa dal visitatore.
E sarebbe finita qui, ma non voglio salvare la chiave AES.
Pertanto, devo crittarla come dici te. Per crittarla posso usare la
chiave pubblica
che mi ha fornito il cliente, ma torniamo punto a capo: il cliente
come si genera le
due chiavi senza doversi installare del software sul proprio computer?
Dubito che javascript faccia tutto per i fatti suoi, senza installare
nemmeno gpg
A meno che tu non stia parlando di un sistema che non ha nulla a che
fare con
gpg ma che ne ricalca solo il "modus operandi".
Ed in tal caso, conosci qualche libreria javascript per generare le
due chiavi?

 due chiavi?
Altro post.


 il file con le chiavi.
Ok, quindi l'utente si registra, il sistema (javascript) gli crea
automaticamente
due chiavi, una privata ed una pubblica.
La pubblica potrà finire in una form html in modo che premendo "Salva"
tale chiave
sarà automaticamente caricata sul mio server.
La privata, però, l'utente come se la salva? Dovrebbe salvarla sul
proprio computer,
e così facendo, potrebbe accedere ai dati criptati solo dal computer
avente la chiave
segreta.
A parte questo, in fase di lettura dovrei richiedere, sempre tramite
javascript in modo
tale che lo script sia eseguito dal browser, il fle con la chiave
segreta, e decifrare la
stringa crittata presente sul server.
Ho capito bene?
Devo solo trovare il modo di far salvare e leggere file da javascript.
AFAIK per motivi di sicurezza i browser han bloccato queste
possibilità.

 possibilit�.
In effetti questo � vero. Un sistema per ovviare comunque c'� di sicuro :-)


 ne dovrebbe essere sempre al corrente)
Ma và...

 Ma và...
Ma va nel senso di "si, la deve sapere"? allora non va bene.
Ma va nel senso di "no, non la deve sapere"? E allora come faccio a
crittare senza sapere la chiave
che andrò ad usare? Ne devo generare una random, ma la devo anche
comunicare al cliente quindi in
un modo o nell'altro, la soluzione è insicura.
La soluzione di zippo invece è perfetta, perchè è vero che mi serve
una chiave, ma io la salvo crittata
e non la comunico a nessuno.
Il cliente, invece, la prima volta che usa il software, accederà ad
una pagina full-javascript (che quindi
viene eseguita tutta dal suo browser) per generare una coppia di
chiavi. La pubblica sarà inserita in una
form e quindi inviata e salvata sul server, la privata sarà
visualizzata all'utente che dovrà fare copia-incolla
dove meglio crede.
Per sbloccare la chiave AES, il cliente accederà ad una seconda pagina
JS in cui dovrà inserire la sua
chiave privata (copia/incolla) e la stringa criptata (che sarà presa
dal mio server). Preme "decritta" ed il
javascript esegue il tutto.
Dato che le funzioni di decrittazione sono in javascript, la pressione
del bottone non invierà alcun dato
fuori dal computer pertanto io non saprò mai la chiave segreta.
Una volta premuto il tasto, sarà fatto un submit POST ad una pagina
sul server che userà tale stringa
per accedere ai dati crittati.
Il tutto protetto da HTTPS

 riferimenti USERID e BLOBID).
Stavo ripendando ad un po di cose.
Partendo dal presupposto che il pannello sarà protetto da SSL con tanto
di certificato rilasciato da autority (quindi niente certificati
self-signed, per quel che importa), potrei far generare una coppia di
chiavi pubblica/privata direttamente al server, il quale salverà solo
e soltanto la chiave pubblica, la privata la mostra a video e muore li.
Banalmente, uno pseudo-codice di questo tipo:
<?
list($public, $private) = makeRSAKeys();
saveDb($public);
echo $private;
unset($private);
?>
non ci sarebbe alcuna differenza rispetto al javascript. In entrambi i
casi il server non salverebbe nulla. L'unico rischio sarebbe quello di
aver loggato il traffico grazie ad uno sfondamento brutale di server, ma
se così dovesse essere, non c'è metodo che regga, l'attaccante
riuscirebbe ad ottenere sempre e comunque la stringa segreta.
Far generare una chiave segreta al client, per poi dover comunque
reinserire la passphrase AES sul server, oppure far generare una
chiave segreta al server senza salvarla mai, avrebbe lo stesso scopo.
Il punto debole sarà sempre e solo la comunicazione tra client e server
(e viceversa) una volta decrittata la stringa segreta.
Se ti sfondano il server, si salvano la stringa già decrittata, a
nessuno interesserebbe la chiave privata. se non ti sfondano il server,
non sarebbe possibile intercettare le comunicazioni perchè ci sarebbe
SSL a cifrare tra i due estremi.
dimentico qualche cosa?
-- 
Non tocca a noi dominare tutte le maree del mondo,
il nostro compito è di fare il possibile per la
salvezza degli anni nei quali viviamo,
sradicando il male dai campi che conosciamo.

 chiavi pubblica/privata direttamente al server
Ma è normale che la chiave privata inizi sempre con i soliti 7-8
caratteri?
Ogni volta che la genero, cambiano tutti i caratteri tranne i primi
7-8.
Cosa rappresentano? Utilizzo, per le prove, le funzioni openssl di php
che si
basano su openssl installato sul server. Non vorrei che generasse i
dati
partendo sempre da una base comune, rendendo meno sicura la chiave.
Inoltre, è normale che la chiave pubblica sia nettamente più corta
della chiave
privata? La privata, a 4096 bit sono tipo 20-30 righe, la pubblica
invece è circa 10
Non ho trovato *niente* che mi permetta di generare la chiave privata
lato php
in tempi umani, ci vogliono ore a calcolare i due numeri primi, mentre
invece per
la soluzione javascript, non ho trovato alcun modo per far salvare il
file direttamente
da browser, pertanto è stata bocciata a priori come soluzione.
Per il discorso che il cliente non si fida a lasciare la chiave
privata nelle mie mani
perchè potrei salvarla o darla ad altri, è un problema che non si
pone.
Sono IO che devo cifrare dei dati evitando che essi siano letti da
altre persone oltre
al mio cliente, quindi io per primo non ho alcun interesse a perdere
la chiave privata.
I dati che andrò a cifrare, sono i miei, di mie proprietà, e non di
proprietà del mio cliente,
e solo un mio singolo cliente deve poterli leggere.
Se non si fida, cazzi suoi, vuol dire che non leggerà mai i miei dati.
Al massimo sono
io che non mi fido a lasciare la chiave privata necessaria per
decodificare al cliente.
Dei visitatori vengono sul *mio* sito, salvano dei dati di *mia*
proprietà che io dovrò
girare in maniera sicura ad un mio cliente ben preciso piuttosto che
ad un altro senza
che ulteriori persone ne possano venire a conoscenza in alcun modo.
Quindi, sono io
che non mi devo fidare dei miei clienti, non il contrario. Quindi io
critto i dati, poi do
la chiave al mio cliente, per poterli decrittare. Se la perde,
problema suo, sta senza i dati.
Tant'è che sul contratto tra me ed i clienti, ci sono delle penali in
caso di divulgazione di
questi dati ad altre persone non autorizzate da noi, proprio perchè i
dati sono i nostri.
E' diverso il discorso....

 
http://www.mozilla.org/projects/security/
Il tuo sistema funziona che è una meraviglia.
Piccolissimo problema: non c'è verso di far
decrittare una stringa da javascript.
Ho trovato solo esempi di codice che crittano
in base ad una chiave pubblica, ma nulla che
decritta una stringa partendo dalla chiave privata.
