Ну вот например схема проверки , для регистрации проги нужно ввести Message и Signature .

CryptHashData,Hash,Message
CryptVerifySignature,Hash,Signature,Key

Hash - MD5 хеш от Message
Signature - зашифрованное секретным ключём Message
Key - публичный ключ

CryptHashData - берёт MD5 хеш от Message
CryptVerifySignature - расшифровывает Signature , также берёт MD5 хеш от расшифрованного и сверяет хеши .

Беру любой набор байт наугад (будет Signature) , расшифровываю их публичным Key (будет Message) и ввожу в прогу эти Message и Signature .
Что в этой схеме вернёт CryptVerifySignature - TRUE или FALSE ?
Было бы слишком просто если TRUE , где я гоню ?

Если я правильно вкурил, то, конечно, FALSE. Ведь хеш-то не совпадет! Ведь MD5 считается! А при чем тут RSA?

„Ведь хеш-то не совпадет!Ведь MD5 считается!“

Почему , ведь MD5 хеш и там и там , берёться от одного и того-же Message . Т.е. расшифрованная Signature это и будет Message .

„А при чем тут RSA?“

Это вроде "стандартная" схема цифровой подписи RSA , публичный ключ у меня RSA-512 , ним расшифровываеться Signature . Это если я конечно правильно всё понимаю .

з.ы. В стойкости RSA я не сомневаюсь , меня интересует именно эта схема . Т.е. CryptVerifySignature должна вернуть TRUE . Как это пропатчить или сделать лоадер я знаю , не предлагайте .

Почему , ведь MD5 хеш и там и там , берёться от одного и того-же Message . Т.е. расшифрованная Signature это и будет Message
там не Message, там хеши, вот схема подписи:

создание:
http://bcw.narod.ru/pic/web_5.jpg
проверка:
http://bcw.narod.ru/pic/web_6.jpg

ну и сама статья
http://bcw.narod.ru/cryptoapi.html

bogrus

Я запутался с терминами Signature и Message. Если не сложно, то еще раз - для особо одаренных :(

Fuck. Пока писал, уже Funbit ответил :)

А-а блин , там хеши . Есть у меня несколько копий этой статьи и многих других , сам уже запутался :)
Надо теперь подумать , что это меняет ...

Хм... Помоему тут не про то речь идет...
Icebp
Единственное что могу предположить это align памяти, у меня так уже было... При первом запуске где-то юзается неалигненная память - при втором - алигненная.

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

snatch
Да я вроде использую нормальный генератор случайных чисел. Там у меня результат инструкции RDTSC после каждого нажатия клавиши используется для генерации случайных простых чисел. Получается аналог рулетки. Так как частота несколько гигагерц, то предсказать что получится не сможет даже тот кто жмет клавиши. Там в программе для рандомизации надо нажимать любую клавишу 8 раз для генерации первого простого числа и еще 8 раз для второго. Кстати я тут понял:
bogrus
У тебя программа висела потому что ты не жал клавиши. Нажатия требуются для рандомизации. Там когда нажмешь на экране будут появляться числа 1, 2, ... , 8 , потом начнется генерация первого простого числа и на экране будет мельтешить символ, показывая насколько быстро идет процесс. Как число сгенерится, то оно высветится на экране. Потом надо будет опять 8 раз нажать любую клавишу для генерации второго простого числа. Когда все сгенерится, то на экране появятся модуль RSA и секретный ключ. Чтобы сохранить результат в файлах надо будет нажать клавишу "w" (маленькая w, а не большая).
masquer
Так а что там непонятно? Вроде я все писал довольно прозрачно без всяких изощрений. Приведи пример того что тебе непонятно.
All
Интересно узнать как обстоит дело со скоростью моей программы у других. У кого-нибудь есть идеи насчет разной скорости до и после запуска винампа (на всякий случай еще раз повторю что в обоих случаях программа запускалась под чистым ДОС-ом, а следовательно в монопольном режиме)? У меня на этот счет подозрения примерно такого типа: винамп чего-то там инициализирует и из-за этого скорость выполнения инструкций MOVQ (ими я копирую большие участки памяти) в моей программе почему то растет. У кого есть какие мысли на это счет. Да, еще вопрос: я правильно понимаю, что сейчас наилучшим алгоритмом факторизации является метод решета общего числового поля или появились новые алгоритмы? Возможно ли, что АНБ или ФАПСИ знают какой то более крутой алгоритм или у них просто большие вычислительные мощности, а факторизуют они (если факторизуют вообще) тем же решетом общего числового поля.
Да, может выложить мою программу цифровой подписи?

