データの破損：バグはどこにありますか

Question

最後の編集： 私は問題が何であるかを理解しました（以下の私自身の答えを参照）が、答えのように質問をマークすることはできません。誰かが以下の私の答えで私が持っている質問に答えることができるなら、つまり、これはシストンのバグですか、これはこのシステンの意図された行動ですか、私はマークします それ 受け入れられているように答えます。なぜなら、それはこれから得られる最も有用な教訓だからです。

---

まず、私はこれを3日間理解しようとしていると言って始めなければならず、壁に頭を叩いているだけです。ドキュメントからわかる限り、私は物事を正しくやっています。明らかに、私は正しく物事をすることはできません。

いずれにせよ、私はMcRyptからPythonへのバインディングに取り組んでいます。 Python 2とPython 3の両方で動作するはずです（ただし、Python 2ではテストされていません）。利用可能です 私のサイトで, 、リンクされているので、投稿に含めるには大きすぎて、私が知らないので 何 私は間違っています、私は問題コードであるかもしれないものを隔離することさえできません。問題を示すスクリプトはです 私のサイトでも. 。このスクリプトは、文字「A」（暗号化アルゴリズム/暗号化モードが使用するブロックサイズでは）の100ブロックに100ブロックに供給され、もちろん丸いトリップの結果として「A」のブロックを取得する必要があります。しかし、それは（常に）ではありません。これがそれの単一の実行からの出力です：

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'

奇妙な部分はそれがそうであるということです まさに 特定の（アルゴリズム、モード）ペアについても同じです。アルゴリズムを変更すると、異なるラウンドトリップが発生しますが、アルゴリズムを変更しない場合は、すべての実行で常に同じです。私は絶対に困惑しています。また、上記の出力でわかるように腐敗しているのは常に2つのブロックです：ブロック5および6、13および14など。パターンがありますが、何らかの理由で、私は理解できませんそのパターンが正確に指し示しているもの。

私はおそらくここでたくさん質問していることに気づきました。私はコードの小さな切り分けを隔離することはできません。McRyptとPythonの両方に精通していることがおそらく必要です。悲しいかな、これに頭を3日間叩いた後、私は少しの間問題から離れる必要があるので、私はこの問題から休憩を取っている間に（a）誰かの休憩を取っている間にこれをここに投稿していますバグを導入した場所がわかります。（b）後で問題に戻ったときにバグを見ることができます。バインディングプロセスまたはライブラリ自体のバグ。

私がやったことがないことの1つは、McRyptライブラリの別のバージョンを使用しようとしたことです。 Cython 0.13、Python 3.1、およびMcRypt 2.5.8で作業を行っています。すべてUbuntu 10.10でUbuntuによって配布されています（Cythonを除く、Pypiから入手したCythonを除く）。しかし、私はデータ腐敗なしにUbuntu 10.10でMcRyptを使用しているPHPアプリケーションを使用してシステムを管理しているので、それがMcRyptのビルドであると信じる理由はありません。 、 おもう。

いずれにせよ、私は誰でも助けることができる人に感謝します。私はこの問題に何日もかなり立ち止まっているので、私は夢中になっているように感じ始めています。

編集: ：誰かが、strncpyの代わりにmemcpyを使用する必要があることを指摘しました。私はそれをしましたが、今、テストスクリプトはそれを示しています 毎日 ブロックが正しくありません。以前よりもさらに混乱しています...これが新しい出力です パステビン.

編集2: ：私はコンピューターに戻って、もう一度それを見てきました。そして、どこにでも印刷されたステートメントを追加して、物事がうまくいかない可能性があることを見つけるだけです。 RAW_ENCRYPT.STEP（入力）関数の次のコード：

    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]

最初の印刷ステートメントは、渡される予想されるもの、つまり渡されたプレーンテキストを示しています。ただし、2つ目はまったく異なるものを示しています。私が完全に理解していないことは、Cythonで何かが起こっているようです。

Answer 1

ああ、私はこれをするのが嫌いです（自分の質問に答えます）が、答えを見つけました：それは私が調べなければならないCythonの癖です（それが意図された癖なのか、それはバグです）。

問題は、Memcpyラインに伴います。 2番目のパラメーターをキャストしますu003Cconst_void*>、PXDファイルのCythonの定義と一致しますが、明らかにCythonが使用するのとは異なる方法でコンパイルされますu003Cchar*>、後者は、CythonがPythonオブジェクト/変数自体へのポインターではなく（私が推測する？）実際のバイトにポインターを渡すように強制します。

だから、これの代わりに：

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)

これである必要があります：

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

なんて奇妙な癖でしょう。キャストが同じ場所を指すことを正直に期待していますが、キャストも行動に影響を与える可能性があるようです。

Answer 2

間違った初期化ベクトル（つまり、復号化の場合とは異なる暗号化に異なるIVを使用する）と暗号化選択の選択で何か面白いことが起こったときに、これに似た結果に遭遇しました。正気確認として、CBCからECBに切り替えてみてください。

別の可能性は、変数の1つが、そうでない場合に（新しい時間ベースの種子を使用して）無作為化されていることです。その場合、暗号化と復号化ステップの間に遅延を置くことにより、データの破損をより頻繁に発生させることができます。