La corrupción de datos: ¿Dónde está la bug?

Question

Última edición: que he descubierto cuál era el problema (ver mi propia respuesta a continuación) pero no puede marcar la pregunta como respondida, parecería. Si alguien puede responder a las preguntas que tengo en mi respuesta a continuación, es decir, se trata de un error en Cython o es comportamiento previsto de este Cython, que marcará que respuesta como aceptada, porque eso sería el más útil lección para obtener de esta, en mi humilde opinión.

---

En primer lugar, tengo que empezar diciendo que he estado tratando de resolver esto durante tres días, y sólo estoy golpeando mi cabeza contra la pared. Lo mejor que puedo decir de la documentación, que estoy haciendo las cosas correctamente. Obviamente, no puedo estar haciendo las cosas correctamente, sin embargo, porque si lo fuera, no tendría un problema (¿verdad?).

En cualquier caso, estoy trabajando en un enlace para mcrypt a Python. Se debe trabajar tanto con Python 2 y Python 3 (aunque es probado para Python 2). Está disponible en mi sitio , vinculado porque es demasiado grande incluir en el mensaje, y dado que no sé lo que estoy haciendo mal, ni siquiera puedo aislar lo que podría ser el código de problema. La secuencia de comandos que muestra el problema es también en mi sitio . El guión simplemente alimenta con 100 bloques de nada más que la letra "a" (en cualquier tamaño de bloque de los usos del modo de algoritmo de cifrado / encriptación), y por supuesto debe recibir un bloque de "a" como resultado de Roundtripping. Pero no (siempre). Aquí se emite desde una única prueba de ello:

Wed Dec 15 10:35:44 EST 2010
test.py:5: McryptSecurityWarning: get_key() is not recommended
  return ''.join(['{:02x}'.format(x) for x in o.get_key()])

key: b'\x01ez\xd5\xa9\xf9\x1f)\xa0G\xd2\xf2Z\xfc{\x7fn\x02?,\x08\x1c\xc8\x03\x061X\xb5\xc9\x99\xd0\xca'
key: b'\x01ez\xd5\xa9\xf9\x1f)\xa0G\xd2\xf2Z\xfc{\x7fn\x02?,\x08\x1c\xc8\x03\x061X\xb5\xc9\x99\xd0\xca'
16
self test result: 0
enc parameters: {'salt': '6162636465666768', 'mode': 'cbc', 'algorithm': 'rijndael-128', 'iv': '61626364616263646162636461626364'}
dec parameters: {'salt': '6162636465666768', 'mode': 'cbc', 'algorithm': 'rijndael-128', 'iv': '61626364616263646162636461626364'}
enc key: 01657ad5a9f91f29a047d2f25afc7b7f6e023f2c081cc803063158b5c999d0ca
dec key: 01657ad5a9f91f29a047d2f25afc7b7f6e023f2c081cc803063158b5c999d0ca
Stats: 88 / 100 good packets (88.0%)

#5: b'aaaaaaaaaaaaaaaa' != b'\xa6\xb8\xf9\td\x8db\xf6\x00Y"ST\xc6\x9b\xe7'
#6: b'aaaaaaaaaaaaaaaa' != b'aaaaaaa1\xb3@\x8d\xff\xf9\xafpy'
#13: b'aaaaaaaaaaaaaaaa' != b'\xb9\xc8\xaf\x1f\xb8\x8c\x0b_\x15s\x9d\xecN,*w'
#14: b'aaaaaaaaaaaaaaaa' != b'aaaaaaaaaaaaa\xeb?\x13'
#49: b'aaaaaaaaaaaaaaaa' != b'_C\xf2\x15\xd5k\xe1XKIF5k\x82\xa4\xec'
#50: b'aaaaaaaaaaaaaaaa' != b'aaaaaaaaaaa+\xdf>\x01\xee'
#74: b'aaaaaaaaaaaaaaaa' != b'\x1c\xdf0\x05\xc7\x0b\xe9\x93H\xc5B\xd7\xcfj+\x03'
#75: b'aaaaaaaaaaaaaaaa' != b'aaaaaaaaaaaaw+\xed\x0f'
#79: b'aaaaaaaaaaaaaaaa' != b"\xf2\x89\x1ct\xe1\xeeBWo\xb4-\xb9\x085'\xef"
#80: b'aaaaaaaaaaaaaaaa' != b'aaaaaaaaaaa\xcc\x01n\xf0<'
#91: b'aaaaaaaaaaaaaaaa' != b'g\x02\x08\xbf\xa5\xd7\x90\xc1\x84D\xf3\x9d$a)\x06'
#92: b'aaaaaaaaaaaaaaaa' != b'aaaaaaaaaaaaaaa\x01'

