la corruzione dei dati: Dov'è il bug?

Question

Ultima modifica: Ho capito quale fosse il problema (vedere la mia risposta qui sotto), ma non riesco a segnare la domanda come risposta, sembrerebbe. Se qualcuno può rispondere alle domande che ho nella mia risposta qui sotto, vale a dire, questo è un bug in Cython o è un comportamento previsto di questo Cython, mi segnerà che risposta come accettato, perché sarebbe la più utile lezione da guadagnare da questo, IMHO.

---

In primo luogo, devo iniziare dicendo che ho cercato di conoscere questo numero per tre giorni, e sto solo sbattere la testa contro il muro. Come meglio posso dire dalla documentazione, che sto facendo le cose correttamente. Ovviamente, non posso essere facendo le cose correttamente, però, perché se lo fossi, non avrei un problema (giusto?).

In ogni caso, sto lavorando su un vincolante per mcrypt a Python. Dovrebbe funzionare sia con Python 2 e Python 3 (anche se è testato per Python 2). E 'disponibile sul mio sito, collegato perché è troppo grande per includere nel post, e dato che non so cosa che sto facendo male, non riesco nemmeno a isolare quello che potrebbe essere il codice problema. Lo script che mostra il problema è anche sul mio sito . Lo script appena alimenta 100 blocchi di nulla, ma la lettera "a" (in qualsiasi dimensione del blocco degli usi modalità di cifratura algoritmo / codifica), e, naturalmente, dovrebbe ottenere un blocco di "a" come il risultato di roundtripping. Ma non (sempre). Qui viene emesso da una singola esecuzione di esso:

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 strana è che è esattamente lo stesso per un dato (algoritmo, modalità) coppia. Posso modificare l'algoritmo e che si tradurrà in diversi viaggi di andata, ma sempre lo stesso per ogni periodo, quando non cambio l'algoritmo. Sono assolutamente sconcertato. Inoltre, è sempre a due isolati di fila che sono corrotti, come si può vedere nella uscita di cui sopra: i blocchi 5 e 6, 13 e 14, ecc Quindi, v'è un modello, ma io sono, per qualsiasi motivo, in grado di capire ciò che quel modello sta indicando con precisione.

mi rendo conto che probabilmente sto chiedendo molto qui: non riesco a isolare un piccolo elemento di cattura di codice, e la familiarità con entrambi mcrypt e Python è probabilmente necessario. Ahimè, dopo tre giorni di sbattere la testa su questo, ho bisogno di allontanarsi dal problema per un po ', così mi distacco questa qui nella speranza che forse, mentre io sto prendendo una pausa da questo problema (a) qualcuno vedrà dove ho introdotto un bug, (b) sarò in grado di vedere il mio bug quando torno al problema più tardi, o (c) qualcuno o riesco a trovare il problema, che forse non è un bug nel mio codice, ma un bug nel processo di associazione o la libreria stessa.

Una cosa che non ho fatto è tentato di utilizzare un'altra versione della libreria mcrypt. Sto facendo il mio lavoro con Cython 0,13, Python 3.1 e 2.5.8 mcrypt, tutto come distribuito da Ubuntu in Ubuntu 10.10 (tranne Cython, che ho avuto da Cheese Shop). Ma io gestire i sistemi con le applicazioni PHP che funzionano bene e che utilizzano mcrypt su Ubuntu 10.10 senza corruzione dei dati, quindi non ho motivo di credere che è la build di mcrypt, in modo che solo le foglie ... beh, qualcosa di sbagliato da parte mia qualche parte , credo.

In ogni caso, ringrazio tutti coloro copiosamente che può aiutare. Sto iniziando a sentire come sto impazzendo perché ho lavorato su questo problema praticamente non-stop per giorni e ho la sensazione che la soluzione è probabilmente proprio di fronte a me, ma non riesco a vederlo.

Modifica : Qualcuno ha fatto notare che dovrei essere usando memcpy invece di strncpy. L'ho fatto, ma ora, gli spettacoli di script di test che tutti di blocco non è corretto. Color me ancora più confuso di quanto precedentemente ... ecco la nuova uscita su pastebin .

Modifica 2 : Hotorno al computer e sono stati a guardare di nuovo, e sto solo aggiungendo istruzioni di stampa in tutto il mondo per trovare dove le cose potrebbero andare male. Il seguente codice nella funzione raw_encrypt.step (ingresso):

    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 dichiarazione spettacoli prima di stampa la cosa prevedibile, il testo in chiaro che viene passato. Tuttavia, il secondo mostra un qualcosa di completamente diverso, che dovrebbero essere identiche. Sembra che ci sia qualcosa da fare con Cython che non ho del tutto capito.

Answer 1

Oy, odio per fare questo (rispondere alla mia domanda), ma ho trovato la risposta: Si tratta di un capriccio del Cython che sto per avere a guardare in (non so se si tratta di un capriccio destinato , o se si tratta di un bug).

Il problema arriva con la linea memcpy. Ho gettato il secondo parametro su <* const_void>, che corrisponde alla definizione Cython nel file PXD, ma a quanto pare che rende Cython compilare il codice in modo diverso rispetto usando , quest'ultima costringendo Cython passare un puntatore ai byte effettivi invece di (credo?) un puntatore oggetti Python / variabile stessa.

Così, invece di questo:

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)

Ha bisogno di essere questo:

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

Che strano capriccio. Vorrei sinceramente aspettarsi alcun cast punto nella stessa posizione, ma sembra che il cast può influenzare il comportamento pure.

Answer 2

ho incontrato risultati simili a questo quando qualcosa di divertente è successo con una combinazione di utilizzare il torto vettore di inizializzazione (vale a dire utilizzando un diverso IV per la crittografia che per la decrittografia) e la scelta Ciphermode. Come un controllo di integrità, prova a passare da CBC BCE.

Un'altra possibilità è che una delle vostre variabili si sta randomizzati (con un nuovo seme a base di tempo), quando non dovrebbe essere. In tal caso, è possibile causare la corruzione dei dati avvenga più spesso mettendo un ritardo tra la fase di codifica e decodifica.