Требуется метод генерации-проверки коротких ключей, типа ХХХХ-ХХХХ-ХХХХ-ХХХХ ну или что-то не сильно длинное
Тока нинада мне рассказывать как крут vmpсофт и длинные ключи! Сейчас срочная цель — быть ближе к юзеру. Как выяснилось, когда приходит портянка в несколько строк, они иногда не воспринимают её в письме как ключ и мучат саппорт. ну и правда, куча сплошного капслока выглядит как битый кусок письма от регистратора. И бывает ещё так, юзер сначала перепужается, в саппорт напишет, я сажусь разбираться, проверю серийник, напишу юзеру первое письмо с вопросами и описаловом, что такое у нас ключ и как им пользоваться, напишу второй письмо, с вопросом жив ли юзер,... а он уже давно разобрался, что к чему, но ему лень отвечать саппорту... Описывать на сайте процесс покупки тоже пустой номер, никто это не читает. Частично спасает то, что поле ввода ключа в программах примерно такого же (большущего) размера, как ключ, и описалово процесса регистрации прям там же, в три строчки
Отвлёкся. Так же не хочется генерить пицоттыщ ключей и забивать потом пицоттыщ хешей в программу. Поэтому, может есть способ нагенерить ключи так, чтоб их можно было только в одну сторону проверить на одной строчке секретного текста? Это был бы самый приемлемый вариант пока, чтоб не зависить от других серверов(у меня есть сервер, но он часто сбоит, а выяснять что-почему или искать другого хостера сейчас нет времени и желания), накидать лист ключей и потом их только пополнять на сервере регистратора по мере надобности. Это я могу сделать с помощью ассимметричного криптования, но строка получается охрененной длины (Crypto++)
Т.е требуется что-то типа, как это делет ассимметричное криптование:
Здравствуйте, Аноним, Вы писали:
А>Извините, что баяню, поиском ничего не нашёл
А>Требуется метод генерации-проверки коротких ключей, типа ХХХХ-ХХХХ-ХХХХ-ХХХХ ну или что-то не сильно длинное А>Тока нинада мне рассказывать как крут vmpсофт и длинные ключи! Сейчас срочная цель — быть ближе к юзеру. Как
Я в свое время искал варианты, но в конечном итоге перешел на кодогенерацию SiliconRealms.
Может и можно было наколхозить свои короткие ключи, но в реальности лучше это время потратить на улучшение своего продукта и его продвижениене.
Здравствуйте, Аноним, Вы писали:
А>Извините, что баяню, поиском ничего не нашёл
по определению, чем короче ключ, тем проще кейген (тупо перебором, хотя бы). можете сделать относительно короткий RSA/ECC в надежде, что хакеров заломает гонять перебор сутками...
Здравствуйте, Аноним, Вы писали:
А>чтоб не зависить от других серверов(у меня есть сервер, но он часто сбоит, а выяснять что-почему или искать другого хостера сейчас нет времени и желания)
ИМХО, это — главная проблема. я когда по инерции российским хостером пользовался — тоже были глюки и тормоза. перешел на HostEurope — пока тьфу-тьфу...
Здравствуй мой дорогой друг. Сейчас я расскажу сказку о том как самому сделать короткие ключи, такие же как у маленького, но гордого, зверка броненосца. Броненосец тот имеет короткие ключи к которым никто не делал генераторов ибо ключи делались на основе цифровой подписи ECDSAразмером аж в 113 бит. Ключегенерилку можно запросто купить у этого гордого, но хитрого, зверька. Но, так как зверек хитрый, то в исходниках ключегенерилки нет кода проверки ключей. Но зверек еще и ленивый и в исходниках ключегенерилки оставил поясняющие комментарии, которые ведут нас на прямую к вот этой книге. Книга умная и ее, конечно можно почитать, но не обязательно. По той ссылке с книгой внизу есть код примеров, из которой броненосец слямзил ~90% кода для своих ключиков.
И так начинаю основной сказ. Качаем код и находим в недрах файл DSA.c — Это практически все, что нам нужно. Там показывается как использовать onb_DSA_Signature для создания сигнатуры и onb_DSA_Verify для проверки сигнатуры. Signer.prvt_key и Signer.pblc_key соответственно приватный и публичный ключи. Так же обратите внимание на Base.pnt — одну и ту же базовую точку нужно использовать при подписи и проверки. Ну а дальше дело только в том, что подписывать. Как делает броненосец: в ключиках у него хранится дата создания ключа, случайное число (чтоб на одно имя разные ключи делались), плюс всякие дополнительные опции как то пользовательские строки и числа. Добавив сюда еще и имя (предварительно подняв буквы и убрав пробелы), получаем "Message" для подписи и проверки. Остается только все байтики собрать вместе и вдарить по ним каким-нибудь base32 для удобочитаемости.
В общем, можно запросто получить такие же ключики как у броненосца, а особо одаренные могут проверять ключики броненосца и без онного (что мне особенно приятно).
Здравствуйте, Аноним, Вы писали:
А>Отвлёкся. Так же не хочется генерить пицоттыщ ключей и забивать потом пицоттыщ хешей в программу.
Ну на самом деле нагенерить стопицоттыщ ключей это самый простой и надежный способ решить проблему с ключегенерилкой. В итоге в любом случае все сводится к функции secret_foo(hash_key) == true. А для среднебольничной шаровары хватит и сотни ключей на первое время.
Здравствуйте, YuriKobets, Вы писали:
YK>Здравствуй мой дорогой друг. Сейчас я расскажу сказку о том как самому сделать короткие ключи, такие же как у маленького, но гордого, зверка броненосца...
Можете пояснить?
DSA — это цифровая подпись, т.е. хеш, зашифрованный приватным ключем. Для проверки цифровой подписи (читаем как "проверки нашего короткого ключика") нужен тот самый "message" и публичный ключ. С message'а снимаем хеш и сравниваем с нашим "коротким ключиком", расшифрованный публичным ключом. Если они совпадают, то цифровая подпись верна — "ключик" валиден. Следовательно в программе должен где-то храниться публичный ключ, а наш "короткий ключик" состоит из "message" + цифровая подпись.
В итоге наши "ключики" все-равно получаются не такими уж и короткими (хотя и гораздо короче RSA). Я прав?
Здравствуйте, altarvic, Вы писали:
A>Можете пояснить?
Конечно!
A>DSA — это цифровая подпись, т.е. хеш, зашифрованный приватным ключем. Для проверки цифровой подписи (читаем как "проверки нашего короткого ключика") нужен тот самый "message" и публичный ключ. С message'а снимаем хеш и сравниваем с нашим "коротким ключиком", расшифрованный публичным ключом. Если они совпадают, то цифровая подпись верна — "ключик" валиден. Следовательно в программе должен где-то храниться публичный ключ, а наш "короткий ключик" состоит из "message" + цифровая подпись.
Вывод верен. Процесс вывода не совсем математически верен. Расшифровки там, как таковой, нет. Но, хотя это неважно для конечного использования, можно почитать теорию, я не слишком силен в этом разделе математики.
A>В итоге наши "ключики" все-равно получаются не такими уж и короткими (хотя и гораздо короче RSA). Я прав?
Факты:
1) message вообще может быть из 1 байта (случайный байт), а то и не быть вообще. Значительная часть message не кодируется в ключ, а является именем (пара имя-ключ).
2) Размер сигнатуры 28 байт. Это и есть минимальный размер ключа в байтах (плюс перекодировка во что-то читаемое), при условии отсутствия в ключе message
Вот такие факты для данного метода. Да может длинновато, если предложите исходники других методов — буду только рад.
Здравствуйте, YuriKobets, Вы писали:
YK>2) Размер сигнатуры 28 байт. Это и есть минимальный размер ключа в байтах (плюс перекодировка во что-то читаемое), при условии отсутствия в ключе message
При переводе в удобочитаемый base64 порлучаем уже 56 байт, ну и немного информации в ключике хранить — уже под 70 символов.
Получается надежно и удобно для программиста, но не так уж коротко для юзера.
Я такие ключи только для дорогого софта использую, для обычного — список хешей.
Советую нагенерить и хранить хеши. Это просто, и займет менще места чем код проверки ключей на ассим алгоритме.
10000 тыс ключей меньше 100 кб!
А ломается с такой же сложностью близкой к 0 если нет навесной защиты.
Здравствуйте, icezone, Вы писали:
YK>>2) Размер сигнатуры 28 байт. Это и есть минимальный размер ключа в байтах (плюс перекодировка во что-то читаемое), при условии отсутствия в ключе message
I>При переводе в удобочитаемый base64 порлучаем уже 56 байт, ну и немного информации в ключике хранить — уже под 70 символов. I>Получается надежно и удобно для программиста, но не так уж коротко для юзера. I>Я такие ключи только для дорогого софта использую, для обычного — список хешей.
Ну у меня схема примерно такая же. В программе сделано окошко с полями ввода имени, мыла, номера лиценции и ключа. Номер лицензии при покупке выдается, по сути — просто индекс в моей базе ордеров. При активации лицензии на сайте пользователю (на мыло, указанное при покупке) отправляется письмо, в котором указаны все эти поля, в аттаче лежит XML файл, в котором все продублировано, и пользователю достаточно драг-н-дропнуть в текстовое поле ввода ключа. Пока никто не жаловался.
Здравствуйте, icezone, Вы писали:
I>Я такие ключи только для дорогого софта использую, для обычного — список хешей.
Ну да, согласен. Список хешей мне видится наиболее приемлемым решением. Я к чему весь этот "разбор полетов" устроил. Сейчас использую армадилу, и хочется слезть с нее. Останавливает только великое множество выданных ключей. Сейчас, когда я научился проверять армадиловские ключи сам, я обрел еще одну степень свободы.
Здравствуйте, YuriKobets, Вы писали:
YK>Ну да, согласен. Список хешей мне видится наиболее приемлемым решением. Я к чему весь этот "разбор полетов" устроил. Сейчас использую армадилу, и хочется слезть с нее. Останавливает только великое множество выданных ключей. Сейчас, когда я научился проверять армадиловские ключи сам, я обрел еще одну степень свободы.
Здравствуйте, sergey2b, Вы писали:
S>если несекрет почему вы хотите уйти с армадилы
Ответ: Windows 8. На восьмерке, на некоторых машинах армадилла круто подвешивает систему если запущена из под админа. Я имел долгую переписку с поддержкой. Вроде как проблему решили, но осадочек остался. Плюс, опять таки по восьмеркой, время загрузки стало вообще каким-то неприличным. Я, конечно, понимаю, что это из за встроенного антивируса. Но т.к. у большинства пользователей 8-ки он включен, то возникает проблема.
Здравствуйте, Аноним, Вы писали:
А>Извините, что баяню, поиском ничего не нашёл
А>Требуется метод генерации-проверки коротких ключей, типа ХХХХ-ХХХХ-ХХХХ-ХХХХ ну или что-то не сильно длинное А>Тока нинада мне рассказывать как крут vmpсофт и длинные ключи! Сейчас срочная цель — быть ближе к юзеру. Как выяснилось, когда приходит портянка в несколько строк, они иногда не воспринимают её в письме как ключ и мучат саппорт. ну и правда, куча сплошного капслока выглядит как битый кусок письма от регистратора. И бывает ещё так, юзер сначала перепужается, в саппорт напишет, я сажусь разбираться, проверю серийник, напишу юзеру первое письмо с вопросами и описаловом, что такое у нас ключ и как им пользоваться, напишу второй письмо, с вопросом жив ли юзер,... а он уже давно разобрался, что к чему, но ему лень отвечать саппорту... Описывать на сайте процесс покупки тоже пустой номер, никто это не читает. Частично спасает то, что поле ввода ключа в программах примерно такого же (большущего) размера, как ключ, и описалово процесса регистрации прям там же, в три строчки
Можно например сделать так. Есть ключ вида: XYYY-XYYY-XYYY-XYYY-XYYY
Где XXXXX — это идентификатор пользователя, а YYYY...YYYY генерятся по какому-нибудь алгоритму на основе соли и идентификатора пользователя.
Люди делятся на 10 категорий: одни понимают, что такое двоичное счисление, другие — нет.
Здравствуйте, YuriKobets, Вы писали:
YK>Ну да, согласен. Список хешей мне видится наиболее приемлемым решением. Я к чему весь этот "разбор полетов" устроил.
А мне такой подход нравится тем, что можно кучу версий с разной ценой наплодить — в ключике список активируемых фич закодирован.
Здравствуйте, archerz, Вы писали:
A>Можно например сделать так. Есть ключ вида: XYYY-XYYY-XYYY-XYYY-XYYY A>Где XXXXX — это идентификатор пользователя, а YYYY...YYYY генерятся по какому-нибудь алгоритму на основе соли и идентификатора пользователя.
Это конечно хорошо, но если хакер какой пройдет своим инструментом по вашему алгоритму то сделает запросто keygen.
Есть популярное среди шароварщиков мнение, что keygen это существенно большее зло чем кряк, в плане снижения продаж,
т.к. выход новой версии программы отсекает от неё пользователей старых кряков, но этого эффекта не происходит в случае появления кейгена.
А замена тысяч или пусть даже сотен выданных легальным пользователям ключей это трудная и неприятная задача.
И еще считается, что есть такие пользователи, которые воспользуются кейгеном, но не станут пользоваться кряком (хотя лично мне в это и не очень верится).
Здравствуйте, YuriKobets, Вы писали:
YK>Ну да, согласен. Список хешей мне видится наиболее приемлемым решением. Я к чему весь этот "разбор полетов" устроил. Сейчас использую армадилу, и хочется слезть с нее. Останавливает только великое множество выданных ключей. Сейчас, когда я научился проверять армадиловские ключи сам, я обрел еще одну степень свободы.
Я полностью поддерживаю идею иметь еще одну степень свободы.
Юрий, а какие ключи Вам удается проверять? Все которые генерит armadill-овский кейген или есть какие-то нюансы?
Здравствуйте, Matrix_Failure, Вы писали: M_F>И еще считается, что есть такие пользователи, которые воспользуются кейгеном, но не станут пользоваться кряком (хотя лично мне в это и не очень верится).
По "фидбека" к своему софту на руборде могу сказать, что это действительно так. Зачастую крякнутый софт работает менее стабильно, также можно подцепить трояна вместе с кряком. С ключом, как вы понимаете, таких проблем нет.
ну и правда, куча сплошного капслока выглядит как битый кусок письма от регистратора. И бывает ещё так, юзер сначала перепужается, в саппорт напишет, я сажусь разбираться, проверю серийник, напишу юзеру первое письмо с вопросами и описаловом, что такое у нас ключ и как им пользоваться, напишу второй письмо, с вопросом жив ли юзер,... а он уже давно разобрался, что к чему, но ему лень отвечать саппорту... 
Описывать на сайте процесс покупки тоже пустой номер, никто это не читает. Частично спасает то, что поле ввода ключа в программах примерно такого же (большущего) размера, как ключ, и описалово процесса регистрации прям там же, в три строчки 
