Xailer & OZ Software

Hola
Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
XA_Aes256Decrypt.
Con el ejemplo de prueba funciona correctamente, pero al cambiar el
valor a encriptar por otra cosa, unas veces funciona bien y otras no.
Saludos
Alf+.
--

José Alfonso,
> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
> XA_Aes256Decrypt.
>
> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
En el caso de la clave, Xailer se encarga de agrandarla lo que sea
necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar no.
No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
Un saludo,
José F. Giménez

Ok. Lo tengo en cuenta.
Gracias
Saludos
Alf+.
El 27/12/2012 12:24, Jose F. Gimenez escribió:
> José Alfonso,
>
>> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
>> XA_Aes256Decrypt.
>>
>> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
>> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
>
> Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
> en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
> En el caso de la clave, Xailer se encarga de agrandarla lo que sea
> necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar no.
>
> No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
>
>
> Un saludo,
>
> José F. Giménez

Quiero probar eso de "encriptar" los datos...
Y me surgen dudas, como es normal.
¿Que haceis con el "sobrante" del texto a procesar, ya que como decis, debe
ser un múltiplo de 16.?
¿Lo dejais tal cual?
¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
texto a encriptar?
¿Hay funciones alternativas de Harbour para encriptar texto sin necesidad de
ser múltiplo de nada?
Un Saludo,
Xevi.
"José Alfonso Suárez Moreno" ha escrit al
missatge:50dc9d1e$[email=2@svctag-j7w3v3j....]2@svctag-j7w3v3j....[/email]
Ok. Lo tengo en cuenta.
Gracias
Saludos
Alf+.
El 27/12/2012 12:24, Jose F. Gimenez escribió:
> José Alfonso,
>
>> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
>> XA_Aes256Decrypt.
>>
>> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
>> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
>
> Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
> en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
> En el caso de la clave, Xailer se encarga de agrandarla lo que sea
> necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar
> no.
>
> No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
>
>
> Un saludo,
>
> José F. Giménez

