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

[dec]

Hola,

Empezado por 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?

Sí; je je je... pero no puede ser Casimiro. Nada me gustaría más que desentenderme del asunto, y, si existiese esta limitación también en Delphi (tal vez incluso en la "especificación" de "base 64" o algo así) entonces tal vez no quedaría más remedio, pero, parece que esta limitación sólo se da en mi DLL y su relación con el programa "madre" en cuestión. Algo que no tiene lógica si se leen mis anteriores mensajes y que se resume en que podemos pasar cadenas mucho más largas de 60.000 caracteres, pero, por alguna razón, no si esta cadena está codificada en "base 64"...

[Casimiro Notevi]

No sé cómo trabaja tu programa ni el otro, pero ¿cómo sabe ese programa que le están enviando algo en code64 (o code25 o code129, por decir algo) para aceptar 60 mil caracteres o más?

[dec]

Hola,

Empezado por Casimiro Notevi

No sé cómo trabaja tu programa ni el otro, pero ¿cómo sabe ese programa que le están enviando algo en code64 (o code25 o code129, por decir algo) para aceptar 60 mil caracteres o más?

Pues... yo creo que en realidad no lo sabe. Y, de saberlo, ¿qué tendría que decir? Es decir, al programa debería darle lo mismo la cadena que se le pasa. Está visto que no le dá lo mismo si se le pasa algo "en binario". Pero el programa puede "recibir" cadenas mucho mayores de 60.000 caracteres... excepto, parece ser, si dichas cadenas están en "base 64".

Ya. Ya sé que esto no tiene sentido. Además, conociendo un poco al programador de NeoBook (y su programa, y que lleva más de 20 años desarrollándolo) me es muy complicado asumir que el "problema" está en la parte que le toca a NeoBook. Quiero pensar y aun pienso que el problema está de mi parte. Ahora bien, dicho esto, que me expliquen lo que está pasando...

[[escafandra]]

Empezado por dec

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.

Si conviertes un String a un PCHAR se te trunca la cadena en el primer carácter #0, por eso debes usar un buffer y no un cast:
Ejemplo con PBYTE, pero puedes usar un Pointer...

Código Delphi [-]
procedute PasaBuffer(buffer: PBYTE; Size: integer);
.....
 
PasaBuffer(PBYTE(@MyString[1]), Length(MyString));

Empezado por dec

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?

Has probado a usar la API de Windows: CryptBinaryToString y CryptStringToBinary
Ejemplo:

Código Delphi [-]
function Base64Encode(S: String): String;
var
  Size: DWORD;
begin
  if CryptBinaryToString(@S[1], Length(S), CRYPT_STRING_BASE64 ,nil, Size) then
  begin
    SetLength(Result, Size-1);
    if not CryptBinaryToString(@S[1], Length(S), CRYPT_STRING_BASE64, PChar(Result), Size) then
      Result:= EmptyStr;
  end;
end;

Saludos.

[dec]

Hola a todos,

