Guid salt - cadena vs bytes []

En pocas palabras, desea maximizar la cantidad de entropía para una longitud de datos determinada, al realizar la mayoría de las tareas criptográficas.

Tiene (a lo sumo) 16 bytes de entropía en su GUID, probablemente menos (algunos de los bits son deterministas), pero podemos ignorar ese detalle para la discusión actual. Cuando se utiliza la representación del byte [] del GUID como sal, tiene 16 bytes de datos. Eso es como máximo 16 bytes de entropía / 16 bytes de datos = 1 byte de entropía por byte de datos, asumiendo un GUID completamente aleatorio. Ahora suponga que utiliza la representación de cadena. Eso es 36 bytes de datos, pero aún como máximo 16 bytes de entropía. Eso da como resultado menos de la mitad de la entropía por byte de datos (aproximadamente una relación de entropía / datos de 0.44 en comparación con el byte compacto []), que es problemático para algunos algoritmos de hashing.

¿Cuándo podría surgir esto?

Para tomar un ejemplo artificial (justo en la parte superior de mi cabeza, realmente no recomendaría hacerlo), considere bcrypt. bcrypt es un algoritmo de hashing de contraseñas que, por razones técnicas, limita la contraseña a 72 bytes . Incluye su propia sal, pero supongamos, por el bien del argumento, que no confía en su sal (de nuevo, esto no es un consejo, solo un ejemplo).

Entonces, decide prefijar la contraseña del usuario con un GUID, antes de introducirla en bcrypt. Si ha usado la versión de byte [], eso acorta el límite superior efectivo en la longitud de la contraseña en 16 bytes. Por lo tanto, el usuario puede proporcionar una contraseña de 56 bytes, como máximo. Eso está bien, aún son más de 50 caracteres ASCII, que es una longitud común que usan las personas cuando tienen un administrador de contraseñas y son un poco paranoicos.

Ahora, supongamos que ha usado la versión de cadena en su lugar. Todavía tiene la misma cantidad de entropía, pero ahora consume 36 bytes que el usuario podría haber estado usando para rellenar su contraseña. Ahora están atrapados con una contraseña de 36 bytes como máximo.

Y eso es solo un ejemplo de la parte superior de mi cabeza; Estoy seguro de que hay otros casos en los que usar la versión de cadena te haría daño.

La sal no es realmente una entropía. Lo que deben lograr las sales es unicidad : tanto como sea posible, nunca intente reutilizar un valor de sal (incluso si cambia la contraseña para el mismo usuario). GUID son buenos para eso. La aleatoriedad es un buen método para lograr ese tipo de singularidad con una probabilidad abrumadora (es "bueno" porque no necesita ningún tipo de directorio mundial).

Por singularidad, GUID-encoded-as-bytes y GUID-encoded-as-string son completamente equivalentes , ya que la conversión entre las dos codificaciones funciona en ambas direcciones: dos GUID que se codifican como secuencias distintas de Los bytes también se codificarán como cadenas distintas y viceversa. No importa que una codificación tenga "más entropía por carácter" o cualquier otra idea, porque la entropía es irrelevante para las sales. (O, dicho de otro modo, cuando la concentración de entropía es importante para una sal, entonces no es una sal, sino otra cosa).

Sin embargo , los algoritmos de hashing de contraseña y los formatos de archivo existentes pueden ser exigentes con respecto a las sales. Por ejemplo, el artículo que especifica bcrypt (*) dice que la sal tiene la longitud es exactamente de 128 bits, por lo que, presumiblemente, si intenta alimentar una implementación bcrypt con cadenas de 36 caracteres, pueden suceder cosas malas (por ejemplo, la implementación solo usa los primeros 16 caracteres, ignorando el resto). La singularidad de GUID se garantiza solo cuando se utiliza el GUID completo , en la codificación que eligió.

En una nota más práctica, ya que ambas codificaciones logran la misma singularidad, también puede preferir usar la más corta de las dos, para ahorrar espacio en su base de datos. Sin embargo, tenga cuidado con cualquier manejo inadecuado de los datos binarios (por ejemplo, utilizando bytes como si fueran una cadena que termina en el primer byte de valor 0). A la inversa, dado que la mayoría de los algoritmos de hashing de contraseña esperan bytes para el salt, debe tener cuidado de especificar una codificación no ambigua si desea almacenar sales como cadenas de caracteres .

^{(*) Si bien el artículo especifica bcrypt, los autores de bcrypt tienden a considerar que la especificación de bcrypt real es la implementación de referencia; en ese sentido, la longitud de sal aceptable real para bcrypt es "lo que la implementación de referencia acepta utilizar".}