С защитой сообщений открытым ключом все понятно. Я имею пару закрытый/открытый ключ и даю открытый ключ людям, от которых хочу получать шифрованные сообщения. Прочитать их могу только я, т.к. расшифровать их можно только с помощью закрытого ключа.
Однако, у меня задача несколько другая. Допустим есть файл, в котором содержатся параметры лицензии — дата истечения, кол-во пользователей и т.п. Мне нужно зашифровать эту информацию, что бы пользователь не мог ее произвольно изменить. Но чтобы клиентское приложение могло расшифровать и получить эту информацию. Исходя из концепции асимметричного шифрования я — отправитель информации — должен зашифровать файл открытым ключом, а клиент (приложение) иметь закрытый ключ, что бы расшифровать файл. Однако, имея и открытый ключ клиент может расшифровать файл и снова его зашифровать с измененной информацией. Получается, что по сути закрытый и открытый ключи должны поменяться ролями — клиенту я отдаю "закрытый", а "открытый", которым шифрую файл — держать в секрете.
Проблема в том, что я не нашел в .net механизма реализации такого сценария. Классы, предназначенные для асимметричного шифрования (например, RSACryptoServiceProvider) позволяют хранить в хранилище либо только открытый ключ (когда RSACryptoServiceProvider.PublicOnly = true), либо оба ключа вместе.
Как отделить закрытый ключ от открытого и расшифровывать только с его помощью ?
Или возможно есть какие-то другие алгоритмы и их реализации в .net ?

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

A>Допустим есть файл, в котором содержатся параметры лицензии — дата истечения, кол-во пользователей и т.п. Мне нужно зашифровать эту информацию, что бы пользователь не мог ее произвольно изменить. Но чтобы клиентское приложение могло расшифровать и получить эту информацию.

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

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

Зачем шифровать, если клиент все-равно сможет расшифровать? Ведь у него есть, по вашей версии, закрытый ключ. Ваша задача просто подписать данные -- защитить от изменения. Если хотите еще и зашифровать -- зашифруйте симметричным ключем, вшитым в программу.

A>Проблема в том, что я не нашел в .net механизма реализации такого сценария. Классы, предназначенные для асимметричного шифрования (например, RSACryptoServiceProvider) позволяют хранить в хранилище либо только открытый ключ (когда RSACryptoServiceProvider.PublicOnly = true), либо оба ключа вместе.

Там есть метод SingData и SingHash. Их и используйте.

A>Как отделить закрытый ключ от открытого и расшифровывать только с его помощью ?

В .Net (Windows CAPI) -- никак. А вообще можно, но нужна своя реализация. Но в вашем случае надобности в этом нет.

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

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

Вы должны зашифровать информацию закрытым ключем, а клиент расшифровывать ее, пользуясь открытым ключем. Только не спрашивайте меня, как это делать в .net

A>Проблема в том, что я не нашел в .net механизма реализации такого сценария. Классы, предназначенные для асимметричного шифрования (например, RSACryptoServiceProvider) позволяют хранить в хранилище либо только открытый ключ (когда RSACryptoServiceProvider.PublicOnly = true), либо оба ключа вместе.

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

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

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

A>>Допустим есть файл, в котором содержатся параметры лицензии — дата истечения, кол-во пользователей и т.п. Мне нужно зашифровать эту информацию, что бы пользователь не мог ее произвольно изменить. Но чтобы клиентское приложение могло расшифровать и получить эту информацию.

0K>Именно для таких случаев и применяется цифровая подпись. Вы подписываете данные лицензии своим закрытым ключом, а программа проверяет подпись с помощью открытого. Если клиент изменит текст -- подпись будет невалидной.

Я понимаю, что подпись позволяет обеспечить неизменность данных. Но когда необходимо шифрование — совместить его с подписью — красиво — не получается. Понятно как легко и красиво зашифровать XML — http://msdn.microsoft.com/ru-ru/library/ms229746.aspx. Понятно как легко и красиво подписать XML — http://msdn.microsoft.com/ru-ru/library/ms229745.aspx. Но вот совместить эти два варианта, что бы это было красиво — непонятно как, т.к. одной парой ключей и подписывать, и шифровать нельзя, т.к. для проверки подписи используется открытый ключ, а для расшифровки — закрытый, и имея оба ключа клиент может попросту создать желаемые данные, подписать и зашифровать их и никто и не догадается, что данные изменены. Т.е. нужно использовать две пары ключей — одну для подписи, другую — для шифрования. Но это как-то громоздко и некрасиво.. Потому, вопрос, собственно, и заключается в том, что неужели не предусмотрен в криптографических схемах вариант, когда нужно послать шифрованное сообщение, которое можно прочитать вторым ключом, но нельзя этим вторым ключом перешифровать для подмены ? Неужели нет таких алгоритмов ? Казалось бы, задача довольно простая/понятная и нет необходимости каскадировать шифрование/подпись..

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

