У меня следующая задача: я должен при генерировании лицензионного номера для клиента "вшивать" в этот самый номер его данные, например, имя, фамилию, название фирмы. Так, чтобы при печатании документов у последнего все эти данные извлекались обратно, из лицензии, и чтобы невозможно было их править на ходу. Соответственно, для каждого клиента генерится свой уникальный ключ и т.п. Если кто знает, где можно накопать исходники, желательно на С++, буду премного благодарен. Уж очень не хочется велосипед изобретать.

Критичен ли для вас размер ключа?
Если нет, то самый лёгкий способ (и самый ... короче в подделке ключа нет проблем) просто закодировать данные по любому алгоритму, хоть XOR+ROR...
Если ключик желательно меньшего размера, то можно просто создать мутную хэшь функцию и при каждой печати сверять хэшь от данных которые вы храните в реестре || *.ini || где там ещё, с хэшем созданом при регистрации... (лучше конечно сравнивать хэшь от хэшь, или ещё что либо подобное... только не на прямую...)

Здравствуйте, RU_Ban0K, Вы писали:

RU_>Критичен ли для вас размер ключа?
RU_>Если нет, то самый лёгкий способ (и самый ... короче в подделке ключа нет проблем) просто закодировать данные по любому алгоритму, хоть XOR+ROR...
RU_>Если ключик желательно меньшего размера, то можно просто создать мутную хэшь функцию и при каждой печати сверять хэшь от данных которые вы храните в реестре || *.ini || где там ещё, с хэшем созданом при регистрации... (лучше конечно сравнивать хэшь от хэшь, или ещё что либо подобное... только не на прямую...)

Размер ключа не критичен. Я вообще подумываю о том, чтобы не утомлять юзера нудным перепечатыванием, а предложить ему поместить файл с ключом в нужное окошко (drag-drop), и на этом "тяжелая" миссия юзера заканчивается.

Здравствуйте, Kiper, Вы писали:

K>У меня следующая задача: я должен при генерировании лицензионного номера для клиента "вшивать" в этот самый номер его данные, например, имя, фамилию, название фирмы. Так, чтобы при печатании документов у последнего все эти данные извлекались обратно, из лицензии, и чтобы невозможно было их править на ходу. Соответственно, для каждого клиента генерится свой уникальный ключ и т.п. Если кто знает, где можно накопать исходники, желательно на С++, буду премного благодарен. Уж очень не хочется велосипед изобретать.

Сам механизм формирования ключей можно сделать на основе асимметричного шифрования, например, того же RSA.
То есть, сначала генерируется пара ключей: публичный и приватный. Публичный "вшивается" в программу и используется при проверке регистрационной информации. Приватный хранится только на Вашей машине и используется в кейгене.

Схема такая:
— покупатель присылает свои регистрационные данные (имя, e-mail, еще что-то);
— кейген создает блок регистрационного кода, шифруя эти данные приватным ключом;
— этот код пересылается пользователю, он вводит его в окно регистрации;
— программа пытается раскодировать эти данные публичным ключом.

С точки зрения криптографии, схема почти идеальная. Но в реальной жизни у нее куча недостатков.

Минусы я вижу такие:
1. Длинные регистрационные коды. Придется заставлять юзера делать Copy/Paste.
2. Большинство алгоритмов, реализующих RSA, применяют обратный способ (public encryption -> pivate decryption), поэтому нужную реализацию придется поискать. Например, в библиотеке Crypto++ ее нет.
3. Крякер может отломить только проверку регистрации, оставив в покое сам ключ.
4. Ну и возможен более хитрый взлом. Крякер сгенерирует свою пару ключей и встроит в программу свой публичный ключ. При этом заработает его собственный кейген.

Поэтому такая защита будет работать только в комплексе с проверкой целостности программы.

Здравствуйте, Kiper, Вы писали:

K>У меня следующая задача: я должен при генерировании лицензионного номера для клиента "вшивать" в этот самый номер его данные, например, имя, фамилию, название фирмы. Так, чтобы при печатании документов у последнего все эти данные извлекались обратно, из лицензии, и чтобы невозможно было их править на ходу. Соответственно, для каждого клиента генерится свой уникальный ключ и т.п. Если кто знает, где можно накопать исходники, желательно на С++, буду премного благодарен. Уж очень не хочется велосипед изобретать.

