Encriptar la .class

Tal vez esto te sirva

• http://stackoverflow.com/questions/49379/how-to-lock-compiled-java-classes-to-prevent-decompilation
• http://www.zelix.com/

Lee algo acerca de cifrado simétrico vs asimétrico. El problema con el cifrado simétrico (el que estás manejando como César y XOR) es que se usa la misma llave para cifrar y descifrar, por lo tanto debes tenerla a la mano. En general, el problema de que una aplicación pueda descifrar datos sin intervención externa siempre es el mismo: la llave debe estar disponible en algún lugar, ya sea guardada en un archivo, o que se pueda generar de cierta forma, pero debe estar disponible y por tanto, con cierto grado de dificultar, siempre alguien podrá encontrarla o derivarla para poder descifrar esos datos. Por eso DRM no sirve.

Aunque ahora que lo pienso, usar una cifra asimétrica (como RSA) no resuelve nada, porque aunque los datos los hayas cifrado con una llave privada, la llave pública debe estar disponible a la aplicación para descifrarlos.

Lo más que puedes hacer es generar la llave de alguna forma, en vez de tenerla como una cadena en código duro, y ofuscar ese código.

Otra opción sería que almacenaras tu llave (key) en un keystore. Cuando vayas a cifrar/descifrar obtienes la llave de tu keystore. De esa manera tu llave permanecerá segura. El pequeño inconveniente es que necesitarás almacenar la información para poder accesar al keystore, pero ahí ya depende de qué tan seguro quieras implementar esa parte. Podrías guardar esa información en un .properties o tener un servicio que te proporcione esa información, o hasta directamente la llave, etc.

Usar una keystore solamente agrega un nivel de indirección, pero no resuelve el problema. La llave final está en la keystore, pero para abrir la keystore se necesita otra llave. Si vas a guardar una llave en un .properties o cualquier formato de archivo, en claro, da igual usar una keystore o guardar directamente la llave final.

Cualquier cosa que encriptes en el código deberá de ser desencriptada para poderse ejecutar, en la comunidad de java.net había muchos usuarios famosos por interceptar el código encriptado que venía en los java web start ( en ese entonces se suponía que era la forma idónea por bajar el ejecutable compilado en flujos y ejecutarlo en el sistema ), pero para poderse ejecutar, el mismo java web start debía de desencriptarlo pasando por una jvm que lo ejecutaría, allí era donde los juackers atrapaban el código y lo guardaban para posteriormente pasarle un jad o un jode y obtener el código fuente.

Siempre habrá una forma... pero si lo que buscas es eludir a una vasta mayoría, yo metería el password hasheado en los bits alpha de alguna de las imágenes que se usen en la interfaz gráfica, y usarla con un servicio web para conceder el acceso con una conexión encriptada ( pienso que meterle rsa y cambair las contraseñas por cada conexión sería ya algo excesivo, además de que las modificaciones a la imágen serían perceptibles con el tiempo ) .

bytes.

Bueno, primeramente la seguridad no es una broma, es un tema al que le tenemos que tener respeto, porque sin ella nuestras aplicaciones son vulnerables.

Tus claves, en lo general no debes de tenerlas hardcoding en tus aplicaciones, porque cualquiera con tres dedos de frente podría obtener acceso a ellas.

Te recomiendo que todo lo relacionado a las keys de tus implementaciones, las mantengas en un almacén (store, keystore, db) de claves, y uses el esquema que mas te convenga.

La seguridad de estos archivos, quedaran a nivel de usuarios de filesystems o db, pero no puedes mantenerlas dentro de tus códigos, imagínate que cambie, tendrás que compilar y desplegar nuevamente, y esto no es optimo en ninguna manera.