Реализация рукопожатия для сокетного соединения

Question

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

Мне интересно, какой длины должно быть рукопожатие, чтобы оно было достаточно безопасным, но также достаточно коротким, чтобы минимизировать накладные расходы на данные, поскольку я хотел бы, чтобы это было с низкой задержкой.

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

Любой вклад высоко ценится.

Answer 1

Я бы использовал соединение HTTPS для связи клиент / сервер. Он прост в использовании (почти все основные SDK реализуют его) и обеспечивает хорошую подпись.

Привет.

PD: в отношении метода шифрования я бы использовал Whirlpool , потому что мистер Ривест сказал в 2005 году, что он был взломан.

Answer 2

Это может быть не так просто, как кажется. Обратите внимание, что если вы отправляете что-либо в чистом виде по сети (например, идентификатор сеанса / рукопожатие), любой может прослушать сообщение и повторно использовать это значение, чтобы действовать в качестве клиента. Если вы не можете использовать https, как было предложено в первом ответе, вам, вероятно, нужно взглянуть на протоколы согласования ключей . Как только обе стороны договорились об общем секретном ключе (который не может быть восстановлен на основе наблюдаемых сообщений), вы можете использовать его для аутентификации всех оставшихся передач с MAC (например, HMAC).

Что бы вы ни делали, не используйте MD5, он полностью сломан. Whirlpool также не может быть хорошим вариантом, он медленнее и недавно (теоретическая) атака на основную его часть, см. Программа ASIACRYPT 2009 . Я бы придерживался SHA-256 сейчас.