Ключ для шаровары

Поделитесь, please, как лучше сделать генерацию и проверку на валидность ключей. Нужны ли мудреные криптоалгоритмы, или хватит просчета контрольных сумм, например?
А может просто список ключей создать, и не заморачиваться над генерацией?
Мне тут бывалые посоветовали не привязывать прогу к железу во избежание серьезных проблем с клиентами, вобщем я немного запутался.

ИМХО, алгоритм генерации будут хакать, если твоя прога будет нужна относительно широким массам. А если всего 100 человек ее будут пользовать, то можно не загоняться с алгоритмом...

Сообщение отредактировано: andyag - 03.08.02, 18:14

Так я знаю, что хакнут. Ну и что, кто-то хакнет, кто-то купит, это нормально. Но тем не менее хоть какую то процедуру регистрации сделаь надо! А если по вашему, можно вообще один пароль там вписать, и всем его раздавать. Почему же все так не делают?

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

Так мне Очень не советовали привязывать к конкретной машине. Мол, проблем потом с юзерами не оберешься (хотя каких проблем я не понял). К тому же у такого способа серьёзный недостаток - а если он имя сменит?

Используй стандартный CryptoAPI, ИМХО самый простой и "самый" надежный способ.

А это что? Можно подробней?

Посмотри в MSDN хелп по функциям CryptEncrypt()/CryptDecrypt()/CryptXXX...и т.д, или на первом диске MSDN в samples\... , (очно не помню, поищи). Если хочешь могу примерчик выслать поточного криптования. CryptoAPI подерживает и подписи, и генерации случайных ключей, и хеши твоих ключей и crc и ..., короче дохера всего.

Цитата andyag, 04.08.02, 19:02:19

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

Что касается использования синусов и косинусов, то это полная лажа (извиняйте за грубость). Т.к. функции периодичны и определить алгоритм шифрования не составит особого труда. Максимальная необходимая последовательность крипто-символов будет не более 256³. Что для простого пня составит не более минуты работы

Выдержка из MSDN

CryptEncrypt
This function is used to encrypt data. The algorithm used to encrypt the data is designated by the key held by the cryptographic service provider (CSP) module, which is referenced by the hKey parameter.

BOOL CRYPTFUNC CryptEncrypt(
HCRYPTKEY hKey,
HCRYPTHASH hHash,
BOOL Final,
DWORD dwFlags,
BYTE *pbData,
DWORD *pdwDataLen,
DWORD dwBufLen);
Parameters
hKey
[in] Handle to the key to use for the encryption. An application obtains this handle by using either the CryptGenKey or the CryptImportKey function.
This key specifies the encryption algorithm that is used.

hHash
[in] Handle to a hash object. This parameter is used only if a hash of the data is to be computed at the same time the encryption is being performed. For more information, see Remarks.
If no hash is to be done, this parameter must be zero.

Final
[in] Boolean value that specifies whether this is the last section in a series being encrypted. This should be TRUE if this is the last or only block, and FALSE if it is not. For more information, see Remarks.
dwFlags
[in] Specifies a bitmask of flags. This parameter is reserved for future use and should always be zero.
pbData
[in/out] Pointer to the buffer that holds the data to be encrypted. After the encryption has been performed, the encrypted data is placed back in this same buffer.
The size of this buffer is specified by dwBufLen. The number of bytes of data to be encrypted is specified by pdwDataLen.

This parameter can be NULL if all you are doing is determining the number of bytes required for the returned data.

pdwDataLen
[in/out] Pointer to the data length. Before calling this function, the caller should set this parameter to the number of bytes to be encrypted. Upon return, this address will contain the number of bytes of encrypted data.
If the buffer specified by pbData is not large enough to hold the data, the function returns the ERROR_MORE_DATA error code (through GetLastError) and stores the required buffer size, in bytes, into the variable pointed to by pdwDataLen.