0K>Зачем шифровать, если клиент все-равно сможет расшифровать? Ведь у него есть, по вашей версии, закрытый ключ. Ваша задача просто подписать данные -- защитить от изменения. Если хотите еще и зашифровать -- зашифруйте симметричным ключем, вшитым в программу.

Шифровать — затем, что бы скрыть данные от глаз пользователя. То, что эти данные расшифрует клиентская программа и их можно подсмотреть в дебаге или в памяти — абсолютно другая тема и проблема.

A>>Проблема в том, что я не нашел в .net механизма реализации такого сценария. Классы, предназначенные для асимметричного шифрования (например, RSACryptoServiceProvider) позволяют хранить в хранилище либо только открытый ключ (когда RSACryptoServiceProvider.PublicOnly = true), либо оба ключа вместе.

0K>Там есть метод SingData и SingHash. Их и используйте.

A>>Как отделить закрытый ключ от открытого и расшифровывать только с его помощью ?

0K>В .Net (Windows CAPI) -- никак. А вообще можно, но нужна своя реализация. Но в вашем случае надобности в этом нет.

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

Хранить ключ вместе с зашифрованными данными — это всё равно что запереть дверь на замок, а ключ от него повесить рядом на гвоздик. Естественно, что для таких глупостей никаких инструментов не предусмотрено.

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

A>Я понимаю, что подпись позволяет обеспечить неизменность данных. Но когда необходимо шифрование — совместить его с подписью — красиво — не получается.

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

Грубо говоря -- подпись -- это и есть шифрование закрытым ключем. Проверка подписи -- расшифровка открытым. Только шифруется/расшифровывается хеш + заголовок, а не само сообщение.

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

A>Шифровать — затем, что бы скрыть данные от глаз пользователя.

Вы не понимаете смысл криптографии Хотя он элементарен: Боб должен получить и прочитать сообщение Алисы, но так, чтобы Ева не смогла это сообщение ни подменить, ни прочитать сама.

Так вот — пользователь это не Ева, а Боб. И он лучший друг ( и даже больше ) Алисы

A>То, что эти данные расшифрует клиентская программа и их можно подсмотреть в дебаге или в памяти — абсолютно другая тема и проблема.

Наоборот, это как раз та самая тема. Добиться того что Вы хотите — то бишь мечты жадных DRM'щиков — можно лишь одним способом, а именно — превращением Боба в Еву Но кто тогда будет пользователем

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

A>>Шифровать — затем, что бы скрыть данные от глаз пользователя.
D>Вы не понимаете смысл криптографии Хотя он элементарен: Боб должен получить и прочитать сообщение Алисы, но так, чтобы Ева не смогла это сообщение ни подменить, ни прочитать сама.
Только подменяет сообщения Мэллори, а не Ева Ева только шпионит.

http://en.wikipedia.org/wiki/Alice_and_Bob

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

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

A>>Шифровать — затем, что бы скрыть данные от глаз пользователя.

D>Вы не понимаете смысл криптографии Хотя он элементарен: Боб должен получить и прочитать сообщение Алисы, но так, чтобы Ева не смогла это сообщение ни подменить, ни прочитать сама.
D>Так вот — пользователь это не Ева, а Боб. И он лучший друг ( и даже больше ) Алисы

Приятно, наверное, считать себя самым умным..? Жаль при этом не хватает внимания понять о чем, собственно, речь..
Начнем с того, что в Вашей гениальной аналогии мсдновскому примеру (с которым я, кстати, давно и хорошо знаком). Требуется не что бы Ева не смогла прочитать и подменить сообщение Алисы, а что бы Алиса не имела возможности сама составлять сообщения (хотя речь вообще не о сообщениях) и выдавать их за сообщения от Боба. Разницу чувствуете ?
Ну и самое главное — речь не об обмене сообщениями. Речь — об единожды получаемой информации, которая 1) ни в коем случае не должна быть подменена, 2) по возможности должен быть максимально затруднен доступ к ней человеческих глаз. Эта информация НЕ для пользователя. Эта информация для клиентского ПРИЛОЖЕНИЯ. Понятно, что ключ для расшифровки все-равно где-то присутствует и при большом желании пользователь может им воспользоваться. Но это дополнительное препятствие.
Пойду убью себя ап стену — смысл криптографии мне недоступен.. Хотя как решить эту задачу я знаю — написал лишь в надежде, что кто-то предложит более элегантный способ, чем совмещение подписи и шифрования..

A>>То, что эти данные расшифрует клиентская программа и их можно подсмотреть в дебаге или в памяти — абсолютно другая тема и проблема.

D>Наоборот, это как раз та самая тема. Добиться того что Вы хотите — то бишь мечты жадных DRM'щиков — можно лишь одним способом, а именно — превращением Боба в Еву Но кто тогда будет пользователем

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

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

A>>Я понимаю, что подпись позволяет обеспечить неизменность данных. Но когда необходимо шифрование — совместить его с подписью — красиво — не получается.

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

