El método de Sun no encripta el jar. Cualquiera lo puede leer y
ejecutar, la firma sólo permite verificar el autor del jar.
El método de exigir un password en el constructor de una clase es
débil, es trivial obtener el password descompilando el jar o incluso
con el comando strings en unix, a menos que se aplique una función no
reversible al password al momento de verificarlo, por ejemplo usando
un hash del password, pero es muy fácil de atacar un hash con fuerza
bruta.
Pienso que lo mejor es usar una combinación de ambos métodos: una
clase en el jar podría estar encriptada con la clave pública del
usuario autorizado, y esa clase sería cargada explícitamente con un
classloader que usaría la clave privada del usuario para
desencriptarla. Todo el jar estaría firmado con la clave privada del
proveedor del jar usando el método de Sun, de modo que cualquier
modificación sería detectada. Cualquier ataque requiere acceso a la
clase privada del usuario autorizado.
On 18 jul, 18:55, "Oscar Berganza" <
oscarberga...@gmail.com> wrote:
> BUeno la realidad es que yo he hecho los JAR CON netbeans y asi como los he
> contruido. me referia a que le pusiseras una contraseña en el contructor de
> la clase fija con programacion
>
> 2008/7/15 Edson Chavez <
edsoncha...@gmail.com>:
>
>
>
> > te refieres a que el jar este protegido para poder descomprimirlo o algo
> > similar?
>
> > recuerda que los jar se comprimen con archivo zip
>
> > saludos
> > Edson
>
> > 2008/7/14 Oscar Berganza <
oscarberga...@gmail.com>:
>
> >> tu pregunta es interesante, lo que si puedes hacer es poner una contraseña
> >> fija es decir mandarle como parametros lo que quieres que sea tu contraseña
> >> al momento de crear el objeto, bueno a mi se me ocurre de es forma saludos
>
> >> 2008/7/4 Fedex <
fedemtz...@gmail.com>: