Если у вас паранойя…

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

На самом деле это довольно несложно делается, попробую показать на примере.
(«промышленные», сертифицированные и прочие решения не рассматриваются потому что потому)

Итак, условие номер один: информация из некой секретной папки не должна быть доступна посторонним.

Очевидное решение — шифрование. При этом также очевидно, что в зашифрованном виде ее могут украсть, так или иначе, например вместе с компьютером.

Но у шифрования есть минус: вы знаете пароль, и если вас настоятельно попросить — вы его скажете. Значит, это и будет условие номер два: вы не можете рассказать пароль. Захотите — но не сможете.

Однако, не зная пароля — вы должны получать при этом доступ к своим файлам.
Это означает, что открываться защищенная папка должна сама, но только при «штатной» работе, и не открываться, если что‑то пошло не так.
Это условие номер три — работает автоматически.

Можно привязать пароль к каким‑то аппаратным свойствам компьютера — но если выкрасть весь компьютер — будет выкраден и ключ к папке. Значит, ключ должен находиться вне компьютера, но в доступе к нему.
Но что, если злоумышленники украли не только один компьютер, но и весь офис? А вам не дают ничего делать.
Тогда ключ должен быть таким, чтобы третье лицо могло в любой момент уничтожить ключ, возможно даже не зная что именно делает, «не вызывая подозрения санитаров».
Это — четвертое условие: ключ физически не привязан к компьютеру и не должен выглядеть как ключ для постороннего наблюдателя, зато должен быть легко уничтожим.

Вот это сейчас и реализуем:

В качестве средства шифрования используем LUKS. Это непринципиально, просто cryptsetup уже есть.
Чтобы не знать пароль — нужно использовать ключевой файл. LUKS работает с 512-битными ключами — это 64 байта данных, запомнить и рассказать вы не сможете.
Управлять подключением секретного диска можно через PAM на компьютере — всё будет происходить аввтоматически.
Получить ключ можно по сети, да вот хотя бы по http с какого‑нибудь веб‑сервера. Причем это может быть хоть корпоративный сервер, хоть удаленный сайт, хоть плата esp8266 в стене за гипсокартоном.

И чтобы ключ не выглядел как ключ для посторонних — в качестве ключа можно использовать самый обычный файл, хоть картинку, хоть текст. Взяв от него 512-битный хеш — и получим тот самый уникальный секретный ключ.
А удалить его очень просто: заменить картинку на сайте, пусть даже на похожую. Как именно это сделать — совсем другой вопрос, но он решаемый.

Для этого пишем такой скрипт (/usr/local/bin/paranoid):

#!/bin/bash

# на всякий случай подключаем /sbin
PATH=/sbin:$PATH

# установка общих переменных
setvars(){
  HOME_DIR=$(getent passwd "$USER" | cut -d: -f6)
  MOUNT_POINT="$HOME_DIR/edisk"

  TMPFS_DIR="/tmp/tmpfs_key_$USER"
  IMG_FILE="$TMPFS_DIR/image.bin"
  KEY_FILE="$TMPFS_DIR/secret.key"
  CRYPT_NAME="edisk_$USER"
}

# проверка наличия установленных программ
checks(){
  which awk grep mount umount wget sha512sum xxd cryptsetup mkfs.ext4
  if [ $? -ne 0 ] ; then
    # если чего-то нет - завершаем работу, но "успешно", чтобы не вызывать ошибок
    exit 0
  fi
}

# читаем конфигурационный файд ля юзера
getconfig(){
  CONFIG="/etc/paranoid/users/$USER.conf"

  DATA_DIR=$(sudo awk -F= '/^data_dir/ {gsub(/^ +| +$/, "", $2); print $2}' $CONFIG)
  DISK_IMAGE=$(sudo awk -F= '/^disk_image/ {gsub(/^ +| +$/, "", $2); print $2}' $CONFIG)
  SECRET=$(sudo awk -F= '/^secret/ {gsub(/^ +| +$/, "", $2); print $2}' $CONFIG)

  if [ "x$DISK_IMAGE" = "x" ] || [ "x$SECRET" = "x" ] || [ "x$DATA_DIR" = "x" ] ; then
    echo "No <disk_image> or <secret> found!"
    exit 0
  fi

  DISK_IMAGE="$DATA_DIR/$DISK_IMAGE"
}

