Implementar AES-256 para delphi y .Net que sean compatible

[erickperez6]

Saludos,

necesito generar cifrados en AES desde delphi y .Net, y que estos sean compatibles uno con el otro (es decir, que lo pueda cifrar en uno, luego descifrarlo en el otro y viceversa), he probado casi todos los componente que son de dominio publico, algunos encontrados en el foro del clubdelphi, la mayoria no son compatibles entre si y mucho menos con el nativo que trae .Net

Buscando mucho por internet, muchas personas sugieren que lo unico seguro para que sean compatibles es utilizar uno implementado en delphi en un dll e invocarlo desde .Net, asi se estara usando exactamente el mismo recurso, pero para mi caso no puedo hacer esto porque este recurso (del lado de .Net) lo necesito correr bajo Mono en linux, y esta dll en delphi no andara en mono obviamente (ademas ya lo probe). Estoy convencido que la unica solucion es tener un recurso nativo para delphi y otro nativo para .Net y que sean compatible entre si, pero no logro dar con ellos.

Incluso me olvidaria del AES, si encuentro otro similar que si sean compatibles, lo que ando buscando es algo que pueda pasarle una clave secreta para cifrar/descifrar y que sea un algoritmo confiable, alguien conoce alguno?.

Nota: el RSA no es lo que ando buscando, ya que no utiliza una clave secreta que asigna el usuario, sino una llave secreta autogenerada que se necesita almacenar en un archivo con un contenido aleatorio e imposible de memorizar.

[[escafandra]]

Quizás esto te interese.

Saludos.

[[Al González]]

Empezado por erickperez6

[...] y mucho menos con el nativo que trae .Net

¿Qué tendrá de especial el algoritmo AES nativo de .NET para que no sea compatible con alguno de los componentes que has utilizado? ¿Qué dice la documentación de .NET sobre cuál variante de AES utiliza?

Saludos.

[erickperez6]

Empezado por Al González

¿Qué tendrá de especial el algoritmo AES nativo de .NET para que no sea compatible con alguno de los componentes que has utilizado? ¿Qué dice la documentación de .NET sobre cuál variante de AES utiliza?

Saludos.

El .Net utiliza el Rijndael y en la version 4 del framework ya esta la disponibilidad de usar la variante estandard del AES, pero la mas conocida y utilizada es la primera.

Sobre el enlace que me recomienda escafandra ya lo habia visto y probado, al igual que algunos 3 o 4 componentes mas para delphi (DCPcrypt, AESlib, etc.) que permiten usar el algoritmo AES, en su mayoria utilizan la variante Rijndael pero extrañamente no son compatibles unos con los otros, cada uno me arroja un cifrado diferente y solo los puedo descifrar con el mismo componente que lo genere.

Pero investigando sus codigo fuentes y analizando el que trae el framework del .Net puedo decir que estas "discrepancias" se debe a que cada uno de ellos utilizan algunas "maniobras" adicionales (o carecen de algunas) para generar el cifrado/descifrado final, como por ejemplo hashear la llave antes de utilizarla, uso de vectores de inicializacion por medio de un salt o segunda llave, algunos utilizan diferentes modos de encriptacion (cbc, cfb, cts, etc.), tamaño de bit para la llave (128, 192, 256). En fin, un sin numeros de variables que hace que cada libreria trabaje diferente.

Por lo menos la que trae .Net es muy flexible y completa, esta permite configurar cualquier caracteristica del cifrado a diferencia de los recursos que aparecen para delphi que son mas sencillos y sin acceso a cambiar algunas caracteristicas del cifrado, ya que estan desarrollado para que trabajen de una sola manera.

Bueno, como realmente necesito algun cifrado compatible con delphi y .Net, pense que la unica solucion es migrar el codigo fuente de algun algoritmo de cifrado desde delphi a .Net o viceversa y asegurarme que trabajen exactamente iguales, pero como soy mas diestro entendiendo C# que pascal/delphi a un bajo nivel, pues me es mas facil y claro digerir un codigo fuente en C# para luego traducirlo a delphi. Asi que me tope con las librerias de seguridad de BouncyCastle, super completas, con muchos algoritmo de cifrados y su respectivo codigo fuente (open source), probe el AES de Rijndael, permite cambiar cualquier caracteristicas del cifrado, muy flexible, y lo es mejor: compatible con el mismo que trae el Framework de microsoft.

Ya comencé a migrar un algoritmo mas sencillo que el AES, pero funcional (no quiero quemar mucha pestaña), tambien implemente una libreria mas sencilla de invocar y trabajar en .Net con el BouncyCastle ya que esta no viene con nada de documentacion y es un poco compleja para ponerla a trabajar. Luego que termine, liberare los codigos para que cualquiera pueda usarlos en delphi y .Net

[[Al González]]

Hola Erick.

Muy loable el estudio que has venido haciendo de esas bibliotecas y más aún que compartas con la comunidad el resultado de tu trabajo.

De momento se me ocurre que, para salir del paso, podrías encapsular en una DLL algunas de las funciones que has encontrado y probado en Delphi, y así poder usarlas también desde .NET. ¿No has considerado esta opción?

[erickperez6]

Empezado por Al González

Hola Erick.

Muy loable el estudio que has venido haciendo de esas bibliotecas y más aún que compartas con la comunidad el resultado de tu trabajo.

De momento se me ocurre que, para salir del paso, podrías encapsular en una DLL algunas de las funciones que has encontrado y probado en Delphi, y así poder usarlas también desde .NET. ¿No has considerado esta opción?

Si, por su puesto, ya lo había pensado, en el primer post de este hilo, mencione lo de crear una dll en delphi y usarla en .Net, incluso ya lo habia probado, el problema es que la aplicacion .Net debe tener compatibilidad en Mono (implementacion de .Net para linux), y estas dll hechas en delphi "en teoria y a duras penas" quizas deberian correr en Mono, si no uso recursos propios del sistema operativo Windows, pero en la practica me fue imposible.

[[Al González]]

¡Cierto! Disculpa, esta memoria mía.

Leyendo nuevamente tu primer mensaje, veo que estás dispuesto a usar otro método de cifrado mientras sea confiable. Y que descartas RSA por que necesitarías el archivo llave.

Quiero pensar que para RSA y similares deben existir funciones a las que no necesariamente tengas que darle una ruta de archivo, sino, por ejemplo, un buffer o un flujo ("stream"). Esto pensando en que puedas guardar la llave en la base de datos de la aplicación más que en un archivo. Además, ¿por qué debe ser una clave fácil de memorizar?

Por otra parte, cuando mencionas que necesitas un algoritmo confiable, ¿a qué nivel de seguridad te refieres? Porque en algunos casos puede bastar un algoritmo casero que uno mismo haga, mediante movimiento, sumas y restas de bytes usando como "factor" una contraseña típica.