2011-02-16 15 views
7

¿Es posible y vale la pena intentar desarrollar alguna aplicación de servidor usando Android NDK que encriptará datos (o simplemente usará una biblioteca de cifrado Linux incorporada) que se le pasa desde Java normal aplicación basada?Usando Android NDK para el cifrado de datos pasados ​​desde la aplicación normal de Android

Intenté usar la biblioteca de cifrado, pero me llevó casi un minuto encriptar un archivo de 2MB con AES. Y blowfish no está disponible en Cipher hasta Android 2.3 (?). Y dudo que sea mucho más rápido.

Estaba usando blowfish para el cifrado en Symbian y fue mucho más rápido (menos de 5-10 segundos), así que creo que en Android es más lento porque uso la máquina virtual Java y me gustaría probar la aplicación nativa.

¿Alguien lo ha hecho antes?

EDITAR: El cifrado en NDK es mucho más rápido. Hazlo allí. Hay una pregunta similar con la misma respuesta para AES: AES decryption on Android too slow to be usable. Will NDK be faster? Other ideas?

+0

Implementé bastante algoritmos criptográficos en Java y es mucho más lento que C/C++ en este sentido. No conseguí que Skein corriera mucho más rápido que 100 MB/s ejecutándose en Oracle JVM.Si implementa AES, intente obtener un buen bucle desenrollado (por ejemplo, 8 rondas en una iteración) y asegúrese de que su aplicación no realice ninguna copia de memoria innecesaria. –

+0

Estoy tratando de implementar AES en el NDK también. ¿Podrías compartir lo que hiciste? ¿Usó algún otro proveedor para AES en su proyecto NDK, o implementó su propia implementación? –

+0

Estoy usando blowfish, y la implementación fue tomada desde [allí] (http://www.schneier.com/blowfish.html). – shtolik

Respuesta

1

¿Con qué versión de Android está probando? Tenga en cuenta que, comenzando con Froyo, hay un JIT de rastreo que debería funcionar bastante bien para los bucles intensivos en matemáticas en una biblioteca de cifrado.

Para versiones anteriores, es probable que desee hacerlo con el NDK, sí. Sin embargo, no sé por qué necesitas un servidor: simplemente compila cualquier biblioteca de criptografía buena/rápida y haz una envoltura alrededor de ella usando el NDK. Entonces, simplemente puede usar el contenedor desde su aplicación basada en Java.

+0

No hubo una gran diferencia entre encriptar en froyo y versiones anteriores. Pero después de haberlo implementado en NDK, el archivo de 1MB se encripta en aproximadamente 1 segundo (en comparación con 30 - 60 segundos usando gnuCrypto java lib). Así que consideraré su respuesta correcta, hágalo en NDK. – shtolik

1

Para responder a su pregunta, sí, probablemente podría escribir algo que se ejecutará con el NDK, pero no veo por qué lo necesitaría.

Si lo que desea es cifrar los datos que se van al almacenamiento de SQL se puede extraer SQLCipher (https://guardianproject.info/code/sqlcipher/)

También puede intentar utilizar algunas bibliotecas castillo hinchable (http://www.bouncycastle.org/java.html). Pueden ser más rápidos que los integrados en Android o pueden tener una biblioteca blowfish que puedes usar.

+0

Si utiliza bibliotecas de castillo hinchable, creo que tendrá que modificarlas un poco, porque ya están en la pila de Android, pero no son públicas para el desarrollador de la aplicación. –

0

Esto no es código abierto, pero el punto de vista del rendimiento Chillkat es el mejor que he encontrado.

0

Por supuesto, es posible usar la biblioteca externa para hacer crypto. Puede usar openssl por ejemplo https://github.com/guardianproject/openssl-android. La única pregunta es qué tan grande será el impacto de la capa JNI que existe entre Java y el código C. Si necesita pasar una gran cantidad de datos a C y viceversa, la capa JNI puede negar el beneficio de tener una biblioteca nativa. Sería mucho mejor mover más funcionalidades de Java a C de una manera que los datos que deberían ser encriptados podrían procesarse solo en C. Por ejemplo, la pila de red y el cifrado podrían estar en C mientras que la interfaz de usuario en Java. Esta es solo una propuesta que debería saber mejor si esto es posible o no.

2

BouncyCastle en Android 2.2 es terriblemente lento con AES/CBC/PKCS5 mientras usa descifrado de flujo. La CPU va al 100% y el rendimiento es de 5kb/seg.

El uso de Chilkat es mucho más rápido y mantiene el uso de CPU bajo (incluso en el emulador). Pero Chilkat no está ofreciendo un InputStream para manejar el descifrado de flujo y está almacenando en el búfer todos los bytes encriptados internamente (hasta que ocurra un error de espacio en el montón). Por lo tanto, usted debe administrar el descifrado de la cadena usted mismo (por ejemplo, inicializando chilkat para cada bloque ...)