Сон Веры Павловны,

не проще вместо "AES + ключ в ресурсах" воспользоваться http://msdn.microsoft.com/ru-ru/library/system.security.cryptography.protecteddata(v=vs.110).aspx ?

Сон Веры ПавловныLelouchСон Веры Павловны,

не проще вместо "AES + ключ в ресурсах" воспользоваться http://msdn.microsoft.com/ru-ru/library/system.security.cryptography.protecteddata(v=vs.110).aspx ?
Не то что бы не проще - в случае такой ситуации, как у ТС, невозможно вообще, т.к. ProtectedData в своих операциях привязывается к аккаунту пользователя, который может быть любым.

http://msdn.microsoft.com/ru-ru/library/system.security.cryptography.dataprotectionscope(v=vs.110).aspx

Там как бы есть LocalMachine

Winnipuh,

Почему бы, кстати, вместо хранения ключа в клиенте не рассмотреть вариант его генерации и обмена ключами?

Сон Веры Павловны,

Поделитесь пожалуйста шаром, а то я пока про приложение ТСа знаю только вот это:

авторЯ отдаю ему приложение-сервис, которое доолжно уметь расшифровывать данные, которые я присылаю из другого приложения-клиента, которое я ему тоже отдаю.

Что мешает применить Д-Х + AES ? тогда ключ вообще будет строго сеансовым.
Если так уперся RSA, то что мешает применить Д-Х, зашифровать AESом приватный ключ и передать его на сервер?

авторСпасибо, я в курсе

Ну а еще у методов Protect и Unprotect есть параметр optionalEntropy. Или про него вы тоже в курсе?

Сон Веры Павловны,

автор wcf c соответствующим data encryption - например, по сертификату.
Кстати, абсолютно согласен.

Тогда еще 1 вариант ТСу (на правах бреда):

авторВ какой момент и как записать в IsolatedStorage мой ключ, который я потом я буду читать в приложении?
Нужно, чтобы сам инсталлятор умел записать этот ключ туда? И будет ли он доступен из приложения?

Если инсталятор позволяет выполнять действия после установки, то можно написать простенькое консольное приложение (а лучше не простенькое, а с обфускацией), которое зашифрует ключ в момент установки с помощью ProtectedData с optionalEntropy и будет сразу удалено.
Плюсом по-отношению к ключу AES в ресурсах будет то, что нельзя будет просто скопировать все файлы приложения на другой компьютер для разбора там, ковыряться придется только на месте.
Минусом - можно будет скопировать Setup )

Но я бы остановился на генерации ключей (если у вас не WCF а что-то самописное)

LelouchСон Веры Павловны,

Поделитесь пожалуйста шаром, а то я пока про приложение ТСа знаю только вот это:

авторЯ отдаю ему приложение-сервис, которое доолжно уметь расшифровывать данные, которые я присылаю из другого приложения-клиента, которое я ему тоже отдаю.

Что мешает применить Д-Х + AES ? тогда ключ вообще будет строго сеансовым.
Если так уперся RSA, то что мешает применить Д-Х, зашифровать AESом приватный ключ и передать его на сервер?

авторСпасибо, я в курсе

Ну а еще у методов Protect и Unprotect есть параметр optionalEntropy. Или про него вы тоже в курсе?


Про Д-Х лучше забыть, проще просто генерировать на сеанс ключи RSA и публичную часть отдавать клиенту...