2016-12-20 7 views
1

В последнее время я много узнаю о шифровании, и я думаю об использовании его в некоторых своих сетевых приложениях Java. Моя идея состоит в том, чтобы генератор псевдослучайных чисел был установлен на клиентское приложение и серверное приложение, и они оба передают одно и то же семя в этот алгоритм, чтобы они генерировали одни и те же ключи шифрования. Мой вопрос: если кто-то обратил-запрограммировал скомпилированный код, можно ли им найти алгоритм и/или семя? Если да, есть ли способ защититься от этого? Я развиваюсь с помощью java и некоторые подобные вопросы, которые я видел, не были очень конкретными.Может ли шифрование семян/алгоритм быть обратным путем скомпилированного кода?

+0

Все, что у вас есть как часть исходного кода, может быть раскрыто с определенным объемом знаний и усилий. См. Http://security.stackexchange.com/questions/29866/reverse-engineering-and-java –

+0

Вы действительно должны просто использовать TLS. Здорово узнать о шифровании и о том, как это работает, но TLS является отраслевым стандартом по какой-то причине, это сэкономит вам время и деньги. –

ответ

4

В общем, да. Но вы должны дать больше информации о своей идее и узнать больше о состоянии шифрования.

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

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

2

Итак, вы решили использовать криптографию. Это очень хорошее и ценное первое понимание, которое не может быть честным.

В теории: Да. Если ваш компьютер может его выполнить, он является детерминированным и конечным, и, следовательно, внутренняя работа кода может быть исследована и реконструирована.

На практике: Это занимает довольно много времени и усилий, чтобы разобрать простой Hello World пример. Для более сложного кода обратного проектирования требуется много времени, усилий и знаний. Если ваш «продукт» не имеет никакого отношения к какой-либо значительной или ценной информации, становится маловероятным, что кто-то действительно будет тратить время, пытаясь разобраться в этом.

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

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

  • Хороший криптографический алгоритм не требует, чтобы быть запутанным. Даже если все его внутренние работы хорошо известны и понятны, он обеспечивает надежную защиту. Security through obscurity - распространенное заблуждение как у начинающих, так и у «экспертов». Многие люди/компании попали в эту ловушку, и ущерб обычно был серьезным.

  • Криптография все или ничего. Если у вас есть небольшая ошибка в вашем коде, вся ваша зашифрованная информация де-факто перестает быть секретной. Если у вашего генератора случайных чисел есть ошибка, ваше шифрование - это не что иное, как перенос бумаги вокруг настоящего ... Даже известные библиотеки, такие как OpenSSL, всегда нуждаются в тонне исправления ошибок, обслуживания и обзоров.

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

  • Do Исследование уже существующих реализаций для известных алгоритмов и попытка выяснить, находятся ли они в хорошем состоянии и обновлены. Научитесь понимать их и правильно их использовать. (Распространенная ошибка # 2: программист не может правильно читать и соблюдать документацию библиотеки)

Заключение: ли поиграться с криптографией, чтобы чувствовать себя за это. Однако, используйте хорошо установленные реализации в «реальном» мире, если вы действительно не ненавидите своих пользователей. Работа с криптографическими библиотеками/фреймворками достаточно сложна. Входите в детали, если вы готовы потратить на это значительную часть своей жизни.

О, и обратное проектирование? Прекратите заботиться об этом. Если ваш нападающий захочет это сделать, он это сделает. Но если ваша реализация безопасности хороша, он вообще не получит от обратной инженерии.