Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Именно 22.12.03 13:29 Число просмотров: 2395
Автор: 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
;) Ведь использование максимально доступного числа дублированных блоков процессора - это тоже часть оптимизации.
|
|
<dnet>
|
1.800.000 key/sec на P4-2700 это номано? 19.12.03 03:22
Автор: Korsh <Мельников Михаил> Статус: Elderman
|
|
|
|
А где ты такой процессор нашёл?? 19.12.03 21:36
Автор: JINN <Sergey> Статус: Elderman
|
У INTEL-а нет процов с частотой 2,7-(
P4 w/HT
P4
|
| |
Сорри ошибся цифрой 2,6 с HT 21.12.03 04:13
Автор: Korsh <Мельников Михаил> Статус: Elderman
|
|
|
|
[RC5] 1.800.000 key/sec на P4-2700 это номано? 19.12.03 18:35
Автор: Miraj <Михаил> Статус: Member
|
|
отруби HT и вс станет на свои места! :)
|
| |
Ну да на один поток 1.800.000 в сумарности 3.600.000, но помойму все равно мало 21.12.03 04:16
Автор: Korsh <Мельников Михаил> Статус: Elderman
|
|
|
| |
Это что ж около 1000 тактов на ключ? 19.12.03 10:35
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Должно быть около 3 900 000:
Что там за метод используется, интересно?
|
| | |
[RC5] почему нет? метод - исходники выложены 22.12.03 11:35
Автор: jammer <alex naumov> Статус: Elderman
|
тут
|
| | | |
Там же только исходники. 22.12.03 12:17
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
Конечно, поковыряюсь в них, если другого варианта нет.
Просто у меня сложение/вычитание 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
;) Ведь использование максимально доступного числа дублированных блоков процессора - это тоже часть оптимизации.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