If pbData is NULL, then no error is returned, and the function stores the size of the data, in bytes, in the variable pointed to be pdwDataLen. This lets an application determine the correct buffer size unambiguously.

When a block cipher is used, this data length must be a multiple of the block size, unless this is the final section of data to be encrypted and the Final flag is TRUE.

dwBufLen
[in] Specifies the number of bytes in the pbData buffer.
Note that, depending on the algorithm used, the encrypted text can be slightly larger than the original plaintext. In this case, the pbData buffer needs to be sized accordingly.

As a rule, if a stream cipher is used the ciphertext will be the same size as the plaintext. If a block cipher is used, the ciphertext will be up to a "block length" larger than the plaintext.

Return Values
TRUE indicates success. FALSE indicates failure. To get extended error information, call GetLastError. Common values for GetLastError are described in the following table. The error values prefaced by "NTE" are generated by the particular CSP you are using.


Value Description
ERROR_INVALID_HANDLE One of the parameters specifies an invalid handle.  
ERROR_INVALID_PARAMETER One of the parameters contains an invalid value. This is most often an illegal pointer.
NTE_BAD_ALGID The hKey session key specifies an algorithm that this CSP does not support.
NTE_BAD_DATA The data to be encrypted is invalid. For example, when a block cipher is used and the Final flag is FALSE, the value specified by pdwDataLen must be a multiple of the block size.
NTE_BAD_FLAGS The dwFlags parameter is nonzero.
NTE_BAD_HASH The hHash parameter contains an invalid handle.
NTE_BAD_HASH_STATE An attempt was made to add data to a hash object that is already marked "finished."
NTE_BAD_KEY The hKey parameter does not contain a valid handle to a key.
NTE_BAD_LEN The size of the output buffer is too small to hold the generated ciphertext.
NTE_BAD_UID The CSP context that was specified when the key was created cannot be found.
NTE_DOUBLE_ENCRYPT The application attempted to encrypt the same data twice.
NTE_FAIL The function failed in some unexpected way.
NTE_NO_MEMORY The CSP ran out of memory during the operation.



Remarks
If data is to be hashed and encrypted simultaneously, a handle to a hash object can be passed in the hHash parameter. The hash value will be updated with the plaintext passed in. This option is useful when generating signed and encrypted text.

Before calling CryptEncrypt, the application should obtain a handle to the hash object by calling the CryptCreateHash function. After the encryption is complete, the hash value can be obtained through the CryptGetHashParam function or the hash can be signed using the CryptSignHash function.

When a large amount of data needs to be encrypted, it can be done in sections. This is done by calling CryptEncrypt repeatedly. The Final parameter should be set to TRUE only on the last invocation of CryptEncrypt, so the encryption engine can properly finish the encryption process. The following extra actions are performed when Final is TRUE:

If the key is a block cipher key, the data will be padded to a multiple of the block size of the cipher. To find the block size of a cipher, use CryptGetKeyParam to get the KP_BLOCKLEN parameter of the key.
If the cipher is operating in a chaining mode, the next CryptEncrypt operation will reset the cipher's feedback register to the KP_IV value of the key.
If the cipher is a stream cipher, the next CryptEncrypt will reset the cipher to its initial state.
Requirements

Runs On Versions Defined in Include Link to
Windows CE OS 2.10 and later Wincrypt.h   Cryptapi.lib



Note   This API is part of the complete Windows CE OS package as provided by Microsoft. The functionality of a particular platform is determined by the original equipment manufacturer (OEM) and some devices may not support this API.



CryptDecrypt
This function is used to decrypt data that was previously encrypted with the CryptEncrypt function.

BOOL CRYPTFUNC CryptDecrypt(
HCRYPTKEY hKey,
HCRYPTHASH hHash,
BOOL Final,
DWORD dwFlags,
BYTE *pbData,
DWORD *pdwDataLen);
Parameters
hKey
[in] Handle to the key to use for the decryption. An application obtains this handle by using either the CryptGenKey or CryptImportKey function.
This key specifies the decryption algorithm that is used.

