jcmvbkbc

где обязательным условием для расшифровки является наличие iv.

А именно, того же IV, что был использован при шифровании.

какие есть варианты решения данной проблемы?

- использовать фиксированный IV (например все нули).
- генерировать его из хранимых данных (например какой-нибудь хеш от пароля). В википедии упоминается похожий вариант: "a cipher or a hash function is used to generate the IVs from the key and the current sector number".
- использовать режим CTR.

Можно ли как-то защититься от этого; есть ли для этого какие-то специальные протоколы?

Для этого бывают key signing party, когда сопоставление ключа и владельца происходит очно.
Либо PKI, если не стрёмно отдать эту функцию на аутсорс.

как можно проверить их на случайность?

Невозможно проверить их "на случайность" (потому что существует бесконечное число отображений, превращающих регулярную последовательность в последовательность выглядящую случайно).
Но можно проверить качество распределения с помощью dieharder.

При одинаковой длине ключей, симметричных и асимметричных, криптостойкость алгоритмов разная. И криптостойкость симметричных выше. Асимметричных ниже. ...

Как это объяснить?

Это объясняется тем, что у симметричных и асимметричных алгоритмов разная природа.
Симметричные (например AES) используют ключ для генерации преобразования входного блока в выходной. Количество бит в ключе напрямую определяет размер пространства преобразований -- 128-битный ключ даёт 2¹²⁸ возможных значений выходного блока для каждого входного.
Асимметричные используют ключ по-разному, поэтому нужно рассматривать конкретный алгоритм. RSA использует биты ключа для хранения произведения двух простых чисел. 128-битный ключ даёт 64-битные простые числа. Факторизация 128-битного числа не требует перебора 2¹²⁸ вариантов и занимает на обычном современном железе порядка секунды.

можно сделать откреплённую подпись: gpg -b <подписываемый файл> или gpg -a -b <подписываемый файл>

Настройки должны были остаться в домашнем каталоге. Установи cryptkeeper обатно и всё должно работать.
Однако, я подозреваю, что пароли надо вводить при монтировании, так что если пароли утеряны, то, наверно, всё...

Мне говорит

RSA operation error
140624383731344:error:0406506C:rsa routines:RSA_EAY_PRIVATE_DECRYPT:data greater than mod len:rsa_eay.c:518:

Что такое Key-ID

key-ID -- это хвост фингерпринта ключа. Фингерпринт -- это уникальный идентификатор ключа, по нему можно найти ключ на публичном сервере или идентифицировать его в командах gpg. Именно его проверяют на key-signing party. 8 цифр по нынешним меркам считается мало, лучше использовать 16.
Например:

gpg --fingerprint --list-keys F83FA044
pub   4096R/F83FA044 2012-05-28
      Key fingerprint = 2B67 854B 98E5 327D CDEB  17D8 51F9 CC91 F83F A044
uid                  Max Filippov <filippov@cadence.com>
uid                  Max Filippov <max.filippov@cogentembedded.com>
uid                  Max Filippov <jcmvbkbc@gmail.com>
sub   4096R/161A72EA 2012-05-28

F83FA044 -- это хвост

Key fingerprint = 2B67 854B 98E5 327D CDEB  17D8 51F9 CC91 F83F A044

Что такое этот самый "сертификат" который я могу экспортировать используя Kleopatra в файл с расширением .asc и является ли он секретным?

Я не знаю, что можно экспортировать из Kleopatra, но .asc -- это просто ascii-текст. Любой ключ или набор ключей можно экспортировать в ascii, достаточно добавить -a к команде экспорта.

Public-key ко всему этому каким боком относится и как он хотя бы выглядит?

Выглядит как-то так: gpg -a --export <key-id>
Имея его можно зашифровать сообщение для владельца соответствующего секретного ключа.
Его можно заслать на сервер ключей или передать в текстовом виде отправителю сообщения. Отправитель может импортировать его с ключевого сервера по key-ID или из текста.

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

hash(пришедший хэш + соль из БД для этого пользователя)

Тут вы говорите о соли в БД, это ок.

hash(password+hash(слово))

Тут вы говорите о вычислении парольного хеша на клиенте, называя hash(слово) солью. Это неправильное использование термина. Соль должна быть случайной.

Возможно ли будет взломать пароль с динамической солью которая нигде не хранится?

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

Обратимы ли функции S0, S1, E0, E1 из алгоритма SHA-256?

Σ0 ( A ) = ( A ⋙ 2 ) ⊕ ( A ⋙ 13 ) ⊕ ( A ⋙ 22 ) -- обратима.
Σ1 ( E ) = ( E ⋙ 6 ) ⊕ ( E ⋙ 11 ) ⊕ ( E ⋙ 25 ) -- тоже обратима.
Что такое E0 и E1 я не нашёл.

Таблицу всех значений S0 и S1 можно построить за несколько минут, если есть свободных 16Г памяти. Все они различны, т.е. обратное преобразование однозначно.
Можно ли найти простую обратную функцию -- непонятно.

1. словом salt обозначают открытую случайную последовательность, нужную для борьбы с rainbow tables. Если материал секретный, то это либо ключ, либо производная от него.

2. K2 и SALT2 в вашем алгоритме не нужны совсем, поскольку никак не используются второй стороной. По сути вы отправляете с замка случайный H2 и проверяете, что ключ знает SALT3.

3. В описании нигде не видно, как ключ и замок идентифицируют сообщения как часть одного процесса аутентификации. Ну т.е. как замок получив что-то (предположительно H3) ассоциирует это с ранее отосланным H2?

Вы странный вопрос задаёте: PSK (pre shared key) -- это способ аутентификации: общий пароль известный станции и точке доступа, а TKIP (temporal key integrity protocol) -- это способ шифрования и обеспечения целостности данных, это независимые вещи.

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

https://ru.wikipedia.org/wiki/Частотный_анализ

Я изучил найденные примеры реализаций этой операции, однако все они используют побитовый сдвиг

Но зачем? Для определения было ли переполнение или нет? Но это можно определить просто сравнив результат сложения (беззнаковый) с любым из слагаемых: в случае переполнения сумма меньше любого слагаемого.
Т.е. имея массивы представляющие 32-битные части слагаемых и результата можно написать так (C):

void AddModulo512(const uint32_t *a,const uint32_t *b, uint32_t *c)
{
    unsigned carry = 0;
    unsigned i;
    for (i = 0; i < 16; ++i) {
        c[i] = a[i] + b[i] + carry;
        carry = a[i] + carry < carry || c[i] < b[i];
    }
}

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

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

Если у вас есть /dev/urandom то всё уже смешано как надо, берите случайные биты оттуда.

Как случайный поток байт превратить в число на отрезке, что бы оно оставалось достаточно случайным?

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

С целыми числами нужно взять столько случайных бит, сколько покрывает нужный вам отрезок, значения которые не вписываются в отрезок выкинуть и сместить полученное значение к началу отрезка. Для плавающих чисел ещё проще: нужно взять единицу вашего плавающего типа, заменить биты мантиссы (23 для float, 52 для double) случайными битами и отнять 1. Получится случайное число в диапазоне [0, 1), умножить его на длину отрезка и сместить к его началу.

В частном случае, если криптостойкость не нужна, то для получения раномерно распределённых на отрезке [a, b) плавающих чисел проще всего взять drand48: r = drand48() * (b - a) + a.