можно использовать SDK сторонних разработчиков. Например Hardkey License Manager, тут и волки сыты (инфа о юзере забита в ключ) и овцы целы (длина ключа ~25 символов).

Здравствуйте, retalik, Вы писали:

R>2. Большинство алгоритмов, реализующих RSA, применяют обратный способ (public encryption -> pivate decryption), поэтому нужную реализацию придется поискать. Например, в библиотеке Crypto++ ее нет.

Я ковярялся с алгоритмами, поставляемыми с Windows. Поэтому есть вопрос:
Просвятите, а какая разница каким ключем кодировать, а каким декодировать?
Все равно ведь даже в этом случае обладая только одним ключем (пусть даже private)
как я понимаю неврозможно закодировать данные правильно.
Т.е. необходимо что бы работало private encryption -> pivate decryption. Или я что-то не понял?

Здравствуйте, Doc, Вы писали:

Doc>Просвятите, а какая разница каким ключем кодировать, а каким декодировать?
Doc>Все равно ведь даже в этом случае обладая только одним ключем (пусть даже private)
Doc>как я понимаю неврозможно закодировать данные правильно.
Doc>Т.е. необходимо что бы работало private encryption -> pivate decryption. Или я что-то не понял?
Видимо, что-то не понял
Асимметричное шифрование использует пару ключей. Причем преобразование одностороннее. Закодировав сообщение одним ключом, невозможно его декодировать при помощи этого же ключа.

Здравствуйте, retalik, Вы писали:

R>Видимо, что-то не понял
R>Асимметричное шифрование использует пару ключей. Причем преобразование одностороннее. Закодировав сообщение одним ключом, невозможно его декодировать при помощи этого же ключа.

Так и я о том же. Вопрос — остает прежним. Вы писали:

R>2. Большинство алгоритмов, реализующих RSA, применяют обратный способ (public encryption -> pivate decryption), поэтому нужную реализацию придется поискать. Например, в библиотеке Crypto++ ее нет.

Я спрашиваю — какая разница каким шифровать? Т.е. если прогграммист шифрует при помоши public свой key, а в программе есть ТОЛЬКО private для расшифровки, то в чем могут быть вилы?

PS: В этом случае лушче использовать подпись, если в самой инфо нет ничего секретного

Здравствуйте, Doc, Вы писали:

Doc>Я спрашиваю — какая разница каким шифровать? Т.е. если прогграммист шифрует при помоши public свой key, а в программе есть ТОЛЬКО private для расшифровки, то в чем могут быть вилы?
Пока ответить толком не могу. Но спросил знающего человека. Ответит — обязательно процитирую здесь.

Doc>PS: В этом случае лушче использовать подпись, если в самой инфо нет ничего секретного
В том и прелесть шифрования, что в инфе можно спрятать: имя юзера, его e-mail, тип лицензии и даже время действия ключа.

Здравствуйте, retalik, Вы писали:

R>Здравствуйте, Doc, Вы писали:

Doc>>Я спрашиваю — какая разница каким шифровать? Т.е. если прогграммист шифрует при помоши public свой key, а в программе есть ТОЛЬКО private для расшифровки, то в чем могут быть вилы?
R>Пока ответить толком не могу. Но спросил знающего человека. Ответит — обязательно процитирую здесь.

Будет интересно. Пока скажу что я думаю:

* теоретически: просто придется поменять названия ключей. Тот что отдали теперь назовем public, тот что оставили private.

* практически: возникнут проблемы, т.к. подразумевается что каждый ключ используется по цели, а не наоборот

Doc>>PS: В этом случае лушче использовать подпись, если в самой инфо нет ничего секретного
R>В том и прелесть шифрования, что в инфе можно спрятать: имя юзера, его e-mail, тип лицензии и даже время действия ключа.

Хм... юзер и так знает (и вероятно может вводит) свое имя, email итд
тип лицензии, время действия и так предназначено для показа.
Вывод: разбиваем все на 2 части.
* из личных данных получаем хэш и подписывает. (потом запрашиваем юзера и сравниваем хеши и действительность подписи)
* остальное шифруем любым простым алгоритмом и подписываем. По прибытию просто проверяем подпись.

Здравствуйте, retalik, Вы писали:

R>Пока ответить толком не могу. Но спросил знающего человека. Ответит — обязательно процитирую здесь.
Ответ специалиста по криптографии:

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

