SJCL: convierte ascii a BitArray y calcula números aleatorios

Sin mirar los números exactos, permítanme dar algunas sugerencias sobre por qué sucede esto:

1. Según los documentos , a veces utilizará algunos bits adicionales para almacenar más información (a saber, el número real de bytes):

     

   La mayoría de nuestros primitivos criptográficos operan en matrices de palabras de 4 bytes internamente, pero muchas de ellas pueden tomar argumentos que no son un múltiplo de 4 bytes. Esta biblioteca codifica matrices de bits ( cuyo tamaño no necesita ser un múltiplo de 8 bits ) como matrices de palabras de 32 bits. Los bits están empaquetados, big-endian, en una serie de palabras, 32 bits a la vez. Como las palabras son números de punto flotante de doble precisión, se ajustan a algunos datos adicionales . Usamos esto (de una manera privada, posiblemente cambiante) para codificar el número de bits realmente presente en la última palabra de la matriz .

        

   Debido a que las operaciones a nivel de bits borran estos datos fuera de banda, estas matrices se pueden pasar a cifrados como AES que desean matrices de palabras.

   Eso probablemente explica el bit extra que se está agregando, y también explica por qué concatenar dos BitArray s no concatenará simplemente la palabra arrays, como parece que estás esperando. Si el primero tuviera un múltiplo de 4 bytes, entonces sí, eso es lo que sucedería.

2. Si recuerdo correctamente, SJCL intentará usar la funcionalidad criptográfica de los navegadores modernos para crear su generador de números aleatorios, recurriendo a uno personalizado (que utiliza movimientos del mouse, pulsaciones de teclas, etc. para generar entropía adicional). combinarse con un PRNG [no criptográfico]. Eso significa que en el navegador moderno no es importante si establece paranoia o no. En los navegadores más antiguos (o en los que no admiten crypto ), realmente debe poner en funcionamiento los recopiladores si planea usar algoritmos que dependen de un CSPRNG. Te ayudaría más, pero nunca usé esa funcionalidad, así que solo puedo dirigirte a los documentos .

P.S. US-ASCII es un subconjunto de UTF-8, por lo que no necesita convertir primero a Hex y luego a BitArray. Solo usa sjcl.codec.utf8String.toBits(str) . (Pensándolo bien, ¿cómo sabe que su texto es realmente ASCII? SJCL [normalmente] se ejecuta en un navegador ... Es mejor estar seguro y hacer que su código sea compatible con Unicode)

La razón por la que BitArray contiene ints > 32bits es que codec.hex.toBits asume que la cadena hexadecimal suministrada tiene una longitud de múltiplo de 8. Probablemente esto se deba a que el códec está diseñado para uso interno, pero pensé que lo mencionaría aquí porque no encontré ninguna indicación de esta limitación en ninguna otra documentación o discusión de SJCL.

Para ejecutar texto arbitrario a través de toBits, podría rellenar con cero la parte frontal de la representación de la cadena hex para obtener una cadena hexadecimal de longitud% 8 = 0.