Почему не перепишут криптографические алгоритмы на ASM?
Почему например симметричные шифры не перепишут на ASM?
Предполагаю что при хорошем ассемблерном коде быстродействие значительно увеличилось, думаю уж на 20% точно, ведь это чистый математический аппарат, и тут есть смысл переписать алгоритм, на машинный команды.
Это же не работа с API где в принципе всё равно на чем писать что на C что на ASM.
Да, конечно оптимизация кода сейчас на высшем уровне, но человек, особенно если будет стараться писать под максимальное быстродействие может добиться результатов куда лучше на ASM'е.
Не ужели ни кто за долгую жизнь крипто-алгоритмов не хочет за это взяться, тем более за такое длительное время жизни например, блочных шифров.
Наверно современной компьютерной индустрии на это просто наплевать, прога должна соответствовать следующим критериям:
1). Здоровый дистрибутив, чем больше тем лучше.
2). Жрать много системных ресурсов.
3). И быть глючной.
А зачем? Работают всё вполне себе быстро. Разницу в 20% я замечу разве что занимаясь круглые сутки только шифровкой. Да и под каждую платформу заколебешься все переписывать, оптимизировать и искать глюки.
1) Есть такая беда. Но хватает и компактных программ.
2) Аналогично.
3) Аналогично.
Я б сказал не хвататет пункта 4, где надо поругать виндовс и Билла Гейтса. :)
Ну например когда копируешь инфу с одного винта на другой, и оба зашифрованы, вот тут вот и почувствуешь, особенно если машина 600Mhz, с 256Kb кеша на камне, и системной в 100Mhz.
А что переписывать-то, это же алгоритм, настругал отладил, оптимизировал, посмотрел нет ли глюков, так, опять оптимизировал и выложил. Под Intel-совместимые один фиг, под MAC найдутся люди которые напишут.
Dа, например, GnuPG и TrueCrypt за место PGP Desktop.
А за что ругать-то. Подход Microsoft делать деньги, что по у них совсем не плохо получается. И Билли помоему парень не бедный.
Ты видно никогда не програмировал, если думаешь, что "настругал-посмотрел" и готово.
И чем ждать милости от природы, сделай апгрейд своего 600 MHz :)
Строго говоря, насколько я слышал, часть криптоштук написана именно на асме. И как бы чуть ли не openssl.. :)
Людей зачастую интересует переносимость и поддержка как можно более большого количества платфотм (при приемлимой оптимизации) нежели выжимание нескольких лишних процентов производительности на какой-то одной платформе. Хотя специализированные реализации на ассемблере для конкретных платформ тоже встречаются.
Вот например, реализация ГОСТ 28147-89 на ассемблере для x86 есть на страничке Андрея Винокурова: http://www.enlight.ru/crypto/
А разницу в 2-3 раза ты заметишь? Оптимизированый ассемблерный код может творить чудеса, в которые сразу и не вериться.
Как-то по молодости написал процедуру поиска подстроки в строке на Pascal (Delphi 3). Потом нашел ТАКОЙ ЖЕ ПО АЛГОРИТМУ кусок кода на ассемблере (кажется в system.pas там же в Delphi), решил же сравнить производительность. К моему глубочайшему удивлению, разница составила процентов 5 (sic!). Так что оптимизирующий компилятор, создающий тот самый оптимизированный ассемблерный код, делает по моему мнению ненужной реализацию различных алгоритмов под различные процессоры. Старые компиляторы C++ вообще в явном виде выводили ассемблерный код, из которого потом и собирался EXE (спросите какие – не вспомню, кажется старые Борланды).
Разница в производительности зависит от конкретного алгоритма, и от уровня знаний архитектуры процессора, под который пишется код.
Если ты вчера выучил пару команд ассеблера, то я бы не удивился, если ассемблерный вариант оказался бы в 5 раз медленее.
Чтобы не оставаться голословным, я привожу свой вариант rc4 оптимизированого под amd x64 архитектуру. Он дает ускорение в полтора раза, по сравнению с сишным исходником.
На алгоритме blowfish я получал и большую разницу, а вот aes не хочет особо оптимизироваться :(
Вот собственно код:
Ну а неверующим в оптимизацию – бегом читать мануалы от intel и amd.
Какой компилятор использовался для C кода? А то ведь компилятор Intel в ряде хороших случаев рвёт все остальные на те же 50%. Проводилась ли оптимизация C кода?
В продолжение моей телеги про дельфовский модуль и ассемблерную реализацию поиска в нем:
В борланде тоже не идиоты работают, и их модуль system.pas переписывался и отлаживался несколько лет, а код на паскале я наваял за несколько минут, и всей разницы в скорости было 5%. Это я все о том же – что заморачиваться и писать асм под конкретную платформу в 99% случаев смысла нет. Хорошо написанный код, собранный нормальным компилятором, по скорости от ассемблерного кода должен отличаться на единицы процентов.
Вот код на си, с которым проводилось сравнение http://astu.secna.ru/russian/s.....54_alex/text_rc4.htm[link2]
Компиляторы MSVC2005 и intel c показали почти одинаковые результаты.
Кстати, ассимитричные криптоалгоримы ПРИНЦИПИАЛЬНО не могут быть оптимально реализованы на си.
Возьмем например такую операцию, как сложение двух больших чисел. На си это выглядит так (пример из rsaref):
Как вы видите, мы должны специально подсчитывать перенос, и хранить его в отдельной переменной. При реализации на ассемблере, у нас есть флаг переноса и команда adc, которая как будто специально создана для нашей задачи
Разница в производительность – минимум в 2 раза.
Идем далее. Как еще можно оптимизировать работы с большими числами? Очевидно, что чем меньше операций на это тратится, тем больше будет производительность. Пусть мне кто нибудь ответит: как в си можно работать с числами 128 битного размера? А никак! Максимум поддерживается int64 тип, и то он компилируется всегда в add/adc. На ассемблере я могу легко использовать sse расширения, и вычислять не порциями по 32 бита, а сразу по 128. Тут разница производительности уже вырастает до 5 раз.
Идем далее. Если нужно постоянно переваривать большие массивы данных в памяти (например вычисления связаные с 3d), то на си нельзя даже выполнить такую необходимую операцию, как предвыборку блока данных, который нам понадобиться позднее. На ассемблере это делается prefetchxx командами, так что в таких тяжелых случаях разница становиться уже в десятки раз.
Ну и наконец программирование на ассемблере несколько перестраивает подход к алгоритмам. В многих алгоритмах есть места, которые при небольшом изменении реализовались бы гораздо оптимальнее, но компилятор об этом догадаться не может.
Последние компиляторы (например 9.0 от Интела) поддерживают SSE, автоматическую параллеризацию кода, префетчинги и все дела. И делают это очень неплохо. Кстати они также позволяют осуществлять компиляцию через ассемблер и всегда можно посмотреть что же они там нагенерили.
Господа, при цитировании в своих сообщениях кода выделяйте его для лучшей читабельности разметкой:
%% code %%
В ссылке, которую я приводил, использовалась готовая реализация ассемблерного кода AES от профессора Брайана Гладмана. Дело не в том, что это известный профессор или что такое не под силу рядовому программисту. Тестовые векторы всем доступны.
Просто вероятность фатальной ошибки велика. Мне помнятся и примитивные ошибки, вроде того как если первый байт в ключе равен нулю, то и все другие байты обнулялись и более труднообнаружимые.
Есть вероятность и "изобретения велосипеда".
Методы реализации криптоалгоритмов изучены в тысячах научных работ, где расписаны все трюки оптимизации от 8-битных контроллеров до многопроцессорных машин. Тот же AES можно реализовать с просчитанными заранее комбинациями S-блоков и операцией MixColumn. Тогда он будет быстрее, когда разменивается память на скорость.
Наверняка и все методы реализации алгоритмов под ассемблер изучены вдоль и поперёк. И если они не используются то есть какие-то соображения неперспективности. Поищите сами уже имеющиеся материалы в этой области, если это Вас интересует.
Если есть возможность подвести под свою работу солидную научную базу с выкладками, графиками, и целью является в первую очередь научное исследование и экспериментирование, тогда есть смысл. А если просто что-то сделать "на коленке", то смысла нет. Лучше проверенные, консервативные решения и устоявшиеся стандарты.
Уважаемые ассемблерные программисты!
Попробуйте представить себе процесс переноса ассемблерного кода, написанного для TASM под Windows с оптимизацией для x86_64, на платформу, например, UltraSPARC64, под Solaris, с использованием синтаксиса AT&T ассемблера. Думаю, вопросов поубудет.
Учитывая, что тот же OpenSSL работает на десятках различных платформ – вопросов вообще не должно остаться.
P. S. А то некоторые воспринимают наличие SSE и команд add/adc как данность :)
господа =))) вопрос от нюба в асме )))
необходимо реализовать на тесее шифрование потока из 8 байт по алгоритму а5/2, данные лежат в озу данных, ключ – в пзу программ...
как бы вопрос – с чего начать-то?? вдруг кто кодил от нечего делать.... ммм...