Problemas al tratar de guardar y después recuperar una cadena de texto cifrada

[roman]

Los strings pueden manejar perfectamente bytes no imprimibles incluido el cero. Lo único que no puedes es, este, imprimirlos. Por eso, insisto, a menos que quiera mostralo en un Memo, mandarlo por correo, guardarlo en un XML o algo por el estilo, no tiene necesidad de pasar a base 64.

// Saludos

[[escafandra]]

Claro, roman, por eso me he referido al cast de conversión PBYTE -> String en el que se va a partir la cadena en cuanto encuentre un #0. Pero ya digo, hay que revisar el código al usar la API de windows y su conversión a String. Naturalmente puedo estar equivocado (no revisé el código), pero el hecho de que se parta la cadena me hace pensar en esa posible causa.


Saludos.

[[escafandra]]

Acabo de probar el código y funciona bien. El primer ShowMessage no muestra toda la cadena cifrada porque realiza una conversión a PCHAR en el seno de ShowMessage. He realizado un debug hasta llegar al punto del fallo, en concreto cuando usa la API DrawText y corta en el primer #0 encontrado. El problema no es del cifrado sino de ShowMessage de delphi. En caso de usar cualquier otra API que use cadenas, el efecto será similar.


Saludos.

[roman]

Empezado por escafandra

Acabo de probar el código y funciona bien. El primer ShowMessage no muestra toda la cadena cifrada porque realiza una conversión a PCHAR en el seno de ShowMessage. He realizado un debug hasta llegar al punto del fallo, en concreto cuando usa la API DrawText y corta en el primer #0 encontrado. El problema no es del cifrado sino de ShowMessage de delphi. En caso de usar cualquier otra API que use cadenas, el efecto será similar.


Saludos.

Contesté mientras escribías tú. Éso es a lo que me refiero. Ni el Memo ni el ShowMessage lo van a hacer correctamente (porque sólo trabajan con texto imprimible). La rutina de seoane está perfecta.

// Saludos

[[escafandra]]

Empezado por roman

Contesté mientras escribías tú. Éso es a lo que me refiero. Ni el Memo ni el ShowMessage lo van a hacer correctamente (porque sólo trabajan con texto imprimible). La rutina de seoane está perfecta.

Claro que está perfecta, el error no está en caracteres no imprimibles pues se escribirá cualquier cosa, el error está en el primer cero que aparezca al usar la API, en este caso DrawText.

Saludos.

[roman]

Quizá me confundo pero yo a lo que me refiero es al código original que pone dec antes de entrar a lo de convertir a base 64.

Él dice que en este código

Código Delphi [-]
 encryptedText := cipher.EncryptString(originalText, 'password', haSHA512);

Memo1.Text := encryptedText;

decryptedText := cipher.DecryptString(Memo1.Text, 'password', haSHA512);

ShowMessage(decryptedText);

Empezado por dec

En este último caso, en lugar de mostrar mediante un "ShowMessage" la cadena cifrada, la guardamos en un "TMemo". Así que después, tratamos de descifrar la cadena que acabamos de guardar en dicho "TMemo", sin embargo, no obtendremos el resultado deseado, puesto que el "TMemo" sólo contendrá/mostrará parte de la cadena cifrada, y, por tanto, será imposible obtener la original a partir de ella.

Y, claro, es imposible que obtenga el resultado original porque un Memo no maneja strings con bytes no imprimibles. Pero eso no quiere decir que no pueda guardar el resultado y recuperarlo posteriormente.

Por ejemplo, puede meter encryptedText en un TStringStream, copiar el stream a un TFileStream y guardarlo a disco. Siguiendo los pasos inversos necesariamente obtendrá el texto original.

// Saludos

[dec]

Hola a todos,

Gracias por vuestro interés. Román, no se trata de mostrar la cadena cifrada en un "Memo", pero, de guardarla en un archivo INI, por ejemplo (por esto saltó la liebre, como suele decirse). O, en todo caso, se trata de "retornar" una cadena cifrada, que, después debería poder descifrarse para obtener la cadena original. De todas formas me has dejado una duda que quiero probar... Lo cierto es que todavía estoy con la mosca detrás de la oreja, fundamentalmente, por estos dos motivos:

1º Todavía no me explico cómo es posible que el mismo código que funciona en Delphi 2007 bajo Windows 7 no lo hace de igual modo en Delphi 2007 bajo Windows 8. Pero, en fin, vamos a dar por hecho algún tipo de error introducido en las últimas versiones de Indy, cosa que me extraña muchísimo, pero, puesto que el problema "parece" solucionarse usando un componente distinto de Indy, de acuerdo, sigamos adelante... pero...

