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

[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...

[roman]

Claro, tú le entregas la cadena al usuario y él hará lo que mejor le convenga, incluso pasarla a base 64 . Pero, ¿quién te obliga a entregársela através de un Memo?. Ponle un botón que diga: "Guarde esta cadena donde a usted más le quep, digo, convenga"

// Saludos

[dec]

Hola,

Román, acabo de probar de nuevo como si no hubiésemos hablado nada, es decir, quitando del medio la codificación/decodificación en "base 64". En este caso no he tratado de mostrar la cadena en un Memo, pero, he querido guardarla en un archivo. Pero estamos en las mismas: la cadena que la DLL pasa al programa, por un motivo que desconozco, parece perderse en parte por el camino...

Sin embargo creo (estoy medio loco ya) comprender el asunto que tratáis de explicarme. Es decir, si yo cifro una cadena en Delphi y trato de guardarla en un archivo, estaré en la misma situación, de ahí que vosotros me sugiráis guardar la cadena en un archivo binario. De hecho acabo de probar a guardar la cadena recién cifrada en un "TStrings", y, de ahí a un archivo, y, en efecto, el problema es el mismo...

Ciertamente, comienzo a pensar que tal vez esto requiera de un planteamiento diferente. ¡Pero no tengo ni idea ahora mismo de cuál puede ser!

Si uno quiere hacer un programa cifrador/descifrador de cadenas... ¿cómo se supone que debe entregar la cadena cifrada al usuario para que este pueda guardarla donde más le plazca? ¿No podrá? ¿Entonces para qué demonios sirve el cifrador/descifrador? ¿Qué es lo que no estoy entendiendo bien?

[roman]

Un TStrings tampoco te sirve, es lo mismo que un TMemo a final de cuentas. Son clases pensadas para mostrar texto y cualquier información binaria se pierde. Usa streams.

// Saludos

[dec]

Hola a todos,

Empezado por roman

Un TStrings tampoco te sirve, es lo mismo que un TMemo a final de cuentas. Son clases pensadas para mostrar texto y cualquier información binaria se pierde. Usa streams.

// Saludos

Quizá aquí deba decirse que el programa "madre" o "host" en cuestión (no mi DLL, claro está) no conoce de tipos "stream". Sólo trabaja con enteros y cadenas. También algún tipo de "array", pero, no sabe lo que es un "stream" y por tanto no puedo "pasar" un "stream" como acaso sería lo suyo.

¿Nos vamos acercando?

[roman]

¡Ah! Caray. Pues, ¿que no estamos hablando de delphi? Si está en Object Pascal debe haber streams, o ¿qué no estoy entendiendo?

Por otro lado, no sé en los delphis actuales, pero en los antiguos no puedes pasar un string de dll a aplicación ni viceversa. Pero eso no debería ser problema. Conviertes a PChar antes de entregarla al programa host.

// Saludos

[dec]

Hola,

En efecto, el programa está hecho en Delphi (desde los tiempos de Turbo Pascal, si no me equivo) y es un programa estupendo: NeoBook. Este programa, en pocas palabras, es un IDE para "no programadores". Permite crear aplicaciones para Windows de una forma "visual" y muy sencilla, seleccionado las "acciones" que uno quiere llevar a cabo: leer un archivo, escribir un archivo, hacer una petición HTTP, cifrar cadenas...

El programa, es decir, el propio NeoBook, sí que entiende de "streams", por supuesto, pero, no los programas generados con NeoBook. Este NeoBook es el IDE y también el intérprete de las acciones que el usuario programe. Y dicho usuario cuenta con la posibilidad de usar variables simples (cadenas, numéricas) o definir algunos tipos de variables más avanzadas como "arrays", pero, no el tipo "stream" o alguno similar.

Además, en efecto, la DLL trabaja con PChar. Es el propio NeoBook el que, en su SDK (Software Development Kit), ofrece ciertas funciones para establecer "variables de NeoBook", obtener su valor, etc. Me quedo con el hecho claro de que las aplicaciones desarrolladas con NeoBook no soportan el tipo "stream", y tal vez por aquí deberíamos empezar a obtener una explicación a todo lo que está pasando, en lugar de tratar de codificar la cadena cifrada en "base 64".

Ahora bien, tal vez, por la propia naturaleza de NeoBook (esto se podría explicar así a los usuarios de mi DLL) el plugin necesariamente tenga que hacer esa codificación en "base 64", puesto que no es posible retornar la cadena cifrada tal cual en una cadena de texto. Pero superado este razonamiento que parece lógico y entendible, nos encontraríamos con la cifra mágica de 60.000 caracteres... es decir, en Delphi puedo cifrar y codificar en "base 64" cadenas de muchos más caracteres.

Y aquí estamos hablando de cadenas de texto... ¿por qué demonios, entonces, no podría la DLL hacer lo mismo que el programa de pruebas de Delphi (de hecho usan el mismo código) y enviar la cadena a NeoBook, tenga esta la longitud que tenga? Más aún, ¿por qué se corta inexplicablemente a los 60.000 caracteres exactos? Vale decir que he probado a enviar cadenas de este tamaño (pero sin codificar ni nada) y NeoBook parece recibirlas correctamente.

[[escafandra]]

Puedes pasar la cadena cifrada a una cadena hexadecimal, en ese caso tendrás siempre texto puro y tu cliente podrá hacer lo que quiera con esa cadena, siempre y cuando la convierta a binario antes de descifrarla.

Saludos.

[dec]

Hola a todos,

Empezado por escafandra

Puedes pasar la cadena cifrada a una cadena hexadecimal, en ese caso tendrás siempre texto puro y tu cliente podrá hacer lo que quiera con esa cadena, siempre y cuando la convierta a binario antes de descifrarla.

Saludos.

Gracias escafandra. No sé si querrás decir que puede usarse otra cosa que no sea "base 64". En efecto, yo también lo he pensado, aunque, no había pensado en la solución que tú propones. De hecho podría ser una solución (si funciona), puesto que, digo yo, el usuario podrá pasarme esa cadena... y ser yo el encargado de convertirla a otra cosa. Pero no creas que tengo claro ahora mismo cómo hacerlo...

Por cierto, acabo de comprobar que, en efecto, una DLL puede pasar a NeoBook cadenas de mucho mayor tamaño que 60.000 caracteres. He cargado un archivo de texto mucho mayor en un "TStrings", lo he asignado a una variable de NeoBook (tal como se hace con la cadena codificada en "base 64") y la aplicación de NeoBook recibe dicha variable y puede a su vez guardarla en un archivo sin pérdidas de ningún tipo.

¿Qué está pasando aquí?

[[escafandra]]

Pasa a tu dll un buffer y su tamaño, es decir, un puntero al primer elemento de tu String y su tamaño, de esa forma probablemente no tendrás errores.


Saludos.

[dec]

Hola,

Empezado por escafandra

Pasa a tu dll un buffer y su tamaño, es decir, un puntero al primer elemento de tu String y su tamaño, de esa forma probablemente no tendrás errores.


Saludos.

No estoy seguro de que algo así pueda funcionar escafandra. Recordemos que el usuario sólo puede pasar a mi DLL una cadena de texto, no un "buffer" ni nada parecido. ¿O lo he entendido mal?

Por cierto que ya vamos acotando el asunto... he guardado en un archivo de texto unos 80.000 caracteres codificados en "base 64". Desde mi DLL leo dicho archivo (usando "TStrings") y asigno su contenido a una variable de NeoBook.

Pues bien, dicha variable se asigna correctamente... y la aplicación puede guardar su contenido a otro archivo de texto sin que se pierda nada en absoluto. Y ahora es cuando digo que creo haber acotado algo que no sé ni lo que es...

[[escafandra]]

En realidad un String no es otra cosa que un buffer y un tamaño...

Debes tener claro si quieres base64 u otra cosa. Cualquier otra cosa binaria puedes pasarla a su texto en hexadecimal... tu decides

Saludos

[dec]

Hola,

Empezado por escafandra

En realidad un String no es otra cosa que un buffer y un tamaño...

Debes tener claro si quieres base64 u otra cosa. Cualquier otra cosa binaria puedes pasarla a su texto en hexadecimal... tu decides

Saludos

Gracias escafandra. Te juro que no sé cómo hacer lo que me sugieres. Otrosí recordemos que yo recibo variables del tipo PChar y no de tipo String. No sé si esto implica algo.

Por lo demás, si os cuento lo que acabo de hacer no lo creéis. Como he dicho arriba, otra de mis DLL permite al usuario codificar y decodificar en "base 64". Ahora bien, esta DLL usa los componentes Indy para llevarlo a cabo.

Pues bien, he probado a codificar un archivo de texto en "base 64" con una de estas acciones, es decir, enviar al programa "madre" la cadena codificada (no cifrada) en "base 64", y, ¿y qué diréis que ha pasado? Exacto: no puedo enviar más de 60.000 caracteres exactos.

O sea, suponiendo que algún usuario de dicha DLL quisiera codificar más de 60.000 caracteres se encontraría con el problema de no poder hacerlo... por si tenía poco con un problema, ahora acaso tengo dos. ¡Toma ya!

¿Pero qué demonios significa esta limitación de 60.000 caracteres? ¿Por qué, exactamente, 60.000 caracteres? ¿Cómo es que dicha limitación existe si se usa Indy como si se usa la unidad que he enlazado más arriba?

Uff...

[Casimiro Notevi]

Puede que esos 60000 caracteres, en su día, surgió de una manera similar a: ¿quién va a necesitar más de 640 Kb?

[roman]

Además siempre puede poner la leyenda:

"Debido a limitaciones propias de NeoBook, este plugn sólo puede cifrar un máximo de 60,000 caracteres"

Supongo que también puedes partir en pedazos de 60000 o menos y pasar pieza por pieza.

// Saludos