hHash
[in] Handle to a hash object. This parameter is used only if a hash of the data is to be computed. For more information, see Remarks.
If no hash is to be done, this parameter must be zero.

Final
[in] Boolean value that specifies whether this is the last section in a series being decrypted. This will be TRUE if this is the last or only block. If it is not, then it will be FALSE. For more information, see Remarks.
dwFlags
[in] Specifies a bitmask of flags. This parameter is reserved for future use and should always be zero.
pbData
[in/out] Pointer to the buffer that holds the data to be decrypted. After the decryption has been performed, the plaintext is placed back in this same buffer.
The number of encrypted bytes in this buffer is specified by pcbData.

pdwDataLen
[in/out] Pointer to the data length. Before calling this function, the caller should set this parameter to the number of bytes to be decrypted. Upon return, this address will contain the number of bytes of plaintext generated.
When a block cipher is used, this data length must be a multiple of the block size, unless this is the final section of data to be decrypted and the Final flag is TRUE.

Return Values
TRUE indicates success. FALSE indicates failure. To get extended error information, call GetLastError. Common values for GetLastError are described in the following table. The error values prefaced by "NTE" are generated by the particular CSP you are using.


Value Description
ERROR_INVALID_HANDLE One of the parameters specifies an invalid handle.  
ERROR_INVALID_PARAMETER One of the parameters contains an invalid value. This is most often an illegal pointer.
NTE_BAD_ALGID The hKey session key specifies an algorithm that this CSP does not support.
NTE_BAD_DATA The data to be decrypted is invalid. For example, when a block cipher is used and the Final flag is FALSE, the value specified by pdwDataLen must be a multiple of the block size. This error can also be returned when the padding is found to be invalid.
NTE_BAD_FLAGS The dwFlags parameter is nonzero.
NTE_BAD_HASH The hHash parameter contains an invalid handle.
NTE_BAD_KEY The hKey parameter does not contain a valid handle to a key.
NTE_BAD_LEN The size of the output buffer is too small to hold the generated plaintext.
NTE_BAD_UID The CSP context that was specified when the key was created cannot be found.
NTE_DOUBLE_ENCRYPT The application attempted to decrypt the same data twice.
NTE_FAIL The function failed in some unexpected way.



Remarks
If data is to be decrypted and hashed simultaneously, a handle to a hash object can be passed in the hHash parameter. The hash value will be updated with the decrypted plaintext. This option is useful when simultaneously decrypting and verifying a signature.

Before calling CryptDecrypt, the application should obtain a handle to the hash object by calling the CryptCreateHash function. After the decryption is complete, the hash value can be obtained (through CryptGetHashParam), it can be signed (through CryptSignHash), or it can be used to verify a digital signature (through CryptVerifySignature).

When a large amount of data needs to be decrypted, it can be done in sections. This is done by calling CryptDecrypt repeatedly. The Final parameter should be set to TRUE only on the last invocation of CryptDecrypt, so the decryption engine can properly finish the decryption process. The following extra actions are performed when Final is TRUE:

If the key is a block cipher key, the data will be padded to a multiple of the block size of the cipher. To find the block size of a cipher, use CryptGetKeyParam to get the KP_BLOCKLEN parameter of the key.
If the cipher is operating in a chaining mode, the next CryptDecrypt operation will reset the cipher's feedback register to the KP_IV value of the key.
If the cipher is a stream cipher, the next CryptDecrypt call will reset the cipher to its initial state

Цитата bobby, 04.08.02, 19:51:04

Так мне Очень не советовали привязывать к конкретной машине. Мол, проблем потом с юзерами не оберешься (хотя каких проблем я не понял). К тому же у такого способа серьёзный недостаток - а если он имя сменит?