Xevi,
> Quiero probar eso de "encriptar" los datos...
> Y me surgen dudas, como es normal.
>
> ¿Que haceis con el "sobrante" del texto a procesar, ya que como decis,
> debe ser un múltiplo de 16.?
> ¿Lo dejais tal cual?
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que
> el texto a encriptar?
El algoritmo AES exige que siempre se cifren los datos en bloques de 16
bytes, y la clave debe de tener siempre 32 bytes. Y como decí­a aquel:
"esto no es negociable". Vamos, que esto es así­ porque es como funciona
el algoritmo. No hay otra opción.
Dicho esto, cuando se llama a las funciones de AES, Xailer expande la
clave que le pasas a 32 bytes en total, simplemente repitiéndola una y
otra vez hasta completar los 32 bytes. P.ej., si usas la clave "1234",
entonces Xailer la expandirá a "123412341234....1234".
Respecto a la cadena a cifrar, Xailer prepara un buffer de salida que es
mútiplo de 16 bytes, pero actualmente no comprueba el tamaño del buffer
de entrada, y eso es lo que da pie a errores en los procesos de crifrado
y descifrado de datos. Por eso es tan importante que la cadena siempre
sea mútiplo de 16 bytes. Pero esto es tan sencillo como hacer un Pad()
previamente.
> ¿Hay funciones alternativas de Harbour para encriptar texto sin
> necesidad de ser múltiplo de nada?
La verdad es que no lo sé, pero sí­ te puedo asegurar que todos los
algoritmos de cifrado simétrico más o menos serios, son de cifrado por
bloques (http://es.wikipedia.org/wiki/Cifrado_por_bloques).
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Jose,
muchas gracias.
Me queda una duda en el tintero...
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
> texto a encriptar?
o sea... si encripto un texto de un campo que ocupa 25 caracteres en una
DBF, el texto encriptado, ¿cuanto ocupará?
Lo digo por si se respeta el ancho de los campos dados en una estructura de
una DBF o como hay que hacerlo.
Un Saludo,
Xevi.
"Jose F. Gimenez" ha escrit al missatge:5195e9f0$[email=1@svctag-j7w3v3j....]1@svctag-j7w3v3j....[/email]
Xevi,
> Quiero probar eso de "encriptar" los datos...
> Y me surgen dudas, como es normal.
>
> ¿Que haceis con el "sobrante" del texto a procesar, ya que como decis,
> debe ser un múltiplo de 16.?
> ¿Lo dejais tal cual?
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
> texto a encriptar?
El algoritmo AES exige que siempre se cifren los datos en bloques de 16
bytes, y la clave debe de tener siempre 32 bytes. Y como decí­a aquel:
"esto no es negociable". Vamos, que esto es así­ porque es como funciona
el algoritmo. No hay otra opción.
Dicho esto, cuando se llama a las funciones de AES, Xailer expande la
clave que le pasas a 32 bytes en total, simplemente repitiéndola una y
otra vez hasta completar los 32 bytes. P.ej., si usas la clave "1234",
entonces Xailer la expandirá a "123412341234....1234".
Respecto a la cadena a cifrar, Xailer prepara un buffer de salida que es
mútiplo de 16 bytes, pero actualmente no comprueba el tamaño del buffer
de entrada, y eso es lo que da pie a errores en los procesos de crifrado
y descifrado de datos. Por eso es tan importante que la cadena siempre
sea mútiplo de 16 bytes. Pero esto es tan sencillo como hacer un Pad()
previamente.
> ¿Hay funciones alternativas de Harbour para encriptar texto sin necesidad
> de ser múltiplo de nada?
La verdad es que no lo sé, pero sí­ te puedo asegurar que todos los
algoritmos de cifrado simétrico más o menos serios, son de cifrado por
bloques (http://es.wikipedia.org/wiki/Cifrado_por_bloques).
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Xevi,
> Me queda una duda en el tintero...
>> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud
>> que el texto a encriptar?
>
> o sea... si encripto un texto de un campo que ocupa 25 caracteres en
> una DBF, el texto encriptado, ¿cuanto ocupará?
> Lo digo por si se respeta el ancho de los campos dados en una
> estructura de una DBF o como hay que hacerlo.
No. Para cifrar 25 caracteres, tienes que expandir la cadena a 32
caracteres, con Pad( cCadena, 32 ), y el texto cifrado va a ocupar 32
caracteres. No intentes después recortarlo porque entonces no se puede
descifrar.
Si lo que vas a hacer es cifrar un campo que contiene una contraseña, lo
mejor que puedes hacer es establecer ese campo de 32, o mejor de 64,
caracteres, y guardar siempre la cadena convertida a hexadecimal. P.ej.:
REPLACE clave WITH StringToHex( cClaveCifrada )
Ten en cuenta que el texto en hexadecimal ocupa siempre justo el doble
que la cadena original. Si la cadena es de 16 caracteres, el resultado
será de 32, y si era de 32, el resultado será de 64 caracteres.
Y ya que estamos... para guardar contraseñas no hace falta usar un
algoritmo de cifrado simétrico, como AES. Se puede usar también un hash
de tipo MD5 (actualmente desaconsejable) o SHA1. La técnica consiste
siempre en no descifrar nunca las contraseñas guardadas. Lo que se hace
es que cuando el usuario escribe su contraseña para entrar, el texto que
ha escrito se vuelve a cifrar, y se compara con lo que tienes almacenado
en la BD. Esto es más seguro que utilizar AES o similares, porque de
algún modo tienes que usar una contraseña de cifrado que se podrí­a
averiguar.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Jose,
Gracias, entiendo.
Tal como tengo mis DBFs no puedo encriptar campos, deberia de cambiar
tamaños... igual deberia de replantear la aplicación.
Para encriptar TODA una DBF, o un fichero... ¿alguna función?
Porque igual puedo encriptar toda la base de datos y que sea desde la
aplicación la encargada de "desencriptar" los datos i así­ poder trabajar y
visualizar los datos.
Un Saludo,
Xevi.
"Jose F. Gimenez" ha escrit al missatge:[email=5196213d@svctag-j7w3v3j....]5196213d@svctag-j7w3v3j....[/email]
Xevi,
> Me queda una duda en el tintero...
>> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
>> texto a encriptar?
>
> o sea... si encripto un texto de un campo que ocupa 25 caracteres en una
> DBF, el texto encriptado, ¿cuanto ocupará?
> Lo digo por si se respeta el ancho de los campos dados en una estructura
> de una DBF o como hay que hacerlo.
No. Para cifrar 25 caracteres, tienes que expandir la cadena a 32
caracteres, con Pad( cCadena, 32 ), y el texto cifrado va a ocupar 32
caracteres. No intentes después recortarlo porque entonces no se puede
descifrar.
Si lo que vas a hacer es cifrar un campo que contiene una contraseña, lo
mejor que puedes hacer es establecer ese campo de 32, o mejor de 64,
caracteres, y guardar siempre la cadena convertida a hexadecimal. P.ej.:
REPLACE clave WITH StringToHex( cClaveCifrada )
Ten en cuenta que el texto en hexadecimal ocupa siempre justo el doble
que la cadena original. Si la cadena es de 16 caracteres, el resultado
será de 32, y si era de 32, el resultado será de 64 caracteres.
Y ya que estamos... para guardar contraseñas no hace falta usar un
algoritmo de cifrado simétrico, como AES. Se puede usar también un hash
de tipo MD5 (actualmente desaconsejable) o SHA1. La técnica consiste
siempre en no descifrar nunca las contraseñas guardadas. Lo que se hace
es que cuando el usuario escribe su contraseña para entrar, el texto que
ha escrito se vuelve a cifrar, y se compara con lo que tienes almacenado
en la BD. Esto es más seguro que utilizar AES o similares, porque de
algún modo tienes que usar una contraseña de cifrado que se podrí­a
averiguar.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Xevi,
> Gracias, entiendo.
> Tal como tengo mis DBFs no puedo encriptar campos, deberia de cambiar
> tamaños... igual deberia de replantear la aplicación.
>
> Para encriptar TODA una DBF, o un fichero... ¿alguna función?
> Porque igual puedo encriptar toda la base de datos y que sea desde la
> aplicación la encargada de "desencriptar" los datos i así­ poder
> trabajar y visualizar los datos.
El datasource de SQLite implementa ya el cifrado completo de la BD, sin
necesidad de ningún software adicional. Es más, yo lo estoy usando, y
funciona perfectamente, te lo puedo asegurar. El fichero de la DB se
cifra completamente, incluida la cabecera, y es completamente
transparente para los datasets o para cualquier cosa que hagas desde
programa. Lo único que hay que hacer es asignar la propiedad cPassword
del datasource, y Xailer se encarga del resto
Pero para DBFs no tenemos nada. No sé si habrá algún RDD que lo haga,
pero a nivel del datasource de Xailer me temo que no.
Yo personalmente, aconsejo a todos los que utilizan DBFs a pasarse a
SQLite. Al ser un motor local, como los DBFs, el salto no es tan grande,
y sí­ que se obtienen los beneficios de usar SQL. Y si más adelante es
necesario, saltar a MySQL o MariaDB es muy sencillo, ya que SQLite es un
99% compatible con MySQL a nivel de dialecto SQL, mucho más compatible
que con cualquier otro motor o que otros motores entre sí­. Yo mismo
tengo aplicaciones que funcionan tanto con SQLite como con MySQL/MariaDB
con sólo cambiar un parámetro en la configuración, y usando el mismo
código para todo. Tan sólo cambia el datasource.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info