Генерация коротких лицензионных ключей с OpenSSL

Question

Я работаю над новой схемой лицензирования для моего программного обеспечения, основанной на шифровании открытого / закрытого ключа OpenSSL. Мой прежний подход , основанный на этой статье , заключался в использовании большого размера закрытого ключа и шифровании хешированной строки SHA1, которую я отправил клиенту в виде файла лицензии (хэш, закодированный в base64, составляет около длина). Я знаю, что кто-то может все еще легко взломать мое приложение, но это помешало кому-то создать генератор ключей, который, я думаю, повредил бы больше в долгосрочной перспективе.

По разным причинам я хочу отойти от файлов лицензий и просто отправить 16-символьную строку base32, которую клиент может ввести в приложение. Даже используя небольшие закрытые ключи (которые, как я понимаю, тривиально взломать), сложно получить такой зашифрованный хеш. Будет ли какая-то польза от использования той же стратегии для генерации зашифрованного хэша, а просто от использования первых 16 символов в качестве лицензионного ключа? Если нет, то есть ли лучшая альтернатива, которая создаст ключи в нужном мне формате?

Answer 1

Подписи DSA значительно короче, чем подписи RSA. Подписи DSA в два раза больше параметра Q; если вы используете значения по умолчанию OpenSSL, Q равно 160 битам, поэтому ваши подписи умещаются в 320 бит.

Если вы можете переключиться на представление base-64 (для которого требуются только прописные и строчные буквы, цифры и два других символа), вам потребуется 53 символа, что можно сделать с 11 группами по 5. Не целых 16, которые вы хотели, но все еще в рамках возможности ввода пользователем.

---

На самом деле, мне приходит в голову, что вы могли бы вдвое сократить количество бит, необходимое в лицензионном ключе. Подписи DSA состоят из двух чисел R и S, каждый размером Q. Однако все значения R могут быть предварительно вычислены подписывающим лицом (вами) - единственное требование - вы никогда не будете использовать их повторно. Таким образом, это означает, что вы можете предварительно рассчитать целую таблицу значений R, скажем, 1 миллион из них (занимая 20 МБ), и распределить их как часть приложения. Теперь, когда вы создаете лицензионный ключ, вы выбираете следующее неиспользуемое значение R и генерируете значение S. Сам лицензионный ключ содержит только индекс значения R (требуется только 20 бит) и полное значение S (160 бит).

И если вы близки к продаже миллиона копий приложения - это хорошая проблема - просто создайте новую версию с новой таблицей R.

Answer 2

Рассматривали ли вы использование какой-либо существующей схемы защиты + генерации ключей? Я знаю, что EXECryptor (я не рекламирую его вообще, это лишь некоторая информация, которую я помню) предлагает сильную защиту, которая вместе с дополнительным продуктом тех же самых парней, StrongKey (если память не изменяет) предлагает короткие клавиши и защиту от взлома. Armadillo - другое название продукта, которое приходит мне в голову, хотя я не знаю, какой уровень защиты они предлагают сейчас. Но у них также были короткие ключи ранее.

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

Конечно, если вам не нужны сильные ключи, вы можете просто использовать хэш «секретного слова» (соль) + имя пользователя и проверить их в приложении, но это можно взломать за считанные минуты.

Answer 3

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

Предложение Юджина об использовании ECC является хорошим - ключи ECC намного короче, чем RSA или DSA для данного уровня безопасности.

Однако 16 символов в базе 32 по-прежнему составляют всего 5 * 16 = 80 битов, что достаточно мало для того, чтобы использовать грубые методы для допустимых ключей, независимо от того, какой алгоритм вы используете.