Что касается привязки к конкретной машине, то вдруг чел чаво нить да и сменит у себя. При аппаратной привязке сразу получаем большой баг в работе программы. Отсюда и проблемы с юзерами. Аналогичная ситуация при зацепки и к имени пользователя.
Один из выходов:
1. Взять время установки проги (в полном формате день:месяц:год:час:минута:секунда:доли_секунд)
2. Конвертнуть,  используя любой метод криптографии, получив почти уникальный код.
Количество максимальных вариантов 311008896000. Не считая алгоритма криптографии ;D ;D ;D

Простите за полное невежество, но как использовать методы криптографии? нужно компонент интсталлировать или что-нибудь еще?

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

Нужно совсем простую вещь. Я имел наглость заняться продажей shareware имея опыт программирования год. Но так как вроде получилось написать пару неплохих и очень нужных в хозяйстве программ, то решил попробовать их продать за символическую сумму на западном рынке. Тут встал вопрос о защите. Точнее даже не столько защите (ведь кому надо все равно сломают, а никакой серьезной защиты я естественно не напишу) сколько о стандартной процедуре регистрации программ с помощью ввода ключа, без которой просто никто вообще не заплатит.
Ну вот, в соответствии с моим уровнем передо мной встал вопрос: либо список ключей, либо их генерация по определенному алгоритму, либо привязка к конкретной машине. Как я уже понял из фака шароварщиков последнее неприемлимо. Хочеться осуществить именно генерацию ключей.
Пока я сделал очень просто: генерирую ключ из 12 латинских букв верхнего регистра так, чтобы каждая тройка букв соответствовала определенному условию, и вся сумма цифр удовлетворяла некоей контрольной сумме.
Вот вопрос: не слишком ли простой алгоритм, не может ли он быть вычислен специальной программой (если такие есть).
Конечно сильно защищать программу я не буду, но и делать макет для тренировки начинающих крякеров тоже не хотелось бы.
Вот это далеко не полный перечень проблем, которые неожиданно возникли (често говоря я думал что все намного проще и не подозревал о том, что придется осущестлять поддержку, рассылки, платить за приличный хостинг, вести учет пользователей, осуществлять рекламу, закупать баннеропоказы...) Да чего я рассказываю, сами все знаете.
Ну вот вроде так. Молодой подаван  нуждается в советах опытных джедаев
Извиняюсь за длинный  пост, но, как говорил классик, не имел времени сделать его короче.
Спасибо за поддержку.

Ради интереса посмотри прогу ASProtect почитай, может понравится, а на счёт собственной защиты, если будешь продавать прогу супостатам, то сделай простенькую защиту и напиши большую и страшную лицензию, что типа всем, "моргала выкалю" за использование не зарегистрированой версии, а лучше с какого-нибудь продукта с плагиатить. Буржуи обычно таких штук боятся, но а кто хочет сломать, сломает, а кто не хочет платить, найдет кряк... вот так, такие пироги...

Что касается уникальных ключей и паролей, то могу на все 100\% завявить, что таких НЕ СУЩЕСТВУЕТ.
1. А что бы не засорять голову различными алгоритмами (если объем "продаж" программы мал), то проще всего создать базу из N ключей размером от 16 символов (типа TR5H6-JFURY8-.....) и каждый ключ привязать к конкретному релизу проги(принцип Microsoft). Правда при этом твою порогу взломав один раз можно распространять уже кому угодно.
2. Для единоличного установления проги для одного пользователя придется привязывать ее аппаратно к машине или пользователю (номера BIOS, CPU, HASP). Но и в  этом случае прогу для "полной" защиты придется  устанавливать самому лично (принцип 1С).
3. Временная защита (дата, часы, время работы). Самый простой для взлома метод.

P.S.
Алгоритмы защиты и готовые проги, если надо могу скинуть.

Да, конечно хочу.

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

Цитата stx, 09.08.02, 17:17:18

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