La parte extraña es que es exactamente el mismo para un (algoritmo, el modo) par dado. Puedo cambiar el algoritmo y que va a dar lugar a diferentes recorridos completos, pero siempre la misma para cada ejecución cuando no se cambia el algoritmo. Estoy absolutamente perplejo. Además, siempre es dos bloques en una fila que son corruptos como se puede ver en la salida anterior: los bloques 5 y 6, 13 y 14, etc Por lo tanto, hay un patrón, pero yo soy, por cualquier razón, no puede averiguar lo que el patrón está apuntando a la precisión.

Me doy cuenta de que probablemente estoy pidiendo mucho aquí: No puedo aislar un pequeño recorte de código, y la familiaridad con tanto mcrypt y Python, probablemente se requiere. Por desgracia, después de tres días de golpear mi cabeza en esto, necesito a alejarse del problema para un poco, por lo que estoy publicando esto aquí con la esperanza de que tal vez mientras estoy tomando un descanso de este problema, ya sea (a) a alguien será ver donde introdujo un error, (b) voy a ser capaz de ver mi error cuando vuelva al problema más adelante, o (c) a alguien o yo puedo encontrar el problema que tal vez no es un error en mi código, pero un error en el proceso de unión o de la propia biblioteca.

Una cosa que no he hecho se trató de utilizar otra versión de la biblioteca mcrypt. Estoy haciendo mi trabajo con Cython 0,13, Python 3.1, 2.5.8 y mcrypt, todo ello como distribuido por Ubuntu en Ubuntu 10.10 (excepto Cython, que obtuve de PyPi). Pero me gestionar sistemas con aplicaciones PHP que están funcionando bien y utilizando mcrypt en Ubuntu 10.10 y sin corrupción de datos, así que no tengo razones para creer que es la acumulación de mcrypt, de manera que las hojas sólo ... bueno, algo malo de mi parte alguna parte , creo.

En cualquier caso, agradezco cualquier profusamente que puede ayudar. Estoy empezando a sentir como que estoy volviendo loco porque he estado trabajando en este problema casi sin parar durante días y me da la sensación de que la solución es probablemente justo en frente de mí, pero no puedo verlo.

Editar : Alguien señaló que debería estar utilizando memcpy en lugar de strncpy. Lo hice, pero ahora, los programas de escritura de la prueba que todos bloque es incorrecto. Color me aún más confundido que antes ... aquí está la nueva salida en Pastebin .

Editar 2 : Tengovolver al equipo y ha estado buscando en él otra vez, y yo sólo estoy añadiendo imprimir estados de todas partes para encontrar donde las cosas podrían ir mal. El código siguiente en la función raw_encrypt.step (entrada):

    cdef char* buffer = <char*>malloc(in_len)
    print in_bin[:in_len]
    memcpy(buffer, <const_void *>in_bin, in_len)
    print "Before/after encryption"
    print buffer[:in_len]
    success = cmc.mcrypt_generic(self._mcStream, <void*>buffer, in_len)
    print buffer[:in_len]

La primera impresión declaración muestra la cosa era de esperar, el texto plano que se pasa. Sin embargo, la segunda muestra uno algo completamente diferente, la cual deben ser idénticos. Parece que hay algo pasando con Cython que no entiendo por completo.

Answer 1

Oy, odio hacer esto (responder a mi propia pregunta), pero he encontrado la respuesta: Es un capricho de la Cython que voy a tener que mirar en (no sé si es un capricho previsto o si se trata de un error).

El problema viene con la línea de establecimiento de memoria. Yo echo el segundo parámetro a <* const_void>, que coincide con la definición Cython en el archivo PXD, pero al parecer que hace Cython compilar el código de manera diferente que el uso de , este último obligando Cython a pasar un puntero a los bytes reales en vez de (supongo?) un puntero al objeto Python / variable misma.

Así que, en lugar de esto:

cdef char* buffer = <char*>malloc(in_len)
memcpy(buffer, <const_void *>in_bin, in_len)
success = cmc.mcrypt_generic(self._mcStream, <void*>buffer, in_len)

Tiene que ser esta:

cdef char* buffer = <char*>malloc(in_len)
memcpy(buffer, <char *>in_bin, in_len)
success = cmc.mcrypt_generic(self._mcStream, <void*>buffer, in_len)

Lo que una peculiaridad extraña. Yo esperaría que honestamente cualquier fundido a punto en la misma ubicación, pero parece que el reparto puede afectar el comportamiento también.

Answer 2

Me he encontrado con resultados similares a éste cuando algo extraño sucedió con una combinación de utilizar el mal vector de inicialización (es decir, utilizando un IV diferente para el cifrado que para el descifrado) y la elección Ciphermode. Como una comprobación de validez, trate de cambiar de CBC a BCE.

Otra posibilidad es que está siendo asignados al azar a uno de sus variables (con una nueva semilla basada en el tiempo) cuando no debería ser. En ese caso, puede causar daños en los datos que suceda más a menudo poniendo un retraso entre la etapa de cifrado y descifrado.