0K>Грубо говоря -- подпись -- это и есть шифрование закрытым ключем. Проверка подписи -- расшифровка открытым. Только шифруется/расшифровывается хеш + заголовок, а не само сообщение.

Да мне и нужно, что бы программа расшифровать могла — иначе зачем передавать данные. Ключ, конечно в программу зашивать — достать можно, но не..как два байта переслать.. Как мою задачу решить — не секрет — это "подписывание и энвелопинг" — http://msdn.microsoft.com/ru-ru/library/ms180961(en-us).aspx Думал просто может кто подскажет можно ли как-то избежать необходимости иметь 2 пары ключей — может есть другие алгоритмы.. Но в который раз убеждаюсь, что на отечественных форумах в первую очередь напишут "умники", пытающиеся дерьма из своих голов на окружающих побольше слить.. Это не в Ваш адрес, а "соседям"..

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

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

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

A>Приятно, наверное, считать себя самым умным..?

Многия знания — многия печали. Но Вам не понять...

A>Начнем с того, что в Вашей гениальной аналогии мсдновскому примеру (с которым я, кстати, давно и хорошо знаком).

Вот и выросло поколение, ни о чём кроме MSDN не слышавшее

*Алиса и Боб — персонажи классической статьи в CACM мохнатых 1970-х. А уж сколько лет основной задаче криптографии...

A>Требуется не что бы Ева не смогла прочитать и подменить сообщение Алисы, а что бы Алиса не имела возможности сама составлять сообщения и выдавать их за сообщения от Боба.

Гы! Вы даже здесь умудрились всё перепутать. Алиса шлёт сообщение Бобу, а не наоборот. Ну да ладно, пускай в этом направлении...

Итак, поехали по-кругу. Алиса и Боб — лучшие друзья. Зачем Алисе подделывать сообщения от Боба для самой себя же У неё какое-то психическое расстройство ???

A>(хотя речь вообще не о сообщениях)

Для тех кто не может совершить элементарный переход от IRL-постановки задачи к соответствующей математической абстракции — конечно "не о сообщениях"

A>Разницу чувствуете ?

Да я-то прекрасно всё понимаю. Это у Вас каша в голове.

A>Ну и самое главное — речь не об обмене сообщениями. Речь — об единожды получаемой информации,

Подумайте над выделенным.

A>2) по возможности должен быть максимально затруднен доступ к ней человеческих глаз.

Зачем Ну может пользователь текст лицензии видеть — что в этом страшного ???

A>Эта информация НЕ для пользователя. Эта информация для клиентского ПРИЛОЖЕНИЯ.

Так вот в данном случае это одна и та же сущность — Боб. А Вы хотите его трансвеститом сделать

A>Понятно, что ключ для расшифровки все-равно где-то присутствует и при большом желании пользователь может им воспользоваться. Но это дополнительное препятствие.

Ничего подобного. Для защиты от бытовых хаков — основанных на подмене сообщений — вполне достаточно одной подписи. Накручивание каких-то дополнительных механизмов именно на этот аспект стойкость системы не повысит. Бо чтобы справиться с правильной подписью кулхацкерам нужно перейти на следующий уровень — потрошить уже не сообщения, а код приложения. А тут не важно сколько слоёв шифрования Вы забубените на лицензию — оный модуль тупо отпилят целиком и всё.

Защита кода приложения от ковыряния — вот что делает level up стойкости.

A>Пойду убью себя ап стену —

Лучше поучитесь. Книжки умные почитайте, знающих людей послушайте...

A>смысл криптографии мне недоступен..

Покамест — да, определённо недоступен.

A>Хотя как решить эту задачу я знаю

Вы ничего не решили. Вы всего лишь потратили время на бессмысленную работу. Это нормально, бывает...

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

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

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

A>>Шифровать — затем, что бы скрыть данные от глаз пользователя.

D>Вы не понимаете смысл криптографии Хотя он элементарен: Боб должен получить и прочитать сообщение Алисы, но так, чтобы Ева не смогла это сообщение ни подменить, ни прочитать сама.

D>Так вот — пользователь это не Ева, а Боб. И он лучший друг ( и даже больше ) Алисы

A>>То, что эти данные расшифрует клиентская программа и их можно подсмотреть в дебаге или в памяти — абсолютно другая тема и проблема.

D>Наоборот, это как раз та самая тема. Добиться того что Вы хотите — то бишь мечты жадных DRM'щиков — можно лишь одним способом, а именно — превращением Боба в Еву Но кто тогда будет пользователем

Блин, ну никак не пойму трепетного оттопыривания зада перед западными "инвесторами" — у нас что своих имен нет, а то тут бобы фасоли и всякая хрень!!!

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


А>Блин, ну никак не пойму трепетного оттопыривания зада перед западными "инвесторами" — у нас что своих имен нет, а то тут бобы фасоли и всякая хрень!!!
это тут причем, этож классика Alice_and_Bob