# проверка на "открытость"
is_mapped() {
  ls /dev/mapper | grep -q "$CRYPT_NAME"
}

# проверка на смонтированность
is_mounted() {
  mount | grep -q "$MOUNT_POINT"
}

# самая главная часть - получение ключа
fetch_key() {
  mkdir -p "$TMPFS_DIR"
  if [ $? -ne 0 ] ; then
    exit 0
  fi
  sudo chmod 700 "$TMPFS_DIR"
  # монтируем временную ФС
  sudo mount -t tmpfs -o size=1M tmpfs "$TMPFS_DIR"

  # получаем ключ по указанному URL
  # ничего не мешает получать по 2-3 ключа из разных источников и
  # конкатенировать их в один файл
  wget -q -O "$IMG_FILE" "$SECRET"

  if [ $? -ne 0 ] || [ ! -f "$IMG_FILE" ] ; then
    echo "No key file loaded!"
    sudo umount "$TMPFS_DIR"
    rmdir "$TMPFS_DIR"
    exit 0
  fi

  # формируем 512-битный ключ
  sha512sum "$IMG_FILE" | awk '{print $1}' | xxd -r -p > $KEY_FILE

  # затираем и удаляем источник - в памяти ничего не остается
  fsize=$(stat -c "%s" "$IMG_FILE")
  dd if=/dev/urandom of="$IMG_FILE" bs=$fsize count=1 status=none
  rm -f "$IMG_FILE"

  chmod 600 "$KEY_FILE"
}

# очистка ключа - затираем и удаляем
cleanup_key() {
  if [[ -f "$KEY_FILE" ]]; then
    dd if=/dev/urandom of="$KEY_FILE" bs=64 count=1 status=none
    rm -f "$KEY_FILE"
  fi

  sudo umount "$TMPFS_DIR"
  rmdir "$TMPFS_DIR"
}

# процедура форматирования/создания диска
format_file(){
  setvars;
  getconfig;

  sudo mkdir -p $DATA_DIR

  # если диска нет - создаем
  if [ ! -f "$DISK_IMAGE" ] ; then
    echo -n "Enter disk size (MB): "
    read size; size=$(( $size * 1 ));
    if [ $size -gt 0 ] ; then
      sudo dd if=/dev/urandom of="$DISK_IMAGE" bs=1M count=$size status=progress
    else
      echo "Size must be greater than 0!"
    fi
  fi

  # если есть и не используется - меняем ключ
  if [ -f "$DISK_IMAGE" ] ; then
    if is_mapped; then
      echo "Encripted disk already opened"
    else
      fetch_key
      echo "Open encryped disk..."
      sudo cryptsetup luksFormat "$DISK_IMAGE" "$KEY_FILE"
      sudo cryptsetup luksOpen "$DISK_IMAGE" "$CRYPT_NAME" --key-file "$KEY_FILE"
      sudo mkfs.ext4 "/dev/mapper/$CRYPT_NAME"
      sudo cryptsetup luksClose "$CRYPT_NAME"
      cleanup_key
    fi
  fi
}

# процедура монтирования
mount_disk() {
  setvars;
  getconfig;

  if [ -f "$DISK_IMAGE" ] ; then
    if is_mapped; then
      echo "Encripted disk already opened"
    else
      fetch_key
      echo "Open encryped disk..."
      sudo cryptsetup luksOpen "$DISK_IMAGE" "$CRYPT_NAME" --key-file "$KEY_FILE"
      cleanup_key
    fi

    if is_mapped; then
      if is_mounted; then
        echo "Already mounted $MOUNT_POINT."
      else
        echo "Mount..."
        mkdir -p "$MOUNT_POINT"
        if [ $? -eq 0 ] ; then
          sudo mount /dev/mapper/"$CRYPT_NAME" "$MOUNT_POINT"
          sudo chown $USER "$MOUNT_POINT"
          sudo chmod 700 "$MOUNT_POINT"
        fi
      fi
    else
     echo "Incorrect key"
    fi
  fi
}

# процедура отключения диска
unmount_disk() {
  setvars;

  if [ ! $UMOUNT_FORCE ] ; then
    # проверка на наличие рабочих сессий - для автоотключения
    USER_SESSIONS=$(who | grep -w "$USER" | wc -l)
    USER_PROCESSES=$(ps -u "$USER" --no-headers | wc -l)
  fi

  if [ "$USER_SESSIONS" -gt 1 ] || [ "$USER_PROCESSES" -gt 0 ]; then
    echo "User $USER logged in ($USER_SESSIONS sessions, $USER_PROCESSES processes)"
  else
    echo "Last session $USER ended"

    if is_mounted; then
      echo "Unmount..."
      sudo umount "$MOUNT_POINT"
      rmdir "$MOUNT_POINT"
    else
      echo "Already unmounted."
    fi

    if is_mapped; then
      echo "Close LUKS-volume..."
      sudo cryptsetup luksClose "$CRYPT_NAME"
    else
      echo "LUKS-volume closed."
    fi
   fi
  fi
}

usage(){
  cat <<EOF
Configurations:

/etc/paranoid/users/<username>.conf:
=============================
data_dir = /var/spool/paranoid
disk_image = data.dump
secret = http://url/secret_file.ext
=============================

Interactive mode:

$0 format 
  Create new or format existing cryptodisk with SECRET

$0 format <username>
  Create new or format existing cryptodisk with SECRET for user <username>

$0 mount
  Mount cryptodisk (if exists)

$0 unmount
  Unmount cryptodisk (if mounted)


PAM mode:

/etc/pam.d/common-session:
session optional  pam_exec.so $0

If used fscrypt - do it twice, before and after pam_fscrypt.so
EOF
}

#=============================
checks;
uid=$(id -u)

case "$1" in
  mount)
    mount_disk
    ;;
  unmount)
    UMOUNT_FORCE=1
    unmount_disk
    ;;
  format)
    if [ "x$2" != "x" ] ; then
      if [ $uid -eq 0 ] ; then
        USER="$2"
        echo "Run for user $USER"
      else
        echo "User change ignored"
        exit 0
      fi
    fi
    format_file;
    ;;
  *)
    case "$PAM_TYPE" in
      open_session)
        USER=$PAM_USER
        mount_disk
        ;;
      close_session)
        USER=$PAM_USER
        unmount_disk
        ;;
      *)
        usage
        ;;
    esac
    ;;
esac

Теперь нужно создать конфиг для нашего юзера - вон как там написано:

/etc/paranoid/users/vasya.conf:

data_dir = /var/spool/paranoid
disk_image = data.dump
secret = http://image172.jpg

Если работаем под vasya:

paranoid format

Если под рутом:

paranoid format vasya

Указываем размер диска в мегабайтах, и если всё на своих местах - файл будет создан, зашифрован и отформатирован.
Подключаем - отключаем:

paranoid mount
paranoid unmount

Для автоматизации внесем записи в /etc/pam.d/common-session:

session optional pam_exec.so /usr/local/bin/paranoid

Если использовалось fscrypt для шифрования домашнего каталога - то дважды:

session optional pam_exec.so /usr/local/bin/paranoid
session optional pam_fscrypt.so
session optional pam_exec.so /usr/local/bin/paranoid

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

Теперь при логине в систему в домашнем каталоге юзера появляется примонтированный секретный диск, который исчезает при выходе из системы.
Либо можно принудительно его закрыть командой.
Если по любой причине ключевой файл недоступен или изменился - диск останется зашифрованным.
Если при этом запустить paranoid format - то еще и перешифрованным под новый ключ, с потерей всего что там было ранее записано.

Более того, файл диска не обязан быть именно файлом на диске - это может быть вообще подключаемая флешка или ISCSI-диск (data_dir = "/dev", disk_image = "sdb1" или подобное).
Если он в наличии - будет молча примонтирован, если нет - то нет.

@JBFW
11.03.2025 20:22 UTC
Первоисточник

Комментарии

@aborouhin
11.03.2025 18:26 UTC
+5

Украду, пожалуй, идею брать хэш от безобидного файлика вместо ключевого файла в явном виде.
В остальном у меня другие сценарии, но на серверы давно уже передаю ключик шифрования (раньше LUKS, теперь везде переехал на ZFS) скриптом по сети. При каждой загрузке сервера дёргается скрипт, расшифровывает и подмонтирует хранилище образов дисков виртуалок и потом уже запускает оные. При необходимости вручную или по событию (например, датчику открытия корпуса...) размонтирует и ключик выгружает.

@
11.03.2025 18:38 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
11.03.2025 18:43 UTC
+1

Если у меня (а) внутри моего VPN заведётся MITM, который (b) и fingerprint ssh-сервера подделает, и (c) собственно ssh-соединение расшифрует, - я... хм... изрядно изумлюсь :)

11.03.2025 19:13 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
11.03.2025 19:23 UTC
0

Во-первых, недостаточно. Допустим атакующий попал в VPN и каким-то образом перехватил IP сервера (тоже не вполне очевидная задача). Мой скрипт подключается к этому серверу, и без п. b ругается, что в known hosts не тот фингерпринт и ничего не передаёт.

Во-вторых, ну Вы же не думаете, что в VPN, имеющем доступ к SSH, админкам и пр., у меня толпа народа сидит, и что новые подключения к этому VPN не мониторятся и предварительно не одобряются? (На самом деле всё несколько сложнее, но упрощаю для примера).

11.03.2025 19:57 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
11.03.2025 20:05 UTC
+3

Да нет, как раз спасибо и автору статьи, и Вам, что появился лишний повод пересмотреть свежим взглядом, как оно там устроено и какие векторы атаки насколько успешно закрывает. Вот я, например, никогда не лез в кишки ssh, чтобы понять, как этот фингерпринт генерится, наивно полагая, что уж там точно есть некая криптография, которая не позволит его продублировать просто слушая трафик. Но надо загуглить, пожалуй.

В моей картине мира риск изъятия сервера в ходе совершенно тупого маски-шоу на пару порядков более вероятен, чем риск внедрения злоумышленника во внутреннюю сеть. Но мы ж тут про паранойю, так что надо со всех сторон защититься :)

11.03.2025 20:13 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
11.03.2025 20:55 UTC
0

Ну можно же в https завернуть, например, с проверкой сертификатов, не?

Тогда и ключ не перехватят, и тем более свой не подсунут (а если и подсунут - что это даст кроме отказа)

@max9
11.03.2025 19:40 UTC
+2

неа.

TMPFS_DIR="/tmp/tmpfs_key_$USER"
...
mkdir -p "$TMPFS_DIR"
  if [ $? -ne 0 ] ; then
    exit 0
  fi

слажает на симлинке:

max@xz:~$ rm -Rf /tmp/xz*
max@xz:~$ mkdir /tmp/xz
max@xz:~$ touch /tmp/xz/123
max@xz:~$ ll /tmp/xz*
total 8
drwxrwxr-x  2 max  max  4096 Mar 11 22:31 ./
drwxrwxrwt 17 root root 4096 Mar 11 22:31 ../
-rw-rw-r--  1 max  max     0 Mar 11 22:31 123
max@xz:~$ ln -s /tmp/xz /tmp/xz2
max@xz:~$ ll /tmp/ |grep xz
drwxrwxr-x  2 max  max  4096 Mar 11 22:31 xz/
lrwxrwxrwx  1 max  max     7 Mar 11 22:31 xz2 -> /tmp/xz/
max@xz:~$ ln -s /tmp/xz /tmp/xz2
max@xz:~$ mkdir -p /tmp/xz2
max@xz:~$ echo $?
0
max@xz:~$ ll /tmp/ |grep xz*
drwxrwxrwt 17 root root 4096 Mar 11 22:32 ./
drwxr-xr-x 23 root root 4096 Sep 14 10:56 ../
drwxrwxrwt  2 root root 4096 Feb 28 01:00 .font-unix/
drwxrwxrwt  2 root root 4096 Feb 28 01:00 .ICE-unix/
drwx------  2 root root 4096 Mar  6 19:46 mc-root/
drwx------  4 root root 4096 Feb 28 01:00 snap-private-tmp/
drwx------  3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-ModemManager.service-jZBoE8/
drwx------  3 root root 4096 Mar  4 21:09 systemd-private-4188cc9d91804f6b80f726d21c270ac4-ocserv.service-VIc0Cd/
drwx------  3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-polkit.service-ZRHRw5/
drwx------  3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-porcula.service-Fh0vYx/
drwx------  3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-systemd-logind.service-fYEaRb/
drwx------  3 root root 4096 Mar  5 21:05 systemd-private-4188cc9d91804f6b80f726d21c270ac4-systemd-resolved.service-uOtQ45/
drwx------  3 root root 4096 Feb 28 01:00 systemd-private-4188cc9d91804f6b80f726d21c270ac4-systemd-timesyncd.service-zHCHyx/
drwx------  3 root root 4096 Mar  6 19:54 systemd-private-4188cc9d91804f6b80f726d21c270ac4-transmission-daemon.service-wVXiDO/
drwxrwxrwt  2 root root 4096 Feb 28 01:00 .X11-unix/
drwxrwxrwt  2 root root 4096 Feb 28 01:00 .XIM-unix/
drwxrwxr-x  2 max  max  4096 Mar 11 22:31 xz/
lrwxrwxrwx  1 max  max     7 Mar 11 22:31 xz2 -> /tmp/xz/