Gracias escafandra. Aunque no comprendo muy bien de lo que se trata, sí sé que NeoBook usa ciertas funciones para "pasar" variables (funciones que nosotros los desarrolladores de DLL's tenemos que usar obligatoriamente), y, lo hace de forma muy similar a como tú dices. O sea, en realidad no me queda claro si podría hacer lo que tú me propones, pero, trataré de investigarlo. Pero, es que ahora ya casi estoy loco del todo, porque, probando a codificar/decodificar cadenas con mis DLL en Windows 7.... no tengo la limitación de 60.000 caracteres. Esto es verdaderamente para acabar atado.

¿Recuerda alguien que ayer comenté que había inconsistencias entre Windows 7 y Windows 8 que yo no podía entender? Parecía que se habían superado (de forma irracional, cambiando de los componentes Indy a otros) pero nada más lejos de la realidad. El asunto es que ahora mismo no sé ni cómo enfocar el problema: ¿resulta que en Windows 7 funciona algo que no funciona en Windows 8? ¿Algo tan "sencillo" como codificar y decodificar en "base 64"? Simplemente no me lo creo.

Así que mañana (espero poder dejar esto por hoy y relajarme/ros un poco) quiero "terminar" la DLL y probarla en Windows 7 y Windows 8,... y ver qué pasa.

Ya os contaré...

¡Gracias de nuevo a todos!

[dec]

Hola,

No os quiero dejar con las ganas de saber que al final he conseguido subsanar el problema. Con la ayuda de todos. Hay cosas que todavía no consigo comprender. Por ejemplo, ya no uso Indy para codificar en "base 64", pero, creo que no se trata de un problema de Indy, sino de cómo se comporta el programa "madre" de mi DLL. El caso es que, como suele pasar, desafortunadamente, más de una vez (por lo menos a tipos como a mí), todo se debía a un "malentendido".

En efecto, imaginaros la situación:

1º Tengo dos casillas en una aplicación y dos botones: cifrar y descifrar.

2º Cifro el texto de la primera casilla, lo codifico en "base 64" y lo sitúo en la segunda casilla.

3º Descifro el texto de la segunda casilla para obtener el texto original.

Hasta aquí todo correcto, excepto la inquietante cifra máxima de 60.000 caracteres. En efecto, nunca puedo obtener texto en claro más allá de esa cifra, y, de hecho la segunda casilla nunca llega a guardar más de esa misma cifra. ¿Qué está pasando aquí?

Lo más obvio (ahora que se sabe): ¡las casillas del programa "madre" de mi DLL están configuradas, por defecto, para tener ese límite máximo de caracteres!

En fin, no voy a decir que la ayuda del programa está errada en esta cuestión pues indica que si se establece como límite un "0", esto significa que no hay límite... pero lo cierto es que sí que lo hay (60.000) si se deja tal cual ese "0". Como digo la ayuda está errada, pero, no voy a culparla porque yo ni siquiera he mirado ahí.

He tenido que hacer varias pruebas por mi cuenta para llegar a dicha conclusión. Y bueno, al final el problema se ha solucionado, aunque, como he dicho más arriba, no uso Indy para realizar la codificación, sino esta otra unidad (espero no estar infringiendo copyright alguno...), que usa la API de Windows y funciona como se espera: aunque insisto en que muy probablemente Indy funciona bien y el fallo está en otro sitio, pero, no tengo tiempo ni ganas para ponerme ahora a investigar sobre este asunto, mucho menos después de haber comprendido y solucionado el problema.

¡Gracias a todos vosotros!

[Casimiro Notevi]

Todo tiene solución , bueno, casi todo

[dec]

Hola,

Empezado por Casimiro Notevi

Todo tiene solución , bueno, casi todo

¿Para qué preocuparnos por lo que tiene solución o por lo que no la tiene? Algo así dicen que dijo un mono sabio. Pero quien no es profesional corre el riesgo de entrar en miedo pánico. ¡Piensa que acaba de abrirse la tierra bajo sus pies! Un error que se añade al primero: errores. Pero en fin... al menos espero haber aprendido algo esta vez.

¡Gracias a todos!

[Casimiro Notevi]

Empezado por dec

¿Para qué preocuparnos por lo que tiene solución o por lo que no la tiene? Algo así dicen que dijo un mono sabio.

Vaya, yo siempre he dicho eso

[dec]

Empezado por Casimiro Notevi

Vaya, yo siempre he dicho eso

Bueno; es que todos somos monos... y algunos más sabios que otros.

[[escafandra]]

Empezado por dec

... al final el problema se ha solucionado, aunque, como he dicho más arriba, no uso Indy para realizar la codificación, sino esta otra unidad (espero no estar infringiendo copyright alguno...), que usa la API de Windows y funciona como se espera...

Esa unit dista bien poco del código que te dejé aunque no testa el fallo en la llamada a la API.

Ten en cuenta que base64 no es un sistema seguro de encriptación, no se si esto es importante para tu propósito.

Me alegra que hayas encontrado la solución.


Saludos.

[roman]

Yo lo que entendí es que está haciendo ambas cosas: cifrar y codificar en base 64.

// Saludos

[dec]

Hola a todos,

Empezado por escafandra

Esa unit dista bien poco del código que te dejé aunque no testa el fallo en la llamada a la API.

Ten en cuenta que base64 no es un sistema seguro de encriptación, no se si esto es importante para tu propósito.

Me alegra que hayas encontrado la solución.


Saludos.

Gracias escafandra. En efecto me decidí por la unidad referida por usar la API de Windows, tal como aconsejaste. Además encontré útil la unidad puesto que implementa las dos funciones necesarias, con ciertos añadidos, además, que acaso también puedan servirme de algo. Respecto de que habría que validar la API, llevas razón, y seguramente haré los cambios necesarios para que se lleve a cabo. Espérate que no envuelva la unidad en una clase que ofrezca varias características.

Empezado por roman

Yo lo que entendí es que está haciendo ambas cosas: cifrar y codificar en base 64.

// Saludos

Eso es Román. Primero la cadena se cifra con un determinado algoritmo, y, después, para poder guardar el resultado (el texto cifrado) en una cadena de texto (y no en binario) se codifica en "base 64".

¡Gracias de nuevo a todos!

[Julián]

Yo tuve los mismos problemas y también los solucioné usando base64. De hecho, hace muy poquito he vuelto a tenerlos, en javascript y php: en la nueva versión de gestor de contenidos/framework o lo que sea, existe la opción de guardar la contraseñas cifradas en una cokie y tambien se cifra antes de enviarla mediante post al hacer login. Bien, pues también uso Base64 para convertir a string.
Ah, y en Delphi tampoco usaba Indy, sino una función hecha en object Pascal, que alguien escribió alguna vez.

[dec]

Hola,

Así es Julián, no somos pocos los que nos hemos topado con este problema y hemos tomado "base 64" como solución.