id: Гость   вход   регистрация
текущее время 21:13 28/03/2024
Автор темы: Serghan, тема открыта 18/11/2006 13:45 Печать
https://www.pgpru.com/Форум/Криптография/ПочемуНеПерепишутКриптографическиеАлгоритмыНаASM
создать
просмотр
ссылки

Почему не перепишут криптографические алгоритмы на ASM?


Почему например симметричные шифры не перепишут на ASM?


Предполагаю что при хорошем ассемблерном коде быстродействие значительно увеличилось, думаю уж на 20% точно, ведь это чистый математический аппарат, и тут есть смысл переписать алгоритм, на машинный команды.


Это же не работа с API где в принципе всё равно на чем писать что на C что на ASM.
Да, конечно оптимизация кода сейчас на высшем уровне, но человек, особенно если будет стараться писать под максимальное быстродействие может добиться результатов куда лучше на ASM'е.


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


Наверно современной компьютерной индустрии на это просто наплевать, прога должна соответствовать следующим критериям:


1). Здоровый дистрибутив, чем больше тем лучше.
2). Жрать много системных ресурсов.
3). И быть глючной.


 
На страницу: 1, 2 След.
Комментарии
— Гость (18/11/2006 14:15)   <#>
А зачем? Работают всё вполне себе быстро. Разницу в 20% я замечу разве что занимаясь круглые сутки только шифровкой. Да и под каждую платформу заколебешься все переписывать, оптимизировать и искать глюки.

1) Есть такая беда. Но хватает и компактных программ.
2) Аналогично.
3) Аналогично.
Я б сказал не хвататет пункта 4, где надо поругать виндовс и Билла Гейтса. :)
— Serghan (18/11/2006 14:53)   профиль/связь   <#>
комментариев: 100   документов: 49   редакций: 14

Ну например когда копируешь инфу с одного винта на другой, и оба зашифрованы, вот тут вот и почувствуешь, особенно если машина 600Mhz, с 256Kb кеша на камне, и системной в 100Mhz.

А что переписывать-то, это же алгоритм, настругал отладил, оптимизировал, посмотрел нет ли глюков, так, опять оптимизировал и выложил. Под Intel-совместимые один фиг, под MAC найдутся люди которые напишут.

Dа, например, GnuPG и TrueCrypt за место PGP Desktop.

А за что ругать-то. Подход Microsoft делать деньги, что по у них совсем не плохо получается. И Билли помоему парень не бедный.
— Гость (19/11/2006 18:26)   <#>
Ты видно никогда не програмировал, если думаешь, что "настругал-посмотрел" и готово.

