Newsgroup: it.comp.lang.vo-clipper
Titolo: crittare un dbf

salve a tutti.
ci sono esperienze di crittografia su questo ng?
Vi chiedo se, ad esempio, č possibile tenere crittato un dbf e renderlo
visibile solo al momento del trasferimento dei dati da dbf in memvars per la
visualizzazione. che strumenti si trovano in giro?
grazie a tutti in anticipo per la cortesia.
giuseppe, Lecce

 visualizzazione. che strumenti si trovano in giro?
Io, semplicemente, codifico le stringhe prima di scriverle nei campi e,
al contrario, le decodifico dopo averle lette.
EMG

 ha scritto nel messaggio
news:3911E83E...@flashnet.it...

Ed io aggiungo di ricordarsi che quando si fa una ricerca di un valore
bisogna ricordarsi che il valore sul dbf č criptato.
Se si sono usate due funzioni per es. CRITT, DECRITT...
Se un valore da cercare č in chiaro bisogna scrivere SEEK CRITT(VALORE), se
l'indice č definito su campi crittati.
Qui sorge un problemino, l'indice sul CRITT(CAMPO) puņ essere stravolto
rispetto a quello che avremmo se lo facessimo su DECRITT(CAMPO). In questo
caso perņ l'indice sarebbe in chiaro e potremmo fare la SEEK VALORE.
Qualcuno ha mai risolto un tale nodo gordiano?
--
Live Long And Prosper
Emanuele Manco
Every generation has a legend... Every journey has a first step... Every
saga has a beginning...
E-mail: 
ma...@tiscalinet.it
ICQ# 36161907
Home Page: 
http://hpdma2.math.unipa.it/Manco/source.html
Stardate Home Page: 
http://hpdma2.math.unipa.it/Manco/stardate.htm


Non sai specificato se parli di Clipper e VO. IN VO la cosa e' banale:
basta creare un classe che deriva dalla DbServer e riscrivere i metodi
FieldGet e Fieldput in questo modo:
METHOD Fieldget(uField) CLASS MyDbServer
	RETURN Decrypt(Super:Fieldget(uField))
METHOD FIELDPUT( uFieldPos, uData ) CLASS MYDBSERVER
	Super:Fieldput(uFieldPos, Crypt(uData)
In questo modo in Dbf e' sempre criptato, e la decriptazione avviene
al volo.
-----------------------------
Fabio Cresta
EDP Consultant & VO/Jasmine developer
President of Clipper/Visual Objects/Jasmine User Group Italy
fcr...@tin.it
http://www.windevs.com
ITALY
------------------------------

 Emanuele Manco
--
by(e) Doriano.
E-MAIL: doria~N~o@skyli~N~
k.it
PS: sostituisci  ~N~ con n per rispondere...
        To reply, replace ~N~ with n

Se hai bisogno di algoritmi elementari di crittografia, seguendo
il criterio che ha indicato Fabio Cresta, ti consiglio di
consultare le librerie "Lincoln" pubblicate diversi anni fa nel
sito ftp della CA.
Saluti
Paolo Cherubini
* Sent from RemarQ 
http://www.remarq.com
 The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


http://users.iol.it/fredaannibale
http://utenti.tripod.it/fredaannibale
a.freda[NOSPAM]@
libero.it
 . togliere [NOSPAM] per comunicare in e-mail

Su DEV di Aprile si parla dell'argomento Crittografia in diversi articoli,
sono molto interessanti e spiegano anche le varie tecniche per "far da se"
Ciao
Enio Donci

 Forse ti riferivi ai CDX ?
No, sono proprio gli NSX ad essere bacati. Purtroppo però il baco è di
tipo "magic number" per cui ti capita quando meno te lo aspetti.
EMG

Comunque da quanto ho capito, CDX, NSX o NTX,  bug a parte sono tutti indici
in chiaro, più o meno manipolati, a questo punto ritengo che gli indici
debbano comunque essere creati al volo magari in directory lontane da quelle
dei dbf e poi distrutti una volta utilizzati. Non è il 100% della sicurezza
ma se non siamo alla CIA penso che possa bastare.(Echelon ci ascolta? :-) )
--
Live Long And Prosper
Emanuele Manco
Every generation has a legend... Every journey has a first step... Every


Tipo "magic number" per cui ti capita quando meno te lo aspetti.
Fino ad adesso non ho mai avuto un riscontro in questo senso. L'unica
cosa che posso dirti è che li uso con le stesse modalità di uso dei
file NTX cioè non uso i tag come i CDX. 


 file NTX cioè non uso i tag come i CDX.
Neanch'io usavo i tag, eppure ancora adesso, pur essendo passato da un
pezzo al Comix, mi trovo con questo problema con vecchie installazioni
non ancora aggiornate. Bisogna però dire che il difetto si manifesta più
che altro nei programmi Windows (Fivewin) ma l'ho visto anche con
programmi DOS.
EMG





Prova a utilizzare queste funzioni :


 






function encrypted    
  && Per crittare 


    parameters 
  p_string


    private pro_temp


    private 
  pro_length


    private pro_x


    if type("p_string") != 
  "C"


        
      "Errore Stringa"


        
      return ""


    endif


    pro_temp = ""


    pro_length = 
  len(p_string)


    for pro_x = 1 to pro_length 
  step 1


        
      pro_temp = pro_temp + chr(asc(substr(p_string,pro_x,1)) + 
  101 + ;


        
      pro_x)


    next


return pro_temp


********************************


function decrypted  && per 
  decifrare 




    parameters 
  p_string


    private pro_temp


    private 
  pro_length


    private pro_x


    
if 
  type("p_string") != "C"


        
  "Errore Stringa " && Ahio che casino ...  


        return 
  ""


    endif


    pro_temp = ""


    pro_length = 
  len(p_string)


    for pro_x = 1 to pro_length 
  step 1


        pro_temp 
  = pro_temp + chr(asc(substr(p_string,pro_x,1)) - 101 - pro_x)


    next


return pro_temp


E' inutile consigliarti di gestire gli input su variabili 
temporanee tipo XXX per poi interagire con replace encrypted/decrypted(xxx) sui 
campi 


 


 


 



         private pro_x
Solo una nota: le variabili PRIVATE sono una reliquia del passato che è
meglio non utilizzare. Come tutte le variabili con scope al di fuori
della singola funzione, provocano molti più problemi di quanti ne
risolvano.
EMG