Icebp
Что-то EMMS я заметил только перед самым int 20h, по-моему это не правильно.

года полтора назад в ru.crypt один человек говорил, что за 2 месяца на кластере из P-III сумел разложить 512-битный ключ Майкрософта, используемый для подписи дллок криптопровайдеров... Типа лень ему было каждую новую версию в Microsoft на подпись отсылать )

2Icebp, да, для больших чисел ничего лучше GNFS пока не придумали :( С этой штукой одна проблема -- нормальную реализацию достать очень непросто :(

Icebp
„из-за этого скорость выполнения инструкций MOVQ (ими я копирую большие участки памяти) в моей программе почему то растет“
Про правильное использование MOVQ написано
, например, здесь :
http://www.sources.ru/NonCGI/Forum5/HTML/000080.html
Обязательно позаботься о выравнивании на границу
8 байт. dq по-моему этого не делает ? В статьях про быстроту Виндовс упоминалось, что необходимость сохранять MMX регистры тормозит переключение контекста.
Я не спец по MMX, но почему бы не быть такой ситуации - система ,узнав что MMX использовался
( возможно бит какой есть в Интеле), начинает сохранять его регистры - отсюда тормоза.

Icebp „У тебя программа висела потому что ты не жал клавиши“

Да , действительно . Надо было инструкцию по пользованию :)

flankerx „сумел разложить 512-битный ключ Майкрософта, используемый для подписи дллок “

Неужели они когда-то использовали 512-бит , сейчас кажеться не меньше 1024 .

All можно я ещё вопросик не по теме .
Если в моей схеме Signature - это есть зашифрованный MD5 хеш от Message , тогда :

Беру любой набор байт наугад (будет Signature) , расшифровываю их публичным Key (будет MD5 хеш) , потом напускаю MD5 брутфорсер на этот хеш и получаю Message . Вуаля ?

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

Это же быстрее , чем факторизовать . Или где меня опять перекосило ?

Насчет MMX valterg прав.
Как влияет winamp не знаю, но:
1) выравнивание на 8 обязательно (в смысле желательно)
2) в конце блока MMX пересылок желательно вставить инструкцию EMMS (признак очистки), иначе при переключении контекста ось может сохранять MMX регистры, хотя не знаю присутствует ли оно в коде.
3) можно дополнительно оптимизировать пересылки: например в процедуре copy25 8 раз повторяется movq mm0,m64 и movq m64,mm0, хотя для оптимизации работы конвейера лучше использовать

movq mm0,..
movq mm1,..
...
movq ..,mm0
movq ..,mm1
...
emms
ret

Eсли EMMS не поможет, то не знаю, разве что подробнее рыться в IA-32 manual по использованию FPU и MMX (надеюсь, эмуляция FPU отключена, иначе movq вообще бы не работали)

PS: исправление - "иначе при переключении контекста ось может сохранять MMX регистры" - это фигня, прошу прощения. Сохранение состояния регистров не зависит от FPU Tag Word, а зависит только от реализации софта - либо FSAVE\FXSAVE (сохранять все), либо FSTENV (только управляющие регистры).

Что может остаться "полезного" от винампа после перезагрузки оси ? Состояние FPU (может пропущена инициализация FINIT) или какой флаг в CRx\EFLAGS (например AC) ?