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

На первый взгляд, самым простым явлется:
1. при коннекте получаем динамически сгенерированный ключ для симметричного шифрования
2. криптуем все по XOR и т.д.

Вопрос.
Как безопасно передать клиенту этот самый ключ? С той точки зрения, что злоумышленник
вполне может законнектиться к серверу как гость клиентской прогой, ему скидывается ключ,
он его отлавливает. Потом перехватывая дальнейшие зашифрованные этим ключом сообщения, и предположив, что наверняка шифрование идет по XOR, (а при желании и просто глазами :)) сможет понять, как звучат команды клиентского приложения и написать свою программу, которая так же будет коннектиться, получать ключ и слать эти самые команды.
Надеюсь понятно объяснил.

Стоп. Кажется лучше нетак, лучше ассиметричное использовать наверно.
1. На сервере генерим открытый и закрытый ключи.
2. Клиенту шлем открытый ключ, зашифрованный по своему алгоритму шифрования
3. Клиентская прога его расшифровывает и начианет шифровать по опять же своему алгоритму

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

На дискете или на флэшке. Это понятно :)
Хотлеось бы по проводам, через спутники и т.д. :)

В общем вряд ли что-то новое услышу наверно.
Буду пытаться сделать как-нибудь.
Еще бы по скорости расшифровки на сервере не подкачать :)

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

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

Но это все равно конечно же взламывается поэтому вопрос перерождается в такой.
Стоит ли использовать ключи в этом случае вообще или можно просто ограничиться разработкой индивидуального механизма шифрования?
Что могут дать ключи кроме лишнего трафика?
Могут ли они ускорить? Вряд ли...
Есть мысль, чтобы ключи работали в роли механизмов, генерирующих механизмы шифрования.
То есть так, чтобы например клиент законнектился один раз, ему сгенировали ключ, на основании которого формируется новый алгоритм шифрования, то есть ключ используется не для шифрования, а для генерации алгоритма шифрования.
Хотя опять же: отдебажили программу и поняли как формируются алгоритм шифрования и т.д.
Бред в общем.

Берлuнгер, это уже осознал, просто вопрос уже в том нужны ли они вообще ключи в моем случае?
То есть защита не трафика отдельно взятого клиента, а защита от подделки команд.
Злоумышленник запускает клиентскую прогу, той прилетает открытый ключ.
Далее клиентская прога, используя его, шлет команды серверу.
Я таких мастеров не видел, но думаю, что они есть, которые мгут взять продебажить программу на предмет того как именно она шифрует сообщения этим ключом и понять, какие именно команды шифрует. И написать свою программу, которая будет коннектиться к серверу и слать "левые" команды.

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

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

То есть пример.
Есть два коннекта от юзеров ID=1 и ID=2
Допустим юзер 1 шлет команду типа от имени второго:
2!some_exec (просто пример)
на сервере просто проверяем соответствует ли id коннекта id, которое пришло от юзера, если нет, команда не выполняется ну и так далее в том числе на уровне субд.

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

Kew,
1) Может неудачныый пример, "вконтаке" одно время многим было интересно смотреть закрые страницы пользователей банально подставляя его id в url нужной страницы. Когда эту возможность закрыли, желающих значительно поубавилось (не знаю правда как сейчас обстоят дела у них с защитой)
У меня примерно такая же дыра, за тем исключением, что все же надо хотя бы уметь перехватывать пакеты по сети и потом суметь сделать прогу генерирующую пакеты нужного формата (с нужными зашифрованными командами).

2) Цена... Прежде всего глубокое недовольство собой, что не смог уберечь юзеров )))
Ну и досадно за напрасно потраченное время, если получится, что старался сделать хорошо, но оказалось, что взломать это можно без особых усилий.
3) Исходя из того, что Q имеет больше моральной составляющей, то и для успокоения души так сказать, хотелось бы повозиьтся, чтобы потом было спокойнее.

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

Просто хочется сделать хорошую, качественную вещь.
При этом делаю уже довольно давно :)
Начинал с веб-интерфейса с asp.net и т.д., потом пришел к выводу, что это медленно и дает большую нагрузку на сервер, в то время как можно сделать просто вин-приложение - спустить на него львиную долю логики с сервера + сервер приложений вместо веб-сервера ну и субд-шка.
Поэтому взял, что умею получше (Delphi), переписал все на нем.
Пока только в первом приближении, но вот по ходу встал вопрос про шифрование.
Понимаю, что делфи тоже далеко не самый быстрый вариант, но все же :).
Еще добавлю, что модульность разарботки конечно позволяет сначала все сделать без шифрования, чтобы хотя сделать некую вещь, выполняющую предполагаему функциональность.
Потом уже прикрутить шифрование. То есть сначала до конца сделать саму штуку.
Но по пути пока делаю, хотелось бы узнать, куда копать потом :)

rstudio, почитал про RSA . Впечатлило...
Атака Франклина-Рейтера... Атака Хастада... Метод факторизации Ферма...
Звучит очень круто :) Так и умным можно стать )))
Самое интересное, что вроде бы как сам алгоритм довольно прост в реализации (как мне показалось на первый взгляд). Единственное, что трафик пожрет конечно, (про вычислительные ресурсы пока не думал сильно).

mayton, насчет SSL, насколько помню, там заморочки с сертификатами, геморрой имхо.

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