Но на практике ключ RSA состоит из двух частей: большого числа,
называемого модулем (и этот модуль один и тот же для Public и Private
в одной паре) и числа, называемого экспонентой. В одной паре у Public
и Private экспоненты связаны математически, и могут быть получены одна
из другой, но только если известно разложение модуля на простые
сомножители (а это — сложная математическая задача, составляющая ядро
RSA).

Так вот, чем меньше значение экспоненты. тем быстрее производятся
вычисления. Поэтому чаще всего в качестве Public exponent выбирают
небольшое простое число — 3, 5, 7, 0x10001, и по ним вычисляют Private
exponent (которая, в общем случае, будет по длине соизмерима с
модулем, то есть, например, 1024 бита для RSA-1024).

Но при таком подходе, если в открытый доступ (в код программы)
помещается "длинная" экспонента, а "короткая" экспонента держится в
секрете, то эту короткую экспоненту можно найти перебором. А если
экспоненту не выбирать короткой (то есть обе экспоненты соизмеримы с
модулем), то все прелести короткой экспоненты теряются.

Здравствуйте, retalik, Вы писали:

R>2. Большинство алгоритмов, реализующих RSA, применяют обратный способ (public encryption -> pivate decryption), поэтому нужную реализацию придется поискать. Например, в библиотеке Crypto++ ее нет.
А подскажите где взять RSA, чтобы криптовал приватным ключом. А то я сам с Crypto++ подвязался, но обнаружил что он так не может.

Здравствуйте, Doc, Вы писали:

Doc>Я спрашиваю — какая разница каким шифровать? Т.е. если прогграммист шифрует при помоши public свой key, а в программе есть ТОЛЬКО private для расшифровки, то в чем могут быть вилы?

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

Здравствуйте, CEMb, Вы писали:

C>Тут вроде никакой. Но вообще разница такая: ...
Ага, никакой. Только один небольшой ньюанс. Имея private ключ, можно получить public, а значит и можно генерировать свои левые рег. ключи и программа будет кушать.
А надо чтобы было наоборот, т.к. из public ключа нельзя получить private, вот поэтому я и ищу такую реализацию RSA.

Здравствуйте, Аноним, Вы писали:

C>>Тут вроде никакой. Но вообще разница такая: ...
А>Ага, никакой. Только один небольшой ньюанс. Имея private ключ, можно получить public, а значит и можно генерировать свои левые рег. ключи и программа будет кушать.
А>А надо чтобы было наоборот, т.к. из public ключа нельзя получить private, вот поэтому я и ищу такую реализацию RSA.

Вообще IMHO из одного ключа другой не получишь.А вот то, что библиотеки как правило сохраняют или public или пару private/public это уже проблема реализаций.

Кстати, как я говорил если данные не секретные, то можно использовать механизм подписей. Тогда public гуляет с программой, а пара private/publiс лежит у разработчика для подписи отправленных им данных.

Здравствуйте, Doc, Вы писали:

D>Вообще IMHO из одного ключа другой не получишь.
Are you sure?
Разве из private нельзя получить public?

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

Здравствуйте, Аноним, Вы писали:

А>Разве из private нельзя получить public?
Спорить не буду. Это к теоретикам.
Я как правило наталкивался на экспорт пары ключей. Поэтому если вы экспортируете private, то экспортируете в эту же запись и public. А значит "получать" его в этом случае не надо, т.к. он уже есть. Выделить чистый privatу не пробовал.


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

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

Здравствуйте, Аноним, Вы писали:

А>А подскажите где взять RSA, чтобы криптовал приватным ключом.
Лююююююююди, вы где?
Елки, неужели все навесные защиты пользуют ?
Или все в отпусках, retalik куда-то делся, я чуствую он должен знать

Здраствуйте,

А>>А подскажите где взять RSA, чтобы криптовал приватным ключом.

Ответ специалиста по криптографии:

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

Из одного ключа второй не получить. Возьми любую библиотеку и вперед, с песней.

Здравствуйте, PVA, Вы писали:

PVA>Из одного ключа второй не получить. Возьми любую библиотеку и вперед, с песней.
Любую которая даст возможность экспортировать private ключ (а не пару private/public).
Проверить просто (если мануал читать лень) — экспортируем private и из результата импортируем public. Если удалось — значит была пара.