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

Подписи 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.

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

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

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

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

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

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