Здравствуйте!
Пользую стандартные NET'ие реализации симметричные алгоритмы для шифрования файлов, с которыми работает программа.
Ключи представляют собой просто массивы байтов, которые заранее известны, и никак к машине/конкретному пользователю не привязаны, т.к. необходимо осуществлять свободный перенос данных файлов между компьютерами.
Возник следующий вопрос: как лучше хранить используемые ключи, чтобы они не стали легкой добычей для потенциального взломщика?

шифровать ключем, который будет знать только софт

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

B>шифровать ключем, который будет знать только софт

Хорошо, а где хранить?

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

CBO>Хорошо, а где хранить?

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

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

Боюсь, в такой постановке задача решения не имеет. Ну а так, в качестве обзорнрй информации, ключи в CryptoApi хранят в контейнерах, доступ к которым производится через соответствующих провайдеров. Для импорта/экспорта есть функции CryptImportKey и CryptExportKey. В NET подобный функционал в ограниченном виде предоставляют xxxCryptoServiceProvider

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

CBO>Здравствуйте!
CBO>Пользую стандартные NET'ие реализации симметричные алгоритмы для шифрования файлов, с которыми работает программа.
CBO>Ключи представляют собой просто массивы байтов, которые заранее известны, и никак к машине/конкретному пользователю не привязаны, т.к. необходимо осуществлять свободный перенос данных файлов между компьютерами.
CBO>Возник следующий вопрос: как лучше хранить используемые ключи, чтобы они не стали легкой добычей для потенциального взломщика?

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

P.S. Есть хороший принцип: "Возложите на пользователя ответственность за его действия".

CBO>Хорошо, а где хранить?

Ну это же зависит от архитектуры вашего приложения. Можете в базе данных, можете где захотите, хоть в памяти УСБ ключа

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

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

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

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

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

CBO>Да, это деталь реализации. Фактически мне нужно шифровать документы, которыми оперирует программа.

Вам очень хорошо посоветовали: "от кого вы прячете?". Судя по вашему ответу, вы прячете информацию неких одних пользователь от других. Лучшее что можно тут зделать — этих "одних" которых "хранят тайну " обязать знать и вводить пароль для доступа к данным.

Если я правильно понял суть вашей задачи: у вас есть данные, которые должны быть видны одним пользователям [вашей программы] и не видны другим. Пароль или, точнее, PassPhrase, — то что доктор прописал.

CBO>То есть ключи я сохраняю в ресурсах сборки и пропускаю через обфускатор, я правильно Вас понял?

Это может прокатить во многих случаях. Но это, при достаточной важности информации [и, =>, при приложенных недоброжелателями усилиях], ломается "на ура". Если вам нужна _защита_, а не отписка, думайте не о том, как проще написать, а как сложнее сломать

Задача прояснилась.

Программа оперирует файлами предсталяющими шифрованные архивы. Для шифрования/расшифрования необходимо указать строку, содержащую пароль архива.

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

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

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

ИМХО, это дополнение ничего не меняет. Боюсь, Вы не с того конца подходите к решению задачи. Понятие "безопаснее" не имеет смысла в отрыве от конкретизации угроз. Против чего "безопаснее"?

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

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