информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[RC5] 1.800.000 key/sec на P4-2700 это номано? 19.12.03 18:35  Число просмотров: 2454
Автор: Miraj <Михаил> Статус: Member
<"чистая" ссылка>
отруби HT и вс станет на свои места! :)
<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 и вс станет на свои места! :)
[RC5] Нет! 19.12.03 10:27  
Автор: Yurii <Юрий> Статус: Elderman
<"чистая" ссылка>
Должно быть около 3 900 000:

http://n0cgi.distributed.net/speed/query.php?cputype=all&arch=0&contest=rc572
Ну да на один поток 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

;) Ведь использование максимально доступного числа дублированных блоков процессора - это тоже часть оптимизации.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach