Конечно, поковыряюсь в них, если другого варианта нет.
Просто у меня сложение/вычитание 64битных чисел "занимает" около 50 тактов, а умножение под 150. Это, конечно неоптимизированно и через вызов функций. Так должно быть около 10/100.
Я просто прикинул, что для вычисления/проверки ключа несколько десятков сложений/умножений должно производиться. Получил под 10000 тактов. А тут на десятичный порядок меньше. Вот и подумал, что в этих методах сам алгоритм (его фрагмент) шифрования может и не участвовать, а что-то еще.
Вдруг, думал, кто-нибудь кинет пару строк, что типа так и так, помножили сложили, разделили, и еще пару раз, сравнили, не сошлось - дальше, иначе - выиграл. Хотя ожидался ответ, что, все нормально, просто все соптимизированно, взяли известный исходник, взяло очередной ключ, шифранули, сравнили с известным шифротекстом, далее в зависимости от результата сравнения.
Именно22.12.03 13:29 Автор: mss <Сергей> Статус: Member
> Хотя > ожидался ответ, что, все нормально, просто все > соптимизированно, взяли известный исходник, взяло очередной > ключ, шифранули, сравнили с известным шифротекстом, далее в > зависимости от результата сравнения. Вот-вот-вот... я только что собирался это сказать :)
Кстати - результат сравнения по наблюдениям получается всегда один и тот же, за исключением... но это уже отдельный разговор.
Кстати, обратите внимание на цифирки 1,2,3
RC5:-1) Auto select 0) SES 1-pipe 1) SES 2-pipe
2) DG 2-pipe 3) DG 3-pipe 4) DG 3-pipe alt
5) SS 2-pipe
;) Ведь использование максимально доступного числа дублированных блоков процессора - это тоже часть оптимизации.
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
