youtuber tag preguntas para novio las hipocrita hacer con canciones amigos c encryption licensing key product

para - tag del youtuber hipocrita preguntas



implementación de claves de producto (5)

Estoy implementando una pequeña aplicación en C, que me gustaría vender como shareware a un precio razonable más adelante. Comenzará con una prueba de 30 días, que ya estoy bastante seguro de cómo implementarlo.

El problema que tengo, sin embargo, es que no estoy muy seguro de cómo implementar la verificación de la clave del producto. Lo que tengo en mente es que el cliente puede registrarse en mi página web (después de probar el producto por un tiempo), pagar por el producto y obtener una clave de producto en forma de aaaaa-bbbbb-ccccc-ddddd-eeeee a través de e -mail (o tal vez disponible a través de su perfil en mi sitio web). No hay problema hasta el momento. Luego, él / ella suelta la llave en los campos clave correspondientes en mi aplicación y la aplicación está registrada.

De lo que pude reunir hasta ahora, las personas recomiendan AES o RSA para esto. Para ser honesto, en otra dirección en la universidad (no en criptografía) y la clase de criptografía que tomé fue hace algún tiempo. Pero por lo que recuerdo, AES es un algoritmo de cifrado simétrico, lo que significaría que solo tendría una clave para cifrado y descifrado, ¿no? ¿Cómo podría generar miles de claves de producto y aún validarlas en mi aplicación (que, por cierto, no requerirá acceso a Internet ... por lo que no volveré a consultar con un servidor)?

¿Entonces supongo que RSA sería el camino a seguir? Pero, ¿no produce RSA teclas bastante largas (al menos más largas que los 25 caracteres necesarios de arriba)?

En otro hilo , leí que algunos productos ni siquiera usarán encriptación para la generación / verificación de claves de producto, sino que emplean algunas comprobaciones como "agregar el carácter 2. y el 17. y eso debería sumar a x".

¿Cuál es la forma más rápida, fácil y segura de ir aquí? :-) ¡Las muestras de código serían azúcar!

Saludos,

Sebastian

PD: Ah ... y por favor no me digan cómo mi clave puede y será resquebrajada en algún momento ... Sé de eso, que es principalmente la razón por la que no quiero pasar mucho tiempo con este problema, pero al mismo tiempo no lo hace demasiado fácil para el cracker ocasional.

Los algoritmos simétricos son limitados, en el sentido de que cualquier cracker novato con un desensamblador puede encontrar su clave (o el algoritmo utilizado para generarla) y hacer un "keygen".

Por esta razón, la criptología asimétrica es el camino a seguir. La premisa básica es algo como esto:

  • Cuando el usuario le compra una licencia, usted recopila ciertos detalles de identificación sobre el usuario y / o su entorno (generalmente, este es solo un nombre completo, a veces también una empresa).
  • Usted hace un hash MD5 de 128 bits de esta información.
  • Usando una criptografía de curva elíptica de 128 bits, encripte este hash usando la clave privada en el servidor.
  • El texto de cifrado de 128 bits se puede representar para el usuario como una cadena de 25 caracteres que consta de letras y dígitos (además de separar guiones para facilitar la lectura). Observe que 26 letras + 10 dígitos = 36 valores discretos, y que 36 ^ 25> 2 ^ 128.
  • El usuario escribe esta clave de producto en su cuadro de diálogo de registro. El software del cliente lo convierte de nuevo a un número de 128 bits (16 bytes), descifra el que usa la clave pública de su criptografía EC y compara el resultado con un hash MD5 de la información personal del usuario, que debe coincidir con el utilizado para el registro .

Esta es solo la idea básica, por supuesto. Para obtener más detalles y el código fuente, consulte Claves de producto basadas en criptografía de curva elíptica .

Puede consultar este artículo de Code Project . Describe una implementación de una clave de software basada en la dirección MAC de la máquina donde se ejecuta el software. El método no es ideal, como admite el propio autor, y es un poco diferente de lo que está buscando, pero tal vez pueda ayudarlo.

Sí, RSA y AES son dos cosas muy diferentes:

  • RSA es una criptografía de clave pública, que implica una clave pública y una clave privada, y es bastante lenta. El uso principal es configurar un intercambio seguro de una clave de sesión de cifrado simétrica.
  • AES es una encriptación simétrica, que es rápida y segura.

Como su aplicación no se comunica a través de canales públicos y el uso de la criptografía está limitado a la activación / registro del producto, le conviene usar un cifrado simétrico. Los beneficios de los cifrados de clave pública se encuentran en la administración de claves, que usted manejará en su sitio web o por correo electrónico.

Tenga en cuenta que no tiene que distribuir la misma clave para cada cliente. Podría generar un hash de parte de la información de registro y XOR con otra cosa (una clave de sesión fija, tal vez). Envíelo al cliente, y el programa podría generar el mismo hash y XOR la ​​clave que envió para producir la clave fija original.

Lidiar con la criptografía no es algo que deba hacerse a la ligera. Como mencionas, esperas que esto se resquebraje. Si estás haciendo lo tuyo, esto seguramente sucederá. Todavía puede usar su propia implementación para "mantener a las personas honestas honestas", pero se da cuenta de que eso es todo lo que obtendrá. Si necesita algo más sólido, debe comprar una solución después de realizar una investigación exhaustiva de las soluciones.