И чем ждать милости от природы, сделай апгрейд своего 600 MHz :)
— spinore (20/11/2006 09:25)   профиль/связь   <#>
комментариев: 1515   документов: 44   редакций: 5786
Строго говоря, насколько я слышал, часть криптоштук написана именно на асме. И как бы чуть ли не openssl.. :)
— unknown (20/11/2006 10:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664


http://loop-aes.sourceforge.ne.....op-AES-v3.0c.tar.bz2

Makefile detects processor type from kernel configuration. If selected processor type is x86 processor or AMD64 processor, optimized assembler implementations of AES and MD5 are used instead of C implementations. If you want to unconditionally disable x86 assembler AES and MD5 implementations, specify X86_ASM=n on make command line. If you want to unconditionally disable AMD64 assembler AES and MD5 implementations, specify AMD64_ASM=n on make command line.



— RElf (17/01/2007 23:34)   профиль/связь   <#>
комментариев: 32   документов: 0   редакций: 0
Людей зачастую интересует переносимость и поддержка как можно более большого количества платфотм (при приемлимой оптимизации) нежели выжимание нескольких лишних процентов производительности на какой-то одной платформе. Хотя специализированные реализации на ассемблере для конкретных платформ тоже встречаются.

Вот например, реализация ГОСТ 28147-89 на ассемблере для x86 есть на страничке Андрея Винокурова: http://www.enlight.ru/crypto/
— Гость (19/01/2007 20:58)   <#>

А разницу в 2-3 раза ты заметишь? Оптимизированый ассемблерный код может творить чудеса, в которые сразу и не вериться.
— Гость (19/01/2007 22:53)   <#>
Как-то по молодости написал процедуру поиска подстроки в строке на Pascal (Delphi 3). Потом нашел ТАКОЙ ЖЕ ПО АЛГОРИТМУ кусок кода на ассемблере (кажется в system.pas там же в Delphi), решил же сравнить производительность. К моему глубочайшему удивлению, разница составила процентов 5 (sic!). Так что оптимизирующий компилятор, создающий тот самый оптимизированный ассемблерный код, делает по моему мнению ненужной реализацию различных алгоритмов под различные процессоры. Старые компиляторы C++ вообще в явном виде выводили ассемблерный код, из которого потом и собирался EXE (спросите какие – не вспомню, кажется старые Борланды).
— Гость (20/01/2007 06:58, исправлен 20/01/2007 21:50)   <#>
Разница в производительности зависит от конкретного алгоритма, и от уровня знаний архитектуры процессора, под который пишется код.
Если ты вчера выучил пару команд ассеблера, то я бы не удивился, если ассемблерный вариант оказался бы в 5 раз медленее.
Чтобы не оставаться голословным, я привожу свой вариант rc4 оптимизированого под amd x64 архитектуру. Он дает ускорение в полтора раза, по сравнению с сишным исходником.
На алгоритме blowfish я получал и большую разницу, а вот aes не хочет особо оптимизироваться :(

Вот собственно код:



Ну а неверующим в оптимизацию – бегом читать мануалы от intel и amd.
— sentaus (20/01/2007 10:30)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Какой компилятор использовался для C кода? А то ведь компилятор Intel в ряде хороших случаев рвёт все остальные на те же 50%. Проводилась ли оптимизация C кода?
— Гость (20/01/2007 10:52)   <#>
В продолжение моей телеги про дельфовский модуль и ассемблерную реализацию поиска в нем:
В борланде тоже не идиоты работают, и их модуль system.pas переписывался и отлаживался несколько лет, а код на паскале я наваял за несколько минут, и всей разницы в скорости было 5%. Это я все о том же – что заморачиваться и писать асм под конкретную платформу в 99% случаев смысла нет. Хорошо написанный код, собранный нормальным компилятором, по скорости от ассемблерного кода должен отличаться на единицы процентов.
— Гость (20/01/2007 19:03, исправлен 20/01/2007 21:51)   <#>
Вот код на си, с которым проводилось сравнение http://astu.secna.ru/russian/s.....54_alex/text_rc4.htm
Компиляторы MSVC2005 и intel c показали почти одинаковые результаты.

Кстати, ассимитричные криптоалгоримы ПРИНЦИПИАЛЬНО не могут быть оптимально реализованы на си.
Возьмем например такую операцию, как сложение двух больших чисел. На си это выглядит так (пример из rsaref):



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



Разница в производительность – минимум в 2 раза.
Идем далее. Как еще можно оптимизировать работы с большими числами? Очевидно, что чем меньше операций на это тратится, тем больше будет производительность. Пусть мне кто нибудь ответит: как в си можно работать с числами 128 битного размера? А никак! Максимум поддерживается int64 тип, и то он компилируется всегда в add/adc. На ассемблере я могу легко использовать sse расширения, и вычислять не порциями по 32 бита, а сразу по 128. Тут разница производительности уже вырастает до 5 раз.
Идем далее. Если нужно постоянно переваривать большие массивы данных в памяти (например вычисления связаные с 3d), то на си нельзя даже выполнить такую необходимую операцию, как предвыборку блока данных, который нам понадобиться позднее. На ассемблере это делается prefetchxx командами, так что в таких тяжелых случаях разница становиться уже в десятки раз.
Ну и наконец программирование на ассемблере несколько перестраивает подход к алгоритмам. В многих алгоритмах есть места, которые при небольшом изменении реализовались бы гораздо оптимальнее, но компилятор об этом догадаться не может.
— vvkot (20/01/2007 21:10)   профиль/связь   <#>
комментариев: 5   документов: 3   редакций: 0
Последние компиляторы (например 9.0 от Интела) поддерживают SSE, автоматическую параллеризацию кода, префетчинги и все дела. И делают это очень неплохо. Кстати они также позволяют осуществлять компиляцию через ассемблер и всегда можно посмотреть что же они там нагенерили.
— SATtva (20/01/2007 21:47)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Господа, при цитировании в своих сообщениях кода выделяйте его для лучшей читабельности разметкой:
%% code %%
— unknown (22/01/2007 09:29)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В ссылке, которую я приводил, использовалась готовая реализация ассемблерного кода AES от профессора Брайана Гладмана. Дело не в том, что это известный профессор или что такое не под силу рядовому программисту. Тестовые векторы всем доступны.

Просто вероятность фатальной ошибки велика. Мне помнятся и примитивные ошибки, вроде того как если первый байт в ключе равен нулю, то и все другие байты обнулялись и более труднообнаружимые.

Есть вероятность и "изобретения велосипеда".
Методы реализации криптоалгоритмов изучены в тысячах научных работ, где расписаны все трюки оптимизации от 8-битных контроллеров до многопроцессорных машин. Тот же AES можно реализовать с просчитанными заранее комбинациями S-блоков и операцией MixColumn. Тогда он будет быстрее, когда разменивается память на скорость.

Наверняка и все методы реализации алгоритмов под ассемблер изучены вдоль и поперёк. И если они не используются то есть какие-то соображения неперспективности. Поищите сами уже имеющиеся материалы в этой области, если это Вас интересует.

Если есть возможность подвести под свою работу солидную научную базу с выкладками, графиками, и целью является в первую очередь научное исследование и экспериментирование, тогда есть смысл. А если просто что-то сделать "на коленке", то смысла нет. Лучше проверенные, консервативные решения и устоявшиеся стандарты.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3