ストリームを暗号化しようとしています。エスペックログファイルに追加すると、実行するたびに同じファイルに追加するのが妥当であるため、次のようなことをしたいと思います。
my_stream | aespipe -K my_key >> aes_logfile
私は512バイトのチャンクを作成することを検討しており、aespipe常にこのサイズの増分でデータを出力するようにストリームをパディングしました。私ほぼ私の計画を実行してみましょうただし、aespipeは最初のファイル以降の512バイトの増加ごとに最初のバイトを破壊します。。たとえば、次のファイルthat_file（行で終わる~）は512バイトです。
Hey StackOverflow, here is a ~
small example. The lines are ~
32 characters long (including ~
the trailing \n) and with ~
aespipe you can encrypt this ~
file with ~
~
cat this_file | aespipe -K \ ~
your_key_with_one_line.gpg \ ~
> enc_file ~
~
then you can concatenate onto ~
the encrypted file again with ~
>> and get a new file. ~
Note that this file is 512 B. ~
So it is the right block size ~
これは次の出力です。
# First go
cat that_file | aespipe -K my_key.gpg > aes_logfile
# Second go
cat that_file | aespipe -K my_key.gpg >> aes_logfile
# Try decrypting
cat aes_logfile | aespipe -d -K my_key.gpg
注釈付き出力：
Hey StackOverflow, here is a ~
small example. The lines are ~
32 characters long (including ~
the trailing \n) and with ~
aespipe you can encrypt this ~
file with ~
~
cat this_file | aespipe -K \ ~
your_key_with_one_line \ ~
> enc_file ~
~
then you can concatenate onto ~
the encrypted file again with ~
>> and get a new file. ~
Note that this file is 512 B. ~
So it is the right block size ~
Iey StackOverflow, here is a ~ # <-- H became I!
small example. The lines are ~
32 characters long (including ~
the trailing \n) and with ~
aespipe you can encrypt this ~
file with ~
~
cat this_file | aespipe -K \ ~
your_key_with_one_line \ ~
> enc_file ~
~
then you can concatenate onto ~
the encrypted file again with ~
>> and get a new file. ~
Note that this file is 512 B. ~
So it is the right block size ~
512バイトごとに発生しますが、その理由はわかりません。この問題を解決する方法はありますか？ ( aespipe version 2.4d)
ベストアンサー1
まあ、再現できますよ。
# dd count=1 if=/dev/zero | aespipe > aes_zero
Password: Error: Password must be at least 20 characters.
# dd count=1 if=/dev/zero | aespipe >> aes_zero
Password: Error: Password must be at least 20 characters.
# cat aes_zero | aespipe -d | hexdump -C
Password: Error: Password must be at least 20 characters.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
^^
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400
暗号文：
# hexdump -C aes_zero
00000000 b3 a3 72 9b 18 5b 6b 73 e5 48 88 d1 8b 66 e3 10 |..r..[ks.H...f..|
00000010 a8 a0 ee d3 7e 08 91 86 6b f7 30 b2 ea 6a 58 0b |....~...k.0..jX.|
[...]
000001e0 d9 2a 60 22 c9 4a 37 5c 47 21 65 0a bb f3 a8 7d |.*`".J7\G!e....}|
000001f0 50 9f ef 38 9a c1 95 2b ff 85 c7 16 cc 90 a7 18 |P..8...+........|
00000200 b3 a3 72 9b 18 5b 6b 73 e5 48 88 d1 8b 66 e3 10 |..r..[ks.H...f..|
00000210 a8 a0 ee d3 7e 08 91 86 6b f7 30 b2 ea 6a 58 0b |....~...k.0..jX.|
[...]
000003e0 d9 2a 60 22 c9 4a 37 5c 47 21 65 0a bb f3 a8 7d |.*`".J7\G!e....}|
000003f0 50 9f ef 38 9a c1 95 2b ff 85 c7 16 cc 90 a7 18 |P..8...+........|
00000400
暗号文が繰り返されるので、まったく発生しない暗号化が間違っていることがすでにわかります。
暗号文自体には問題はありません。
# dd count=1 if=aes_zero | md5sum
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00136312 s, 376 kB/s
f328ce6ff88545bc803b033561cbdffd -
# dd count=1 skip=1 if=aes_zero | md5sum
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.00148213 s, 345 kB/s
f328ce6ff88545bc803b033561cbdffd -
したがって、同じであり、復号化中に無効なバイトがあります。
実際、私が素直に予想したのは、1バイトの偏差ではなく、最初の512バイト以降のランダムなデータでした。最も一般的に使用される暗号化方式では、暗号文の重複を避けるために各セクタのIVが異なり、結果は完全に異なる必要があります。
一度に1024バイトを暗号化します。
# dd count=2 if=/dev/zero | aespipe >> aes_zero2
Password: Error: Password must be at least 20 characters.
# hexdump -C aes_zero2
00000000 b3 a3 72 9b 18 5b 6b 73 e5 48 88 d1 8b 66 e3 10 |..r..[ks.H...f..|
00000010 a8 a0 ee d3 7e 08 91 86 6b f7 30 b2 ea 6a 58 0b |....~...k.0..jX.|
...
000001e0 d9 2a 60 22 c9 4a 37 5c 47 21 65 0a bb f3 a8 7d |.*`".J7\G!e....}|
000001f0 50 9f ef 38 9a c1 95 2b ff 85 c7 16 cc 90 a7 18 |P..8...+........|
00000200 60 89 3e 37 87 1c 37 31 1a 11 50 b6 99 50 d3 74 |`.>7..71..P..P.t|
00000210 af a9 a2 30 3d e6 72 5f f3 96 6d 3b 9e 5b 33 6f |...0=.r_..m;.[3o|
...
000003e0 3f d3 2e 9a 18 ad 7a c9 5a ee 04 99 28 e6 af 3f |?.....z.Z...(..?|
000003f0 a3 a9 71 be 1a 56 35 01 06 b9 57 dd fc 42 7c 47 |..q..V5...W..B|G|
ご覧のとおり、暗号文はまったく繰り返されません。したがって、接続で無効な暗号文が生成され（IVが正しく設定されていない）、とにかく多くのフルテキストを取得することは大きな驚きであり、良い暗号化ではありません。暗号文を別のオフセットに移動して合理的な結果を得ることはできません（最初の数バイトだけが誤ったIVの影響を受けます）。
LUKS（aes-xts-plain64）を使用して同じものを再現しようとしています。
# truncate -s 1024 luks_zero
# losetup --find --show luks_zero
/dev/loop9
# cryptsetup open --type plain --cipher aes-xts-plain64 /dev/loop9 luks_zero
Enter passphrase for /dev/loop9: Error: Password must be at least 20 characters.
# dd if=/dev/zero of=/dev/mapper/luks_zero
dd: writing to '/dev/mapper/luks_zero': No space left on device
3+0 records in
2+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.000719156 s, 1.4 MB/s
LUKSで暗号化された0。繰り返される暗号文:
# sync
# dd count=1 seek=1 if=/dev/loop9 of=/dev/loop9
# hexdump -C /dev/loop9
00000000 1c 18 b1 e6 57 9c a1 60 8c 98 f0 d3 59 8b 97 0c |....W..`....Y...|
00000010 bc fc 8a 62 68 52 51 f1 51 49 bf 21 2e f5 bc 84 |...bhRQ.QI.!....|
[...]
000001e0 4a e0 ef eb 8f 09 18 a8 73 95 0b 2c 59 01 69 1b |J.......s..,Y.i.|
000001f0 92 71 e6 0d dd 3b 71 b5 22 f4 34 1c e1 4a 95 71 |.q...;q.".4..J.q|
00000200 1c 18 b1 e6 57 9c a1 60 8c 98 f0 d3 59 8b 97 0c |....W..`....Y...|
00000210 bc fc 8a 62 68 52 51 f1 51 49 bf 21 2e f5 bc 84 |...bhRQ.QI.!....|
[...]
000003e0 4a e0 ef eb 8f 09 18 a8 73 95 0b 2c 59 01 69 1b |J.......s..,Y.i.|
000003f0 92 71 e6 0d dd 3b 71 b5 22 f4 34 1c e1 4a 95 71 |.q...;q.".4..J.q|
00000400
暗号文が完全にコピーされました。解読結果：
# hexdump -C /dev/mapper/luks_zero
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200 b7 6c 5c 84 3d 7d dc 58 fc d5 ee 7f 20 c0 d5 09 |.l\.=}.X.... ...|
00000210 a8 78 f8 d8 38 4b 6a 24 bb b1 d2 65 b8 5c 2b ac |.x..8Kj$...e.\+.|
[...]
000003e0 08 31 74 f4 59 92 3b 7f 0f fa b9 36 2e de 53 e2 |.1t.Y.;....6..S.|
000003f0 24 83 01 53 6e 56 dc a5 3a 3f 1b 4e d5 0a fd a9 |$..SnV..:?.N....|
00000400
512バイトのゼロと完全なガベージが続きます。これは暗号通貨が良いことを証明するものではありませんが、aespipeから得られるように明らかに悪くはありません。
これは無効なIVによるものなので、まず正しいIVで暗号化されていることを確認してください。次のフラグがaespipeあります。-O sectornumber
-O sectornumber
Set IV offset in 512 byte units. Default is zero. Data is encrypted in 512 byte CBC
chains and each 512 byte chain starts with IV whose computation depends on offset
within the data. This option can be used to start encryption or decryption in middle of
some existing encrypted disk image.
モノを暗号化してリンクする新しい方法：
# dd count=1 if=/dev/zero | aespipe -O 0 > aes_zero
Password: Error: Password must be at least 20 characters.
# dd count=1 if=/dev/zero | aespipe -O 1 >> aes_zero
Password: Error: Password must be at least 20 characters.
ワンタイム暗号化と一致していることを確認してください。
# md5sum aes_zero aes_zero2
3b0479e04a46a3d268dc4252e066d2b5 aes_zero
3b0479e04a46a3d268dc4252e066d2b5 aes_zero2
次に、復号化の結果が正しいことを確認します。
# cat aes_zero | aespipe -d | hexdump -C
Password: Error: Password must be at least 20 characters.
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400
DNAが一致し、タイミングが機能し、すべてが確認されます...まあ、暗号通貨自体を改善するのではなく、当面の問題を解決し、おそらく目的に十分です。
ファイルサイズから正しい-O sectornumber値を動的に派生させることは、読者の練習問題のままです。