¿Cuál es el cifrado detrás de los códigos canjeables?

Es una buena apuesta que cada compañía tenga su propia forma de hacerlo. Edgar Chris ha sugerido un algoritmo anclado por el usuario, pero para los códigos genéricos transferibles (por ejemplo, códigos de tarjetas de regalo de iTunes), puede mantener un contador en serie para cada tipo de regalo por separado (por ejemplo, tarjetas de regalo de $ 10 frente a $ 50), luego use el siguiente algoritmo:

  1. Genere el siguiente número de serie N.
  2. Genere una sal S que se base en el código de tipo de regalo C (por ejemplo, siembre su PRNG favorito con C , luego use el noveno número generado como S ).
  3. Calcule un hash H del par (N, S).
  4. Base36-encode (C, N, H) para obtener su código de regalo. Probablemente quiera quitar los bits de alto orden de C y N no utilizados para compactar el código tanto como sea posible.

El algoritmo de verificación se deja como ejercicio para el lector.

ACTUALIZACIÓN: Gracias a Jeffrey Goldberg por recordarme que un Código de autenticación de mensajes como HMAC tiene un mejor propósito que un simple hash en el paso 3, y la mayor complejidad computacional es trivial e irrelevante para este caso de uso. El uso de un MAC también hace innecesaria la generación de sal, por lo que mi algoritmo revisado sería:

  1. Genere el siguiente número de serie N.
  2. Calcule un HMAC H del par (N, C).
  3. Base36-encode (C, N, H) para obtener su código de regalo. Probablemente quiera quitar los bits de alto orden de C y N no utilizados para compactar el código tanto como sea posible.

Solo puedo adivinar, pero una forma de hacerlo es con un MAC (Código de autenticación de mensaje). Entonces, la información no secreta (o no necesariamente secreta) se codificaría y luego se le daría a algún algoritmo MAC (como HMAC) con una clave secreta para producir una etiqueta. La etiqueta es una función matemática de los datos y el secreto.

De esta manera, se debe conocer un secreto cuando se genera la etiqueta del código de canje, y este mismo secreto debe conocerse cuando se verifica.

Sería posible hacer esto usando firmas digitales, para que el secreto no tenga que ser conocido cuando se verifica la etiqueta (solo cuando se genera). Pero eso requeriría etiquetas más largas, por lo que sospecho que se usa un MAC típico con etiquetas truncadas.

Cuando tengo códigos implícitos como este, no hay cifrado. El código tiene que ser aleatorio, por lo que es difícil de adivinar.

Cada código generalmente tiene algún tipo de crc adjunto, por lo que se puede hacer una verificación muy rápida cuando se ingresa en una computadora.

La verificación principal es que cada código que se emite se rastrea en una base de datos. Está marcado, en la base de datos, como canjeado cuando se usa.

No creo que códigos como este se usen con cosas de alto valor.

Realmente no puedo decir cómo hacen su hashing, pero si yo fuera el que hacía el hashing … tos … cómo lo haría para lograr lo mismo
1. tenga un método de hash que primero indique la cuenta de correo electrónico o ID de los usuarios
algo que podría usar para saber quién es el usuario
esto resuelve dos cosas primero, un usuario que no existe en nuestra base de datos no puede tener esto y, en segundo lugar , tenemos la parte del cifrado que es única para el usuario y siempre comenzará con los mismos caracteres

2. como se trata de un tipo de código canjeable, haga que el valor del código de canje sea parte de la cadena enviada a los clientes
3. tenga un método diferente para mezclar algunos caracteres de variable aleatoria y úselo para salar el primero

el cheque se verificaría fácilmente si la primera parte del hash coincide si es que tenemos un usuario válido, verifique si la sal también pasa, entonces tenemos un reclamo válido y, por último, verifica si el código de canje tiene valor y el cliente puede redimir