Идея в следующем:
в программу на клиенте надо "зашить" приватный ключ, а на сервере — "публичный"
При обращении за данными к вебсервису сервер шифрует данные открытым ключем и передает их клиенту, а тот приватным расшифровывает

Это надо для того чтобы юзер не мог посмотреть эти данные — вот поэтому SSL не предлагать!!!!!!!!

Я не знаю как получить эти ключи и как с ними работать — помогите плз

Здравствуйте, Аноним, Вы писали:

А>Идея в следующем:
А>в программу на клиенте надо "зашить" приватный ключ, а на сервере — "публичный"
А>При обращении за данными к вебсервису сервер шифрует данные открытым ключем и передает их клиенту, а тот приватным расшифровывает

А>Это надо для того чтобы юзер не мог посмотреть эти данные — вот поэтому SSL не предлагать!!!!!!!!

А>Я не знаю как получить эти ключи и как с ними работать — помогите плз

Самый простой способ — использование .NET Remoting в котором используешь в данных любое шифрование.
Но обращаю внимание на то, что раз закрытый ключ хранится на клиенте, то там же лежит и пароль от него в открытом виде да и сам ключ. Поэтому клиент запросто сможет расшифровать трафик. (ЗЫ: закрытый и открытый ключи в симметричных алгоритмах это половинки одного и того же целого ключа. Между собой никак не отличаются, просто один обзывают открытым и выкладывают, а второй закрытым и дополнительно шифруют)
Также, учитывая, что .NET декомпилируется легко — то подход к решению задачи, думаю просто неверен и реализовать ее нужно немного по другому в зависимости от того, что конкретно требуется и какой уровень защиты нужен.

Здравствуйте, Аноним, Вы писали:

А>Идея в следующем:
А>в программу на клиенте надо "зашить" приватный ключ, а на сервере — "публичный"
А>При обращении за данными к вебсервису сервер шифрует данные открытым ключем и передает их клиенту, а тот приватным расшифровывает

А>Это надо для того чтобы юзер не мог посмотреть эти данные — вот поэтому SSL не предлагать!!!!!!!!

1. SSL работает по принципу открытого/закрытого ключей.
2. Если у клиента будет закрытый ключ, то он сможет расшифровать те данные, которые вы ему передали. Возможно в вашем случае можно выкрутиться хешем данных.
3. Технически SSL посмотреть сложнее (т.к. реализация в нейтив коде и рефлектором не посмотришь).

А>Я не знаю как получить эти ключи и как с ними работать — помогите плз

Здравствуйте, Clevelus, Вы писали:

C>Здравствуйте, Аноним, Вы писали:

А>>Идея в следующем:
А>>в программу на клиенте надо "зашить" приватный ключ, а на сервере — "публичный"
А>>При обращении за данными к вебсервису сервер шифрует данные открытым ключем и передает их клиенту, а тот приватным расшифровывает

А>>Это надо для того чтобы юзер не мог посмотреть эти данные — вот поэтому SSL не предлагать!!!!!!!!

А>>Я не знаю как получить эти ключи и как с ними работать — помогите плз

C>Также, учитывая, что .NET декомпилируется легко — то подход к решению задачи, думаю просто неверен и реализовать ее нужно немного по другому в зависимости от того, что конкретно требуется и какой уровень защиты нужен.

для этой цели был куплен обфускатор с защитой от декомпиляции и дебугения
здесь имеется в виду некая система лицензирования по — клиент запрашивает с сервера лицензию, а сервер смотрит, что за клиент, его IP и выдает сроки работы по лицензии — и шоб ацкий хаккер не поломал ничего — надо трафик шифровать

Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, Аноним, Вы писали:

А>>Идея в следующем:
А>>в программу на клиенте надо "зашить" приватный ключ, а на сервере — "публичный"
А>>При обращении за данными к вебсервису сервер шифрует данные открытым ключем и передает их клиенту, а тот приватным расшифровывает

А>>Это надо для того чтобы юзер не мог посмотреть эти данные — вот поэтому SSL не предлагать!!!!!!!!

0K>1. SSL работает по принципу открытого/закрытого ключей.
0K>2. Если у клиента будет закрытый ключ, то он сможет расшифровать те данные, которые вы ему передали. Возможно в вашем случае можно выкрутиться хешем данных.
0K>3. Технически SSL посмотреть сложнее (т.к. реализация в нейтив коде и рефлектором не посмотришь).

Щасэто уже не проблема подсматривать за SSL — Fiddler отчасти это делает

Здравствуйте, Аноним, Вы писали:

А>Идея в следующем:
А>в программу на клиенте надо "зашить" приватный ключ, а на сервере — "публичный"
А>При обращении за данными к вебсервису сервер шифрует данные открытым ключем и передает их клиенту, а тот приватным расшифровывает

А>Это надо для того чтобы юзер не мог посмотреть эти данные — вот поэтому SSL не предлагать!!!!!!!!

А>Я не знаю как получить эти ключи и как с ними работать — помогите плз


