encrypt DBF using ADS Local

[clemerson]

does he have as encrypt DBF using ADS Local for any user to access without the system to be?

Clemerson

[R.F.]

Postea el mensaje en portugues, es totalmente intenedible

[clemerson]

Postea el mensaje en portugues, es totalmente intenedible

Gostaria de encriptografar o DBF usando o ADS local, para que nenhum usuario consiga abrir usando DBU, wdbu, etc ..

Clemerson

[R.F.]

Ok, aqui va:

1) En el código fuente, deber cargar los componentes necesarios del RDDADS

In the source code you need to include the necesary components for the RDDADS

Request ADS
RddSetDefault(ADS)
AdsSetServerType(7) //todos los servidores
AdsSetFileType(2) // archivos DBF /CDX

No olviden linkear las libs RDDADS.LIB y ACE32.LIB
Don´t forget to include RDDADS.LIB and ACE32.LIB libraries.

2) Abrir la tabla DBF y SI NO ESTA ENCRIPTADA, establecer el password y encriptar:
Open the DBF and IF IT'S NOT ENCRYPTED, you must set a password and proceed to encrypt


USE tabla
AdsEnableEncryption("clave") //"clave" es el password para la tabla
AdsEncryptTable()
CLOSE

3) Si la tabla ya esta encriptada entonces se abre y se establece su password:
If the table is already encrypted, then open it and set the password

USE tabla
AdsEnableEncryption("clave")
BROWSE()

4) Se utilizan normalmente, todas las operaciones relativas a la base de datos, como SEEK, SET FILTER, APPEND, REPLACE etc. Estas realizarán la encriptacion de manera automatica. No hay necesidad de desencriptar los datos, el servidor (local o remoto), se encarga de encriptar en el momento de hacer un REPLACE y de enviar al cliente los datos desencriptados de manera automatica. Solo tienes que establecer la clave correcta para cada area.

Now you can use all the database related operations such SEEK, SET FILTER, APPEND, REPLACE, etc. All these instructions will perform the encryption by themselves automatically. There's no need to decrypt the data, the server (local or remote), takes care of encrypting whenever you perfom a REPLACE or when sending data to the client, the data is automatically decrypted. You just have to set the correct password for each area.

5) No olvides incluir los 3 DLLs de ADS ncesarios donde esta el EXE: ACE32.DLL, AXWCS32.DLL y ADSLOC32.DLL

Don't forget to include the 3 needed DLLs for ADS in the sema directory where the EXE is: ACE32.DLL, AXWC32.DLL and ADSLOC32.DLL

6) Cada AREA puede tener su propia llave de encriptacion, por ejemplo:
Each workarea can have its own encrypt password, example:

USE tabla1
AdsEnableEncryption("clave1")

USE tabla2
AdsEnableEncryption("clave2")

7) No hay caida en la velocidad porque el programa no hace los procesos de encriptar/desencriptar, lo hace el server.
There's no decrease of the app speed, because the encrypt/decrypt process are performed by the server, not by the program.

7) El proceso de encriptar con ADS ALTERA LA CABECERA DEL ARCHIVO, ni Excel ni ningun editor deDBFs podra visualizar el archivo.

Datos interesantes con respecto a la encriptacion: A partir del encriptamiento de la tabla, siempre que se haga uso de ella, será necesario utilizar la función AdsEnableEncryption() con la clave de encriptamiento adecuada, para poder hacer actualizaciones al archivo, si la clave de encriptamiento no es correcta, el archivo se abre pero no se pueden leer ni modificar datos.

Cuando una tabla se encripta, también se realizan procesos de encriptamiento en la cabecera del archivo, esto se hace con el fin de que los datos no puedan ser leidos por ningún programa externo, incluyendo el ARC, el cual pedirá la clave de encriptamiento cuando se intente abrir el archivo.

