CityCat4

зашифровал домашнюю папку по инструкции

Зачем? Ну то есть от кого пытаетесь защититься?
От жены/мужа/соседа - смысла особо не имеет, разве только в общаге живете.
От работодателя при удаленке - ну, может какой-то смысл есть...
От работодателя в офисе, от государства - смысла нет, так как никто Вашу "зашиту" ломать не будет. Ломать будут Вас.

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

Никак. Если бы там массив был, хотя бы килобайта два текста - можно было бы попытаться. А разгадать 4 байта - дохлый номер.

Скрипты визуалки пытаешься расшщифровать, что ли? Фиг чего получится.

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

Очередной гений разработки хочет защитить свое чудо-творение? Его и с помощью JS невозможно защитить ;) Можно затруднить расшифровку, не более

А подключение к exchange есть?

А что, в гугле забанили?

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

Для частотного анализа маловата строка. А вообще рекомендую перечитать рассказ "Пляшушие человечки" - мне он почему-то сразу вспомнился

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

В голову приходят следующие мысли:
- Белый раздел первый, шифрованный второй
- Для загрузки с шифрованного нужен отдельный носитель с загрузчиком
- Таблица разделов на SSD правится вручную hex-редактором так, чтобы последний цилиндр раздела был последним цилиндром диска, чтобы различные менеджеры разделов не видели пустого места в пол-винта (что закономерно вызовет интерес - а что это тут?)

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

Видимо потому что больше не поддерживается. Кому и зачем он нужен сейчас? Он все еще считается достаточно криптостойким, но уже выводится из оборота.

а вот как не дать заглянуть в мой проект хостеру?

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

Первое, что приходит на ум - DPD. Если DPD включен, нужно чтобы керио его правильно ловил а не опускал соединение по неактивности (этим грешит racoon)
второе - при истечении таймаута на 75% заново проводится фаза2, возникает новое SPI, устройства начинают путаться в том, какую SPI использовать и так продолжается до тех пор, пока старая SPI не сдохнет (а это как раз 7 - 10 минут может занять).

Что можно сделать - посмотреть таймауты по фазам и политику их назначения и если можно забрать на микротики их назначение, может быть прибавить времени, отключить dpd (разумеется это все при наличии возможности это сделать - а то может быть там фиксированный набор настроек)

"Все украдено до вас".
У Synology есть такое решение - типа частного облака, мы так с контрагентами документацией меняемся.

Политика горит красным потому что нет соответствующих настроек Peer и Identity, либо они неверные/неприменимые.
Вот такой proposal я использую для одной немного больной на голову конторы:

/ip ipsec proposal
add auth-algorithms=sha256,sha1,md5 enc-algorithms=\
    aes-256-cbc,aes-256-gcm,aes-192-cbc,aes-192-gcm,aes-128-cbc,aes-128-gcm lifetime=1h

Смысл в том, чтобы дать той стороне выбрать и посмотреть, что она выбрала. "Там" у меня циска, и она выбирает auth sha1 и шифронабор aes256-cbc
А вообще в таких случаях включается лог. Ну и кроме того, уберите пассивку, пусть микротик сам подолбится и посмотрите на ошибки.

SHA, конечно же причем начиная с sha256

owa или десктопный outlook?
В прикрепленном файле что?
В свойствах сообщения совсем ничего про шифрование?