Армянское Радио

Сам криптоматор есть, но encfs - лучше

Ну, на то она и парольная фраза, чтобы стойкой быть.

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

Через ssh ключи передайте и все.

Вы посылаете в голом виде K1 и MD5(K1 || SALT1)? В таком случае, вашему костылю крышка, любой желающий подберет SALT1.

Вы как обычно схлопотали закононом Шнаера.

Вы опасно некомпетентны в криптографии

tox и его вариации - utox, antox (для Андроида) и так далее

Огромное, НУ ОЧЕНЬ ОГРОМНОЕ количество - 256^12=79228162514264337593543950336 штук строк (если все символы использовать)

Но так как строка обычно в BASE64, это может быть немного меньше -
64^12=4722366482869645213696

Побитовый сдвиг вправо на 1 бит - это деление на 2 с отбрасыванием дробной части.
Побитовый сдвиг влево на 1 бит - это умножение на 2.

Про GMP знаете?

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

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

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

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

В криптографии следует использовать сторонние утилиты, так как реализовать качественную защиту крайне сложно.

Алиса - имя начинается на A, Боб - имя начинается на B, Чарли - имя начинается на C.
A, B, С - первые буквы английского алфавита.
Так что это просто удобные обозначения для сторон обмена информацией.

Тут сложность в том, что генерироваться ключи должны специализированным дорогущим оборудованием с кучей сертификатов, поэтому их изготавливает УЦ и секретным образом (так, что ЗК не сохранятся в УЦ и не станет известен его сотрудникам) передает своему клиенту.

Открытый/закрытый - статус публичности ключа.

Шифрование называется асимметричным не потому что что-то там открыто, а что-то закрыто, а потому, что для шифрования используется один ключ из пары, а для расшифровки - второй.

Сами ключи при этом для алгоритма не различаются никак, нет привязки, что открытый - шифрует, закрытый - расшифровывает.

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

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

• клиент подключается к серверу, поддерживающему TLS, и запрашивает защищённое соединение;
• клиент предоставляет список поддерживаемых алгоритмов шифрования и хеш-функций;
• сервер выбирает из списка, предоставленного клиентом, наиболее надёжные алгоритмы среди тех, которые поддерживаются сервером, и сообщает о своём выборе клиенту;
• сервер отправляет клиенту цифровой сертификат для собственной аутентификации. Обычно цифровой сертификат содержит имя сервера, имя удостоверяющего центра сертификации и открытый ключ сервера;
• клиент может связаться с сервером доверенного центра сертификации и подтвердить аутентичность переданного сертификата до начала передачи данных;
• для генерации сеансового ключа для защищённого соединения клиент шифрует случайно сгенерированную цифровую последовательность открытым ключом сервера и посылает результат на сервер. Учитывая специфику алгоритма асимметричного шифрования, используемого для установления соединения, только сервер может расшифровать полученную последовательность, используя свой закрытый ключ.