далее слажает вгет на уже существующем файле

  wget -q -O "$IMG_FILE" "$SECRET"

  if [ $? -ne 0 ] || [ ! -f "$IMG_FILE" ] ; then

вот так, например

max@xz:~$ wget  -q -O /tmp/123 https://www.rbc.ru/
max@xz:~$ echo $?
0
max@xz:~$ wget  -q -O /tmp/123 https://www.rbc.ru/
max@xz:~$ echo $?
0

создаем симлинк /tmp/$username, подкладываем свое и ждем пока автор выкачает ключ. кстате непонятно какой - приватный или публичный

@JBFW
11.03.2025 20:12 UTC
0

какие проблемы: если вы тот злоумышленник, который УЖЕ сидит на машине и делает симлинки - то вам мешают просто скачать ключ только права на каталог /etc/paranoid/users.
И тогда рут мог бы сконфигурить вместо /tmp - /var/paranoid, и точно так же закрыть правами его.

11.03.2025 20:13 UTC
+2

для уже сидеть на машине и делать симлинки в /tmp достаточно пользователя nginx или подобного с /sbin/nologin и ровно это показывал пример - непривелигерованный пользователь

и да, спойлер - давно придумали mktemp от этих проблем, прерыват цепочку атаки прям на первом пункте, но оный не единственный для "паранойи"

11.03.2025 20:50 UTC
0

И то правда, можно же его подключить к делу. Добавим )

@foxb
11.03.2025 21:35 UTC
0

Идея хорошая, но она не соответствует нескольким исходным критериям. Если вы вынуждены дать доступ (ваш пароль) к диску вашего компьютера, его можно расшифровать. Исправьте меня, если я не прав, но ключ хранится на диске... поэтому каждый, у кого есть доступ, может прочитать файл. Возможным решением является хранение папки на скрытом зашифрованном разделе.

@dartraiden
11.03.2025 22:32 UTC
+1

Всё зависит от модели угроз. Например, если главная угроза - "пришли с обыском, изъяли технику, угрозой «позвонить Путину» заставили сообщить пароль", то, при условии, что вместе с техникой не забрали вас (или забрали, но дали позвонить доверенному лицу), пока техника путешествует к криминалистам, файл из интернета уже может быть и потёрт.

Другая разновидность этой схемы: расшифровка накопителя лишь при одновременном вводе правильного пароля и вставке microSD-карточки с ключевым файлом. Если успеете уничтожить карточку, пока пилят дверь, расшифровать накопитель уже будет невозможно.

Скрытый раздел может применяться, но лучше применять его как дополнение, а не возлагать всю защиту целиком на него.

@JBFW
12.03.2025 07:40 UTC
+1

В том-то и дело, ключ на диске НЕ хранится. Он где-то в другом месте, и если это место неподконтрольно тому кто вынуждает вас выдать пароль - то ключ может быть легко уничтожен третьими лицами, или автоматикой.

@dartraiden
11.03.2025 22:42 UTC
0

Проблема в том, что ключевой файл нужно как-то резервировать. Сервер в интернете это не очень надёжное место. Файл может быть банально потерян из-за сбоя (у выделенного сервера помер накопитель / в облаке произошёл сбой с потерей данных). А если есть копия, то нужно продумать оперативное уничтожение уже двух файлов.

Более того, файл диска не обязан быть именно файлом на диске - это может быть вообще подключаемая флешка

Для тех, кто захочет реализовать это в Windows: такое (ключевой файл на внешнем накопителе) умеет штатный BitLocker. Разумно дополнить эту схему и паролем (это BitLocker тоже умеет), таким образом для расшифровки нужно одновременно и знать (пароль) и иметь (флешку).

