.NET crypto API предоставляет библиотеку шифрования общего назначения , содержащую объектно-ориентированные подходы для реализации криптографических алгоритмов . Конечно, чтобы использовать эти алгоритмы и реализации алгоритмов, вам нужно хорошо разбираться в криптографии, которой у вас сейчас нет.
Эта библиотека общего назначения требуется для реализации различных протоколов , которые существуют там. Обычно один алгоритм не удовлетворяет конкретному варианту использования (в вашем случае шифруйте строку с помощью пароля, возвращая другую строку). Таким образом, протокол должен быть выбран или разработан, который соответствует этому варианту использования. Этот протокол может, например, определите формат контейнера, такой как CMS или PGP, который может, например, использоваться для шифрования электронной почты (вариант использования).
Вы напрямую пытаетесь применить криптографические алгоритмы для решения вашего варианта использования. Это не сработает. Вам нужен готовый протокол , предпочтительно с предварительно созданным API.
Обратите внимание, что существует много разных вариантов использования, много разных протоколов и даже больше мнений о том, как правильно их создавать и реализовывать. Например, Libsodium / NaCl определяет небольшой контейнерный формат, называемый SecretBox, который берет на себя часть вашей работы.
Однако, конечно, было бы довольно невозможно реализовать TLS поверх NaCl, так как функциональности / алгоритмов просто нет. Опять же, .NET нужна общая криптографическая библиотека, такая как .NET API, чтобы другие могли реализовать свои протоколы.
Так что либо вам придется пропустить маркер и попытаться создать свой собственный протокол, либо вы берете существующий и делаете обоснованное предположение, если он безопасен (надеюсь, протокол был просмотрен / обновлен несколько раз). Держитесь подальше от проектов с одним человеком без дополнительных участников (например, многие примеры кодов там без обзора).
Для вашего собственного протокола, да, есть ошибки, такие как не хранение соли с зашифрованным текстом. Вам нужна случайная (или, по крайней мере, уникальная) соль для обеспечения безопасности, повторное использование пароля для этого, безусловно, не безопасно. Не позволяйте, чтобы он сам стал проектом для одного человека, и заимствуйте протокол или пересмотрите его.
Хорошо, тогда быстро:
- Для получения ключа из пароля интерфейсу требуется соль. Могу ли я использовать пароль как соль? Могу ли я повторно использовать IV в качестве соли? Возможно нет, но я не хочу добавлять другой параметр.
Нет, соль должна быть уникальной и предпочтительно случайной; комбинация пароль / соль должна быть уникальной (она не должна повторяться, даже во времени или в разных доменах).
- Могу ли я использовать фиксированный IV? Один и тот же текст и пароль должны приводить к другому тексту шифра, поэтому я должен предоставить IV для расшифровки в полезной нагрузке.
Нет, если ключ не меняет значение каждый раз (см. Выше). Для CBC IV должен быть непредсказуемым , если вы не используете новый ключ каждый раз.
- Могу ли я использовать соль для ключа и сохранить вместо этого значение IV? Чувствует себя не так.
Это возможно, если только вы не будете повторять соль.
- Создание одноразового номера и получение IV и ключевой соли из него - правильный подход?
Это зависит от очень конкретных деталей. Другими словами, я бы не стал пробовать это, если вы точно не знаете, что делаете.
- Если .Net будет поддерживать режим GCM, у меня все еще будут проблемы?
Безусловно, и в некотором смысле ваши проблемы были бы хуже, если бы вы использовали GCM, поскольку использование GCM с тем же ключом и IV полностью сломано.
Помните, что GCM - это всего лишь алгоритм, а не протокол, он не может самостоятельно решить ваш сценарий использования.