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

Question

Я смотрю на это весь день. Я, вероятно, должен был уйти от этого несколько часов назад; Я мог бы упустить что-то очевидное в этой точке.

Краткая версия: есть ли способ создать и свести асимметрично зашифрованный хэш к разумному количеству однозначных, читаемых человеком символов?

Длинная версия:

Я хочу создать лицензионные ключи для моего программного обеспечения. Мне бы хотелось, чтобы эти ключи были разумной длины (25–36 символов) и легко читались и вводились человеком (поэтому избегайте неоднозначных символов, таких как число 0 и заглавная буква O).

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

У меня есть общий подход: объединить мою информацию (имя пользователя, версию продукта, соль) в строку и сгенерировать из нее хеш SHA1 (), а затем зашифровать хеш своим личным ключом. На клиенте создайте хеш SHA1 () из той же информации, затем расшифруйте лицензию с помощью открытого ключа и посмотрите, есть ли совпадение.

Поскольку это приложение для Mac, я посмотрел на AquaticPrime, но он генерирует относительно большой файл лицензии, а не строку. Я могу работать с этим, если нужно, но как пользователь мне очень нравится удобство лицензионного ключа, который я могу читать и распечатывать.

Я также посмотрел на CocoaFob, который генерирует ключ, но это так долго, что я все равно хотел бы доставить его в виде файла.

Я некоторое время дурачился с OpenSSL , но не мог придумать ничего разумного.

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

Я открыт для покупки решения. Но я работаю на разных платформах, поэтому хочу что-то портативное. Все, на что я смотрел, зависит от платформы.

Большое, большое спасибо за решение!

PS - Да, я знаю, что он все еще будет взломан. Я пытаюсь придумать что-то разумное, что, как пользователь, я все равно нахожу дружелюбным.

Answer 1

К сожалению, нет. Если вы сделаете его короче, вы потеряете информацию и не сможете восстановить исходный хеш.

Однако вот несколько вещей, которые вы можете попробовать:

• Используйте base32. Сопоставьте его со всеми доступными буквами в алфавите, которые не являются двусмысленными. (0vsO и т. Д.)
• Используйте DSA, он более компактен, чем RSA.
• Сокращение вашего ввода (например, усечение хэша sha1 или использование вместо него md5) может также сделать вывод короче.

Answer 2

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

Вот способ сделать это с помощью общих openssl и bash:

openssl ecparam -genkey -name sect113r1 -out private.key # generate the private key (store it on your server)
openssl ec hist-in private.key -pubout -out public.key # generate a public key (store it in the client software)
# generate a random one time activation userID or a hardware-based one here (CLIENT SIDE)
user_id="unique_on_the_fly_generated_user_ID" # send the user ID to the server for license generation
signature=""
return_value=0
while [[ $return_value == 0 ]]
do
    signature=$(echo "$user_id" | openssl dgst -sign private.key | base64 > signature.txt) # generate a user licence
    echo "$signature" | egrep -q 'O|l|/|\+|=' # check for ambiguous chars
    return_value=$?
done
echo "$signature" | base64 -d > signature.txt # send the signature/license to the client
openssl dgst -verify public.key -signature signature.txt # verify signature (CLIENT SIDE)

Обратите внимание, что вы по-прежнему получаете подпись / лицензионный ключ длиной 48 символов (плюс общий символ заголовка "M", который вы можете избежать при отправке). Насколько я знаю, вы не можете генерировать более короткие подписи с openssl на данный момент.

Answer 3

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

Также неплохо показать небольшое предупреждение на интерфейсе, указывающее, что информация была успешно удалена из буфера обмена (или нет!), Чтобы пользователь знал, что произошло или не произошло.

Answer 4

Обрабатывайте каждый символ SHA1 как шестнадцатеричный, возможно, отбрасывайте ненужное форматирование (тире или скобки), используйте отображение массива для преобразования 0-9A-F в произвольный порядок, скажем, AP, используйте его как введенный вами «человеческий» текст , MD5 даст вам 32 символа или еще несколько для SHA1. Распакуйте символы обратно в строку / байты SHA1 / MD5 и продолжайте оттуда.

Answer 5

Я бы рассмотрел алгоритм MD5. Он широко реализован и генерирует 32-символьную буквенно-цифровую строку независимо от размера ввода. Примените алгоритм к вашему хешу SHA1, и это может быть то, что вы ищете.