а можно коимто образом в ресурсы запихнуть сертификат и затем работать с ним???

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Идея в следующем:
А>>в программу на клиенте надо "зашить" приватный ключ, а на сервере — "публичный"
А>>При обращении за данными к вебсервису сервер шифрует данные открытым ключем и передает их клиенту, а тот приватным расшифровывает
А>>Это надо для того чтобы юзер не мог посмотреть эти данные — вот поэтому SSL не предлагать!!!!!!!!
А>>Я не знаю как получить эти ключи и как с ними работать — помогите плз
Повторяю — пароль и сам сертификат лежат у клиента. Больших знаний не нужно, чтобы их достать, если не принимать никаких действий. Смысл заморачиваться с сертификатами? Сертификаты Вам может выдать любой центр сертификации, — проще всего поднять свой на Windows Server 2003 или Linux и выдать самому себе — статей в Интернете навалом.
Если пойдете этим путем, то для хранения пароля используйте костанту типа SecureString.

А>а можно коимто образом в ресурсы запихнуть сертификат и затем работать с ним???
Легко — поиск по форуму как получить ресурсы. Просто добавляете файл в проект и в опциях компиляции ставите встроенный ресурс.
Но мое мнение — ЗАЧЕМ? если закрытый ключ на клиенте используйте ремоутинг с ассиметричным шифрованием (сам ключ-пароль храните все равно в классе SecureString)

А>>а можно коимто образом в ресурсы запихнуть сертификат и затем работать с ним???
C>Легко — поиск по форуму как получить ресурсы. Просто добавляете файл в проект и в опциях компиляции ставите встроенный ресурс.
C>Но мое мнение — ЗАЧЕМ? если закрытый ключ на клиенте используйте ремоутинг с ассиметричным шифрованием (сам ключ-пароль храните все равно в классе SecureString)

Я просто хочу использовать ассиметричное криптование с приватным и публичным ключем- для этого мне надо как-то эту пару получить — и потом какой использовать провайдер для шифрования\дешифрования (просто я более или менее наслышан о работе с ключами при обмене сертификатами)?

Здравствуйте, Аноним, Вы писали:

А>>>а можно коимто образом в ресурсы запихнуть сертификат и затем работать с ним???
C>>Легко — поиск по форуму как получить ресурсы. Просто добавляете файл в проект и в опциях компиляции ставите встроенный ресурс.
C>>Но мое мнение — ЗАЧЕМ? если закрытый ключ на клиенте используйте ремоутинг с ассиметричным шифрованием (сам ключ-пароль храните все равно в классе SecureString)

А>Я просто хочу использовать ассиметричное криптование с приватным и публичным ключем- для этого мне надо как-то эту пару получить — и потом какой использовать провайдер для шифрования\дешифрования (просто я более или менее наслышан о работе с ключами при обмене сертификатами)?

Когда два ключа приватный и публичный — то шифрование симметричное! то что зашифровано открытым — лкгко расшифровывается закрытым и наоборот! Именно на этом строится принцип шифрования с одной стороны и цифровой подписи с другой. Обратитесь к теории!
Ассиметричное, это когда информацию конечной длины или поток информации шифруют так, что можно расшифровать только зная ключ (пароль, хеш ...). Именно ассиметричным шифрованием шифруют половинку ключа, обозванную закрытым ключом, чтобы его нельзя было просто использовать если украдут.

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

За Вас разбираться что Вам надо и писать код совсем не хочется.

C>Когда два ключа приватный и публичный — то шифрование симметричное! то что зашифровано открытым — лкгко расшифровывается закрытым и наоборот! Именно на этом строится принцип шифрования с одной стороны и цифровой подписи с другой. Обратитесь к теории!

Знаете, даже спорить не хочется, ибо здесь мы видим грубейшее незнание теории... обратитесь-ка лучше сами к этой самой теории (Брюс Шнайер "Прикладная криптография" — самая попсовая и, вместе в тем, самая основная книжка по прикладной криптографии)

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

Но если коротко, то симметричное и ассиметричное шифрование свои названия получили именно из-за типа шифрования. В симметричном шифровании используется ОДИН ключ, им одним и шифруется и расшифровывается, поэтому и названо "симметричным". Ассиметричные алгоритмы строятся на том, что шифруется сообщение с помощью открытого ключа (видимого всем), а расшифровывается ТОЛЬКО закрытым (известного ТОЛЬКО получателю сообщения, который выдает открытый ключ). В таких алгоритмах общий ключ — это пара из закрытого и открытого ключа, по отдельности они бесполезны, зная открытый ключ невозможно получить закрытый, зная открытый ключ невозможно получить исходное сообщение. Самый классический и самый известный ассиметричный алгоритм шифрования — алгоритм Райвеста-Шамира-Адлемана, всем известный RSA. Он основывается на малой теореме Ферма (но это уже так, детали... у Шнаера, я думаю, про это написано).

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

А вообще для обмена ключами существуют специально для этого разработанные алгоритмы. Самый классический — алгоритм Диффи-Хэлмана. Правда он уязвим к атаке типа man-in-the-middle (это когда злоумышленник перехватывает сообщения между клиентом и сервером и подменяет их на свои), поэтому есть модификация алгоритма Диффи-Хэлмана, лишенная этой уязвимости. Есть и другие алгоритмы.