El proceso de encriptar / desencriptar, pasa por el servidor ADS, los datos siempre permanecen almacenados de manera encriptada y es el servidor quien se encarga de los procesos de traducción, es decir, el servidor leerá los datos de archivo encriptado, desencripta la información y los devuelve al cliente de manera desencriptada y viceversa, en los procesos de actualización / inserción, los datos son recibidos del cliente de manera desencriptada, y cuando son escritos en el archivo de datos, el servidor encripta y guarda.

Interestings facts about ADS encryption: Once encypted the table, and whenever you use it, It would be necesary to use the AdsEnableEncryption() function with the correct encryption password in order to perform update operations on the DBF, if the password is not correct the table is open but you cannot read, nor update the data.

When a table is encrypted, the header of the DBF is also encrypted, this is perform to avoid any external program to open the DBF, including the ARC (The DBU for advantage tables) which will ask for the password when you try to open it.

The encrypt/decrypt process goes through the ADS server, the data is always stored in an encrypted way, and is the server which performs the translation process, this means that the server will read the data in the encrypted file, will decrypt it and will be send decrypted to the client application and viceversa, in the append/update process the data is recieved from the client application decrypted and it's encrypted and saved to the file by the server.

[clemerson]

Muito Obrigado ...

[reinaldocrespo]

René;

Como siempre --muy buena información.

Muy agradecido.

De paso, si esto funciona tan y tan bien, que razón pudiera existir para no usar encryption con ADS?

Recibe un saludo muy coridal,


Reinaldo.

[R.F.]

Reinaldo:

De paso, si esto funciona tan y tan bien, que razón pudiera existir para no usar encryption con ADS?

1) Esta caracteristica esta disponible en el servidor local, sin embargo ten en cuenta que con el server local solo pueden utilizar 5 usuarios en red la aplicacion sin tener problema de velocidad. Con el servidor local yo no meteria mi mano al fuego para mas de 5 usuarios en temas de velocidad.

2) el unico problema que hemos visto con respecto a la encriptacion, es el tamaño de las tablas cuando las quieres meter en un ZIP, veras, si tu compactas en un archivo ZIP un DBF comun y corriente, puedes obtener grados de compresion superiores al 50%, ¿ porque ?, pues porque dentro del archivo DBF hay muchisimos espacios en blanco que son facilmente comprimibles por el algoritmo del ZIP, por ejemplo, si tienes un campo que guarda un nombre y ese campo mide 60 caracteres, y en promedio utilizas 40, tienes 20 espacios en blanco que puden ser facilmente comprimibles. Cuando tienes la tabla encriptada, esto no sucede asi, ADS utiliza un algoritmo de encirptamiento que nunca proporciona el mismo caracter encriptado para los mismos caracteres, por ejemplo, si yo tengo el dato:

RF

ADS te presentara criptado algo como esto:

[rkL-*Qc,;

En un algoritmo tradicional de encriptamiento, todas las letras tienen un mismo signo encriptado, por ejemplo la "r" en este caso equivale a la "E", pero con ADS eso no funciona asi, porque el encriptamiento se da POR POSICION, asi que la misma letra "E" puede tener distintos signos que la identifiquen dependiendo en la posicion donde este. Volviendo a este ejemplo, si tenemos un campo de longitud 40 para almacenar el dato, y solo estas guardando "RF", estan libres 29 espacios en blanco, sin embargo, ADS TAMBIEN ENCRIPTA LOS ESPACIOS EN BLANCO, y como cada espacio en blanco tiene una posicion distinta, el algoritmo genera caracteres distintos que luego el ZIP no puede comprimir.

Esa seria la unica desventaja de usar la encriptacion de ADS.

[Joan]

does he have as encrypt DBF using ADS Local for any user to access without the system to be?

Clemerson

Será posible desencryptar tablas libres y despues de leer sus registros encryptar nuevamente?, .Adt´s. Pues me lanza un error cuando lo hago de la siguiente manera :
getConexion.Execute("EXECUTE PROCEDURE sp_DecryptTable('Tabla.Adt','12345678');", out iFilasAfectadas, -1);
getConexion.Execute("EXECUTE PROCEDURE sp_EncryptTable('Tabla.Adt','12345678');", out iFilasAfectadas, -1);

Me dice que la tabla está abierta.