Требуется метод генерации-проверки коротких ключей, типа ХХХХ-ХХХХ-ХХХХ-ХХХХ ну или что-то не сильно длинное
Тока нинада мне рассказывать как крут 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>И еще считается, что есть такие пользователи, которые воспользуются кейгеном, но не станут пользоваться кряком (хотя лично мне в это и не очень верится).
По "фидбека" к своему софту на руборде могу сказать, что это действительно так. Зачастую крякнутый софт работает менее стабильно, также можно подцепить трояна вместе с кряком. С ключом, как вы понимаете, таких проблем нет.
Здравствуйте, Matrix_Failure, Вы писали:
M_F>Юрий, а какие ключи Вам удается проверять? Все которые генерит armadill-овский кейген или есть какие-то нюансы?
Не все, только те которые ShortV3 10-го уровня, остальные мне просто не нужны.
Здравствуйте, Matrix_Failure, Вы писали:
M_F>А много пришлось руками писать или всё что требуется это Copy&Paste из примера к книге? M_F>Код без проблем скомпилировался?
Скомпилировался без проблем, но нужно иметь в виду, что там 100% сишный стиль. Так же в книге с message-а снимают sha1 хеш, а армадила использует md5.
Ну и пришлось повозится с форматом ключа, а так же с параметрами элиптической кривой. Там т.н. base point берется не случайным числом, а зависит от encryption template.
Поддерживаю.
Использую данную технологию давно и успешно, пока не видел ни одного корректно сделанного взлома своих программ, все отлавливались дополнительной логикой с задержкой в несколько дней.
Ключегенерилку достаточно проблематично сделать, так как основная большая матрица в программе не хранится, а используются только определенные ее узлы.
С выходом новой версии, то банально выбираем другой узел в новой версии программы для проверки ключа. Проверок делаем несколько в разных местах программы.
При взломе ключегенерилка будет работать только для взломанной версии и далеко не факт, что полностью если сделать дополнительные проверки и сразу об этом не информировать, а менять логику работы программы в непредсказуемые моменты со сдвигом по времени.
Ключи же пользователей остаются валидными от версии к версии.
Здравствуйте, YuriKobets, Вы писали:
YK>Скомпилировался без проблем, но нужно иметь в виду, что там 100% сишный стиль. Так же в книге с message-а снимают sha1 хеш, а армадила использует md5. YK>Ну и пришлось повозится с форматом ключа, а так же с параметрами элиптической кривой. Там т.н. base point берется не случайным числом, а зависит от encryption template.
Юрий, ты крут!
Если не жалко, пришлешь мне исохдник проверки ключей?
Мой адрес электронной почты:
Здравствуйте, Аноним, Вы писали:
А>Извините, что баяню, поиском ничего не нашёл
А>Требуется метод генерации-проверки коротких ключей, типа ХХХХ-ХХХХ-ХХХХ-ХХХХ ну или что-то не сильно длинное
Такой короткий ключ выдает система регистрации EXECryptor, который увы уже не поддерживается.
Однако можно ухитриться и первичную регистрацию сделать на EXECryptor'е с его короткими ключами, затем сделать активацию софта каким-нибудь другим протектором. Таким образом надо будет использовать два протектора, чтобы покрыть программу. Причем EXECryptor надо применять в самом облегченном виде.
Я так и сделал, в результате покупатель вводит 16-значный короткий ключ и регистрируется. Потом программа через Интернет автоматически активируется, ничего не требуя от покупателя. Никаких жалоб нет ни у них, ни у меня !
Здравствуйте, muExclusion, Вы писали:
E>Такой короткий ключ выдает система регистрации EXECryptor, который увы уже не поддерживается. E>Однако можно ухитриться и первичную регистрацию сделать на EXECryptor'е с его короткими ключами, затем сделать активацию софта каким-нибудь другим протектором. Таким образом надо будет использовать два протектора, чтобы покрыть программу. Причем EXECryptor надо применять в самом облегченном виде.
скажите пожалуйста что значит — Причем EXECryptor надо применять в самом облегченном виде.
вы пробовали запускать программы защишенные EXECryptor на win2008/2012/Win8?
у меня программа защишенная EXECryptor вещаеться под win 2008 R2
Здравствуйте, sergey2b, Вы писали:
S>скажите пожалуйста что значит — Причем EXECryptor надо применять в самом облегченном виде.
Отключите все опции защиты, оставив только компрессию.
И естественно, Use builtin serials. S>вы пробовали запускать программы защишенные EXECryptor на win2008/2012/Win8?
Эта программа запустилась под 8-кой.
Большое спасибо за ваш ответ
могли бы вы пожалуйста дать ссылку (мой email в профале) на вашу программу илил запаковать
hello world я бы попробовал запустить под x64 серверами
Здравствуйте, Matrix_Failure, Вы писали:
M_F>Если не жалко, пришлешь мне исохдник проверки ключей?
Пожалуйста пользуйтесь. Учтите, там только проверка ключа на валидность. Никакая информация из ключа не извлекается. Так что если вы используете Key String или Extra Info, то нужно допиливать, верней выпиливать эту информацию из ключа.
V>Я так понимаю, что будет продолжение статьи про выбор протектора? Ждемс!
Ну так давайте действуйте!
Юрий практически все сделал чтобы Вам помочь.
Небольшое усилие с вашей стороны и в вашем протекторе наконец появится поддержка коротких ключей. Да еще и совместимых с shortv3 L10 ключами Броненосца.
Это будет uber фича и последняя точка в споре про короткие ключи.
Здравствуйте, Matrix_Failure, Вы писали:
V>>Я так понимаю, что будет продолжение статьи про выбор протектора? Ждемс!
M_F>Ну так давайте действуйте! M_F>Юрий практически все сделал чтобы Вам помочь. M_F>Небольшое усилие с вашей стороны и в вашем протекторе наконец появится поддержка коротких ключей. Да еще и совместимых с shortv3 L10 ключами Броненосца. M_F>Это будет uber фича и последняя точка в споре про короткие ключи.
Спора о коротких ключах какбе и не было. Просто кто-то любит мягкое, а кто-то теплое. Я то как раз намекаю на то, что вы так тщательно выбирали протектор, а в результате, потратив довольно приличную сумму, нашли опенсурс, который насколько я понимаю заменит тот самый мучительно выбранный протектор. И очень хочется увидеть в вашем блоге итог всей этой эпопеи
S>>скажите пожалуйста что значит — Причем EXECryptor надо применять в самом облегченном виде. E>Отключите все опции защиты, оставив только компрессию. E>И естественно, Use builtin serials. S>>вы пробовали запускать программы защишенные EXECryptor на win2008/2012/Win8? E>Эта программа запустилась под 8-кой.
Спасибо muExclusion EXECryptor с минимальными настройками зашиты был протестирован под
win 2003/2008 R2/2012 x64 работает нормально, тестовое приложение не виснет
ну и правда, куча сплошного капслока выглядит как битый кусок письма от регистратора. И бывает ещё так, юзер сначала перепужается, в саппорт напишет, я сажусь разбираться, проверю серийник, напишу юзеру первое письмо с вопросами и описаловом, что такое у нас ключ и как им пользоваться, напишу второй письмо, с вопросом жив ли юзер,... а он уже давно разобрался, что к чему, но ему лень отвечать саппорту... 
Описывать на сайте процесс покупки тоже пустой номер, никто это не читает. Частично спасает то, что поле ввода ключа в программах примерно такого же (большущего) размера, как ключ, и описалово процесса регистрации прям там же, в три строчки 
Ждемс!
