Передача симметричного ключа асимметричному ключу

Question

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

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

Хорошо, у меня есть связь клиент -> сервер.Клиент, которого я могу жестко закодировать в общедоступной части 2048-битного ключа RSA.Когда клиент хочет инициировать безопасное соединение, он отправляет свое имя пользователя, md5-хэш своего пароля и хэш случайного UUID, все из которых были зашифрованы с использованием открытого ключа сервера.Сервер получает информацию и расшифровывает ее, используя свой закрытый ключ.Проверяет базу данных, работают ли его login + pass, и если они работают, создайте новую запись в таблице "Сеансы" в базе данных.Это включает в себя идентификатор сеанса, UID (идентификатор пользователя) и хэш UUID.Используя UUID соответствующего идентификатора сеанса в качестве ключевой фразы, сервер затем отправит обратно сообщение, содержащее зашифрованное в Blowfish слово "Успех!" + случайный UUID (это сообщение имеет цифровую подпись, чтобы мы могли определить, пришло оно с сервера или нет).С этого момента, когда клиент отправляет информацию на сервер, она будет содержать открытый текстовый идентификатор sess_id и включать зашифрованное сообщение Blowfish, используя соответствующий идентификатор сеанса blowfish secret (хранящийся в зашифрованном виде в БД) в качестве ключа для шифрования / дешифрования.

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

Answer 1

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

• Если вы используете генератор UUID, а не настоящий криптографический RNG, скорее всего, у него недостаточная энтропия.Не сбрасывайте это со счетов - в реальном мире излюбленным способом скрытого ослабления системы шифрования было ослабление ГСЧ;

• Ваше первоначальное шифрование RSA звучит так, как будто оно подвержено атаке с малым показателем и, возможно, другим креативным атакам.Там слишком много структуры, чтобы быть комфортным;

• Похоже, существует множество возможностей для повторных атак;

• Какой режим блочного шифрования вы используете с Blowfish?

Я рекомендую использовать TLS / SSL - на него смотрели гораздо более дружелюбные глаза гораздо дольше, чем на все, что вы создаете сами, когда-либо.

Answer 2

Просто используйте SSL или DTLS, IKEv2, HIP, EAP или какой-нибудь подходящий стандартный протокол.Не пытайтесь изобретать свои собственные криптопротоколы, ни у кого нет достаточного опыта, чтобы сделать это самостоятельно.Насколько я могу видеть, в вашем протоколе недостаточно энтропии, поэтому ваши результирующие ключи будут довольно слабыми.

Answer 3

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

Если вы отправляете идентификатор сеанса в виде открытого текста и используете его в качестве ключа шифрования, насколько это безопасно?

Я не вижу причин, по которым вы не можете использовать стандартную SSL-аутентификацию и позволить разработчику библиотеки беспокоиться о квитировании.