LUKSがCBCを使用する理由
LUKSはデフォルトでCBC付きの256ビットAESを使用することを読みました。もちろん、CBCには、プレーンテキストで何かを変更すると、その後に続くすべてのものを変更しなければならないという欠点があります。ハードドライブ暗号化の場合、それは通常少なくとも数百GB、多くの場合数TBです。明らかに、テキストファイルのWordが変更されるたびに、いくつかのTB=を書き換える必要はありません。
次に、LUKSが互いに独立して暗号化する小さなブロック（512バイトなど）内のCBCのみを使用してこの問題を解決することを読みます。 他の問題がある を除いて、これはどのようにECBの問題を導入しないのですか？つまり、構造を維持し、意味的に順応性があるのでしょうか。
これらの問題が発生しないように、これらの〜512バイトブロックのそれぞれに新しい初期化ベクトルが選択されていますか？もしそうなら：それはどのように選択されますか？
LUKSがCTRを使用しないのはなぜですか？
Liam Dennehyの回答は、luksがデフォルトでCBCを使用しないことを示しています。以前はCTRの代わりにそれを使用した理由については、ディスク暗号化の通常の敵対モデルでは、CTRはディスク暗号化に対して安全ではないためです（ Wikipedia で確認できます）。
変更のたびにIVを変更しない限り、変更ごとにディスク全体を暗号化する必要がありますが、ある時点で敵がブロックのプレーンテキストと暗号化テキストを持っている場合、攻撃者はIVを変更するまでそのブロックを復号化できます。 CTR暗号化は、プレーンテキストでxorされた特定のブロックのランダムバイトのストリームを生成するだけです。変更ごとにディスク全体を再暗号化せずに安全にする唯一の方法は、ブロックごとにIVを保存することで（更新ごとに変更されます）、ディスク容量の点で非常にコストがかかるか、大きなブロックが必要になります。したがって、更新ごとに大量の再暗号化を行います。
CBCモードでは、512バイトのブロックごとに、キーとブロック番号から生成された独自のIVがあるため、2つの同一のブロックは暗号化後に同じになることはありません。
私が見つけたcryptsetupのオンラインmanページはまだ本当に古いリリースを参照しており、これが古い情報のソースである可能性があります。
2013年6月28日のコミット （この回答から4年前）は、LUKSデバイスの新しいデフォルトがaes-xts-plain64、これは1.6.0と1.6.2リリースの間のどこかにあるようです。