@JBFW
12.03.2025 07:56 UTC
0

Есть такая проблема, но ее уже можно решать очень по разному. Именно поэтому ключ не должен быть похож на ключ - и резервная копия ключа может оказаться в самом неожиданном и довольно надежном месте, но об этом никто не будет знать кроме того кто создавал этот ключ - и это не обязательно пользователь под контролем.

Сама идея в том, что в отличии от традиционной схемы защиты, когда "у вас нет ключа от сейфа" - тут ключем от сейфа может быть что угодно: ключ от дверей, кофейная чашка, тапочки, кот с соседней улицы, карандаш, гвоздь-"сотка".

Получив доступ к закрытому сейфу - вы узнаете где этот ключ лежал, но вы не знаете что это такое было. Может быть он у вас в руках, но не попробовав применить - не узнаете этого.
А может быть резервной копии и нет - и этого вы тоже не узнаете.

29.03.2025 11:46 UTC
+1

Что-то вы не то говорите. Вот вы могли бы знать пароль, но хотите, чтобы и при вашем сотрудничестве пароль оставался неизвестным, но ведь вы будете знать где ключ и вкуда он вмонтирован, вы и расскажете...

В практическом применении имеет смысл только что-то, что имеет два ключа, и тогда, если у вас стальные яйца вы выдадите тот ключ, который уничтожит систему. Но работает это только если систему не сдублировать.

Альтернатива - получение ключа извне, и возможность третьих лиц это всё заблокировать. Но тогда вы в целом не нужны, а забирать надо этих третьих лиц...

Собственно еще много лет назад знал людей, которые работали на удаленных машинах, причем где эти машины они не знали. И доступ к ним контролировали совершенно иные люди находящиеся тоже неизвестно где и не имеющие имен. Т.е. нажав ресет на своей рабочей станции ты отключался от работы навсегда. Подключить тебя мог только некто, находящийся где-то и ты должен был ему что-то сказать, а он мог многое проверить. (Видео из офиса к нему шло к примеру итп).

@anzay911
12.03.2025 06:25 UTC
0

Немного автоматизации добавлено в Network-Bound Disk Encryption (NBDE).

@Lazhu
12.03.2025 06:40 UTC
0

@NutsUnderline
12.03.2025 07:21 UTC
0

условие номер два: вы не можете рассказать пароль. Захотите — но не сможете.

условие 2 со звездочкой: иметь способ доказать любопытным злодеям что пароль вы дейcтвительно не знаете

@JBFW
12.03.2025 07:58 UTC
+1

А это уже нюансы: кому и какие доказательства чего требуются, им или вам )

@EchoA
12.03.2025 08:49 UTC
+3

Понравилась идея с картинкой из интернета. Только вот теперь чувствительной информацией становится уже адрес картинки. Даже если она будет своевременно заменена, будет забавно, если её какой-нибудь cdn или web archive запомнит.

@JBFW
12.03.2025 14:32 UTC
0

Вот, спасибо за идею )
Непременно запомнит, значит, надо это учитывать...

@iantonspb
12.03.2025 10:13 UTC
+2

В давно почившем TrueCrypt такое было, можно было любой файл в качестве ключа использовать. А для параноиков была фича с со скрытым диском - два разных ключа, зашифрованное одним лежит в начале контейнера, зашифрованное вторым в конце, и в зависимости от использованного ключа видно либо одно, либо второе. При принуждении можно отдать первый ключ, узнать по контейнеру есть ли второй нельзя. Главное, чтобы обоим фрагментам места хватило.

https://www.truecrypt71a.com/documentation/plausible-deniability/hidden-volume/

@VADemon
13.03.2025 14:53 UTC
0

Узнать можно, по крайней мере так заявил продолжитель дела, без почин трудящийся мисье Idrassi из Франции, в форке VeraCrypt. По наводке анонимного лица. Было исправлено, что именно поменялось - не смотрел.

@xSVPx
29.03.2025 11:52 UTC
0

Эээ... простите, но что мешает требовать оба ключа :)? Если уж утилита штатно так умеет.

Да, у того кто создавал контейнер будут проблемы, если он создал один ключ. Но его проблемы совершенно никого не заботят...