Открытый ключ C # проверяет закрытый ключ Perl и использует его как ключ AES?Возможно и / или жизнеспособно? - PullRequest
1 голос
/ 24 июня 2010

Я подумал, возможно ли и / или целесообразно ли обфускация и безопасность сделать следующее:

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

Из того, что я вижу, Rijndael имеет некоторые ограничения в отношении размера пароля, поэтому возможно ли это (учитывая вывод зашифрованного случайного пароля) ??

Есть ли другой подход, который был бы близок к тому, что я думал или пытался описать здесь?

Это даже сусло?

Причина, по которой я хотел что-то подобное, состоит в том, чтобы в основном кому-то было трудно воспроизвести то, что наш сервер взаимодействует с клиентом, кроме того, что мы используем Smart Assembly. Я хотел бы, чтобы вы, ребята, сосредоточились на приведенных выше вопросах и забыли об упаковке моего кода и т. Д. Если это возможно, подумайте об этом как о нарушении безопасности связи между клиентом и сервером.

С уважением.

1 Ответ

1 голос
/ 24 июня 2010

Я могу обратиться к первой части. Если сервер шифрует ключ своим закрытым ключом, ЛЮБОЙ со своим открытым ключом сможет расшифровать его. Это оставляет зияющую дыру открытой для атаки «человек посередине». Другими словами, если я перехватываю тот же токен, что и вы, я теперь знаю тот же ключ, что и вы. Это означает, что я могу видеть весь трафик, который идет назад и вперед.

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

...