Влияет ли первоначальный пароль шифрованного диска на криптостойкость?

Если зашифрованный мастер-ключ хранится в "хрупком" виде, как в cryptsetup-LUKS, и/или надёжно стирается при смене пароля, то первоначальный пароль не должен влиять на стойкость. В противном случае у противника сохранится возможность восстановить с диска нестойко зашифрованную копию мастер-ключа и получить доступ к содержимому.

Если чуть подробнее, то процесс "под капотом" в качественных программах выглядит примерно так:

1. При первоначальном шифровании контейнера одновременно с запросом пароля генерируется стойкий мастер-ключ (обычно 128, 256 или сдвоенный 256+256 бит для XTS-режима).
2. Пароль пропускается через функцию замедленного вывода ключа из пароля путём многоцикловых преобразований (Key Derivation Function — KDF).
3. Генерируется ключ слота (которых м.б. много — чтобы можно было использовать разные пароли одновременно). Результат K = KDF(Password) используется для шифрования ключа слота, которым в свою очередь шифруется мастер ключ.
4. В каждый слот записывается мастер-ключ, зашифрованный ключом слота, который в свою очередь зашифрован ключом KDF из пароля.
5. Контейнер шифруется всегда только одним мастер-ключом. Расшифрование происходит в обратном порядке: по паролю вычисляется ключ, по его хэшу подбирается слот, из него расшифровывается ключ слота, который расшифровываает мастер-ключ контейнера.
6. Есть ещё кое-какие тонкости со служебными заголовками для проверки правильности ключей по хэшам, по заданию числа итераций в KDF и т.д.

При смене пароля перешифровывается один из слотов. Мастер ключ контейнера остаётся тем же самым (сам контейнер целиком не перешифровыается на новый ключ!). Как было отмечено выше, чтобы стирание информации из слота было трудновосстановимым, используется т.н. хранение в хрупком виде: данные в слоте "размазаны" на большой размер блока, утрата определённой части битов к которому в процессе перешифровывания/перетирания, делает восстановление данных требующим большого перебора грубой силой.

Что может пойти не так:

1. Если заголовок контейнера со слотами, шифрованными слабым паролем где-то бэкапился отдельным файлом, который мог бы попасть в руки противника.
2. Если контейнер создавался в виде файла поверх файловой системы: тогда он может по ней "ездить", оставляя незатёртые блоки, в которых может быть и слот, зашифрованный на старый пароль.
3. При использовании носителей типа флэшек и SSD-винчестеров процесс затирания ячеек может не выполняться, а заменяться записью и/или перемещением данных в другую область, что теоретически также может позволить найти противнику старые копии заголовка к контейнеру.
4. Заголовок может утечь куда-либо ещё: в нешифрованный своп файл, системные снэпшоты, и др.
5. Избыточность хранения информации в рэйд-массивах также затрудняет её стирание.
6. При создании файлов на удалённых машинах (виртуальный и физический хостинг) владелец, контролирующий эту машину, может снимать копии заголовков, бэкапить контейнеры и т.д.

Против кое-чего из этого как раз и используется т.н. хранение заголовков в "хрупком виде" (anti-forensic stripes), но полной гарантии во всех случаях оно дать не может.

в качественных программах

можно хотя бы 1 пример для win и *nix.

для win

DiskCryptor(?)

Если чуть подробнее, то процесс "под капотом" в качественных программах выглядит примерно так

Спасибо за структурированное подробное описание. По поиску словосочетания мастер ключ google находит множество ранних ваших комментов. Первое жаркое подробное обсуждение этой тему имело место, видимо, здесь.

ранение заголовков в "хрупком виде" (anti-forensic stripes)

Ссылка для тех, кому интересны подробности.