Обратите внимание, что механизм обмена Диффи-Хеллмана не защищен от атаки MITM, поэтому отсутствие шифрования трафика означает, что вам необходимо аутентифицировать данные DH, поступающие с сервера. Вот почему веб-сервер, использующий набор шифров на основе DH, подписывает элементы DH, отправленные по сети, с помощью закрытого ключа своего сертификата сервера, чтобы клиент мог проверить, действительно ли эти элементы получены с сервера, к которому он хочет подключиться. Эти элементы общедоступны, но должны быть подписаны.
То, что вы называете «генерацией хэша полезной нагрузки с разделяемой солью», является кодом аутентификации сообщения с хеш-ключом, поэтому, как вы заметили, он основан на общем секрете, и, поскольку вы не хотите использовать этот механизм, это означает, что Вы не доверяете клиенту. Поэтому для подписи полезной нагрузки необходимо использовать асимметричную криптографию.
Подписание полезной нагрузки сервера с помощью асимметричного алгоритма означает, что сначала вам нужно разрешить серверу делиться открытым ключом с клиентом. Поскольку вы не шифруете данные между клиентом и сервером, вам необходимо развернуть открытый ключ сервера внутри исходного кода клиента.
Вы говорите о процессе генерации подписи, но процесс проверки подписи на стороне клиента также очень важен в вашем случае, потому что общее время, которое пользователь должен ждать результата, - это добавление времени для подписи и время для проверки подписи (более того, подпись часто может ожидаться на сервере, если подписываемые данные не генерируются динамически, но никогда нельзя ожидать проверки). Поэтому вам нужен быстрый способ проверки подписи на стороне клиента. Сначала подпишите хеш, а не всю полезную нагрузку. Затем выберите самый быстрый алгоритм асимметричной подписи, который доступен в вашей среде разработки на стороне клиента. Обратите внимание, что проверка подписи RSA выполняется быстрее, чем проверка подписи DSA или ECDSA, для соответствующей длины ключей, соответствующей тому же уровню безопасности. Так что вам стоит остаться с RSA.
Все это, пока эта строка не может вам так сильно помочь! Теперь есть способ повысить производительность, используя RSA для подписи и проверки подписей, и этот способ довольно похож на тот, который реализует SSL / TLS для увеличения производительности браузера при загрузке нескольких страниц или других объектов с одного сервера: использует кеш сессии . Вы делитесь общим секретом для определенного сеанса с одним конкретным пользователем. Никогда не используйте этот общий секрет для других сессий. Когда пользователь подключается в первый раз, используйте RSA только один раз, чтобы обменяться эфемерным общим секретом или обменяться материалами DH для создания этого общего секрета. Затем каждый раз, когда серверу необходимо подписать объект, он создает код аутентификации сообщения с хеш-ключом с этим конкретным секретом. Поэтому, если пользователь находит секрет, например, используя режим отладки своего браузера, это не проблема: этот секрет предназначен только для того, чтобы помочь ему узнать, что то, что исходит от сервера, не было изменено. Поэтому пользователь не может использовать этот секрет для изменения обмена данными между сервером и другими пользователями.