Что касается раскрутки проги, то это вопрос довольно спорный. А вот по поводу хардовых ключей, то это опять таки не способ защиты. Написать простейший эмулятор для ключа, или перекрыть функции обращения к нему в проге не составляет особого труда для "умеющего человека". Так что вопрос об уникальном методе защиты всегда будет оставаться открытым. ;D ;D ;D

не знаю, иожет идея - бред(если это так, пусть Гранд мне первый об этом скажет, я не обижусь:) )
но я бы делал так:
на сайте для ознакомления выкладываешь демо-версию, обладающую неполной функциональностью, или работающую 30 дней.
когда у тебя заказывают прогу, придумываешь новый пароль/ключ, перекомпиливаешь прогу именно для этого ключа, отсылаешь клиенту прогу с ключом.
прога при инсталяции спрашивает ключ, который ты тоже послал клиенту, он его вводит, инсталяция продолжается, прога ставиться:) вот и вся радость. без привязки к машине или имени клиента.
то есть, на каждую высланную копию ты придумываешь ключ и посылаешь вместе с ней:).
если прога работает с инетом, можно позлодействовать, и сделать ей. чтобы она коннектилась к некому серверу, твоему, и проверяла, сколько прог с ее ключом ты сделал (должна быть одна, если клиент не раздал ее своим друзьям с этим ключом)
ЗЫ лицензию тоже написать не мешает, что прога типа только для 1 чела.

To Demo_S:
Не скажу я тебе, что идея - полный бред. Многие на самом деле так пользуются. Но что мне будет мешать получить такую прогу вместе с "ключом", а затем просто напросто распространить ее уже для N-го количества пользователей. ;D ;D ;D
А вот найти или придумать действительно уникальный ключ - вот это ВЕЩЬ!!!

Одно бесспорно - какой бы ты не написал алгоритм защиты, его взломают. Единственное что отпугивает 99\% процентов горе-хакеров, так это зажатые проги (ASPack, UPX ...). Можно не особо гимморится и защитить прогу ASProtect'oм.

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

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

Цитата GrAnd, 07.08.02, 09:40:45

Алгоритмы защиты и готовые проги, если надо могу скинуть.

а можно и мне скинуть?? буду очень признателен!!

AsPack платный, если б я был уверен, что продажа моей проги хоть какую-то выручку принесет, то можно было б и купить.
2GrAnd: насчет того, что инфа и проги должны быть бесплатными. Всем так хотелось бы. Но если задуматься, то программы из воздуха не появляются  и информация на деревьях не растет. Чтобы появилась книга, автор должен проделать большую работу, потратить свое время, не говоря уже о времени потраченном на обучение, чтобы стать человеком, в принципе способным написать что-то. То же и о программах. Никто, кроме самого автора не имеет права считать то или иное произведение интеллекта бесплатным. Если он считает нужным подарить свой труд людям, то только так. А все крики о том, что инфа и проги должны быть бесплатными-это бред незрелых компо-маньяков, утопия, такая же, как и социализм. Реальность иная. Ведь мы же не считаем, что продукты питания должны быть бесплатными, потому, что они растут на земле, которая в принципе никому не должна принадлежать. А тот, кто так думает, наверное полагает, что либо вырастить их не составит труда, либо надеется, что кто-то вырастит их за него, либо витает в облаках и думает, что живет в райском саду, где все само растет, а люди работают, чтобы просто поделится всем что имеют с первым попавшимся.
Мнения о бесплатности-красивая но глупая  мечта амбициозных романтиков.
Имхо.

Самая крутая защита, которую я видел выглядит так:

1. Прога запускаеться и собирает данные о компьютере.
2. Генерит текстовую строку.
3. Юзер отправляет эту строку разработчику.
4. Разработчик присылает ключ для конкретного юзера.

Проблемы:

1. При измененни конфигурации машины надо снова менять ключь
2. Чем больше юзеров тем больше головной боли (support).
3. Если юзер поменяет компьютер то он ничего не сможет доказать.

Если програма стоящая то запросто могу разработать программу зашиты.
Мне только интерестно знать на чём прога писана...