2º Resulta que de este modo, con el nuevo componente (no Indy) todo va sobre ruedas en Delphi, esto es, puedo cifrar y descifrar cadenas verdaderamente largas sin problema alguno. Pero... por alguna razón, cuando lo pruebo en mi programa, no es que no funcione, pero, es que puede cifrar cadenas de (ojo al dato) hasta 60.000 caracteres. Como lo leéis. A mí me suena que esa es la cifra máxima permitida para una "línea"...

Bien. Quisiera ahora hablar un poco de mi programa, sólo para declarar su naturaleza un tanto "especial". Mi programa es en realidad una DLL, que a su vez será usada por otro programa. ¿Complica esto las cosas? Bueno, sí, pero no. Llevo hechas ya varias decenas de DLL para dicho programa "host", y, ciertamente, a veces he notado comportamientos extraños que no notaba en Delphi. Resumiendo, esto podría deberse a las características del programa, de trabajar desde una DLL, etc.

Pero el caso es que me llama muchísimo la atención no poder cifrar cadenas de más de una cifra tan redonda como 60.000 caracteres... me parece una cifra demasiado redonda como para que no signifique algo. ¿Cuál es mi problema ahora, por lo tanto? Pues que, asumiendo que usar "base 64" sea la solución, lo cierto es que esta solución funciona sin problemas en un programa de pruebas hecho en Delphi, pero, no en la DLL desarrollo y a su vez utiliza otro programa.

Voy a intentar que el autor de dicho programa me eche una mano, en el sentido de si a él le sonase de algo una cifra mágica como es 60.000 caracteres... ni uno más. Por supuesto si se os ocurre cualquier cosa al respecto os estaría muy agradecido.

P.D. Román, de hecho la DLL que desarrollo cuenta con "acciones" para cifrar y descifrar cadenas y archivos. Ahora bien, en lo tocante a archivos no he tenido problemas en cifrar y descifrar archivos de cualquier tamaño y tipo. Pero claro,... las acciones para cifrar cadenas se supone que deberían servir también. Ay diosito mío.

[[escafandra]]

Empezado por dec

1º Todavía no me explico cómo es posible que el mismo código que funciona en Delphi 2007 bajo Windows 7 no lo hace de igual modo en Delphi 2007 bajo Windows 8. Pero, en fin, vamos a dar por hecho algún tipo de error introducido en las últimas versiones de Indy, cosa que me extraña muchísimo, pero, puesto que el problema "parece" solucionarse usando un componente distinto de Indy, de acuerdo, sigamos adelante... pero...

Yo lo he probado en Win8, pero compilado con delphi7 y el error en ShowMessage es el esperado.

No trates de guardarlo en un archivo de texto (INI) pues obtendrás el mismo error, usa un archivo binario.


Saludos.

[roman]

Si quieres guardar el resultado en un archivo INI, desde luego, no tienes otra opción que hacer una conversión a base 64 o similar. Pero, puedes guardarlo en un archivo binario y olvidarte del base 64

// Saludos

[roman]

Je, je, nos vamos pisando los talones

// Saludos

[[escafandra]]

Sip.

Saludos.

[dec]

Hola,

Gracias por responder. Entiendo lo que queréis decir, y, si de mí dependiera, esa sería probablemente la solución que tomase. Tal vez algo falla en la lógica del producto que ofrezco, lo que también me gustaría que se me dijese si es así. Bien. El caso es que yo ofrezco una DLL que añade "acciones" a un programa "madre" o "host". Para simplificar diremos que estas acciones son: cifrar cadena, descifrar cadena, cifrar archivo, descifrar archivo.

Ahora bien, si se ofrece la acción "cifrar cadena", para mí es obvio (¡pero puedo estar completamente equivocado!) que tenemos que retornar al usuario de nuestra DLL la cadena cifrada. Dónde la guarde o lo que haga con ella no es de nuestra incumbencia. Lo que pasa es que, dicho así, podría uno replicar: "Un momento, si el usuario necesita pasar la cadena cifrada a base 64, ¡que lo haga el mismo!".

Pero es que el problema reside en que, sea por las características de la comunicación entre DLL y programa "madre", la cadena cifrada no llega, directamente, a retornarse al usuario. Queda truncada. De manera que no es posible después su descifrado. Ahora bien... os juro por dios que ahora mismo dudo de si hasta he probado esto efectivamente... esto es, si la cadena se descifra aunque sea "en memoria", es decir, sin guardarla en sitio alguno.

Así que no me queda otra que volver a hacer pruebas de nuevo. Como decía Casimiro, vísteme despacio que tengo prisa... Aunque de todos modos, por favor, prestad atención a lo dicho en el primer párrafo, en el sentido de que no se trata de lo que yo haga con la cadena cifrada (y mi empeño verla en un "Memo" o lo que sea) sino que es el usuario de mi DLL quien debe recibir una cadena cifrada que después pueda descifrar.

Gracias de nuevo por vuestro interés.

P.D. Quisiera recordar la cifra mágica de 60.000 ¿caracteres? como posible límite de algún tipo en algún lugar...