Почему не перепишут криптографические алгоритмы на ASM?
Почему например симметричные шифры не перепишут на ASM?
Предполагаю что при хорошем ассемблерном коде быстродействие значительно увеличилось, думаю уж на 20% точно, ведь это чистый математический аппарат, и тут есть смысл переписать алгоритм, на машинный команды.
Это же не работа с API где в принципе всё равно на чем писать что на C что на ASM.
Да, конечно оптимизация кода сейчас на высшем уровне, но человек, особенно если будет стараться писать под максимальное быстродействие может добиться результатов куда лучше на ASM'е.
Не ужели ни кто за долгую жизнь крипто-алгоритмов не хочет за это взяться, тем более за такое длительное время жизни например, блочных шифров.
Наверно современной компьютерной индустрии на это просто наплевать, прога должна соответствовать следующим критериям:
1). Здоровый дистрибутив, чем больше тем лучше.
2). Жрать много системных ресурсов.
3). И быть глючной.
1) Есть такая беда. Но хватает и компактных программ.
2) Аналогично.
3) Аналогично.
Я б сказал не хвататет пункта 4, где надо поругать виндовс и Билла Гейтса. :)
комментариев: 100 документов: 49 редакций: 14
Ну например когда копируешь инфу с одного винта на другой, и оба зашифрованы, вот тут вот и почувствуешь, особенно если машина 600Mhz, с 256Kb кеша на камне, и системной в 100Mhz.
А что переписывать-то, это же алгоритм, настругал отладил, оптимизировал, посмотрел нет ли глюков, так, опять оптимизировал и выложил. Под Intel-совместимые один фиг, под MAC найдутся люди которые напишут.
Dа, например, GnuPG и TrueCrypt за место PGP Desktop.
А за что ругать-то. Подход Microsoft делать деньги, что по у них совсем не плохо получается. И Билли помоему парень не бедный.
И чем ждать милости от природы, сделай апгрейд своего 600 MHz :)
комментариев: 1515 документов: 44 редакций: 5786
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 32 документов: 0 редакций: 0
Вот например, реализация ГОСТ 28147-89 на ассемблере для x86 есть на страничке Андрея Винокурова: http://www.enlight.ru/crypto/
А разницу в 2-3 раза ты заметишь? Оптимизированый ассемблерный код может творить чудеса, в которые сразу и не вериться.
Если ты вчера выучил пару команд ассеблера, то я бы не удивился, если ассемблерный вариант оказался бы в 5 раз медленее.
Чтобы не оставаться голословным, я привожу свой вариант rc4 оптимизированого под amd x64 архитектуру. Он дает ускорение в полтора раза, по сравнению с сишным исходником.
На алгоритме blowfish я получал и большую разницу, а вот aes не хочет особо оптимизироваться :(
Вот собственно код:
Ну а неверующим в оптимизацию – бегом читать мануалы от intel и amd.
комментариев: 1060 документов: 16 редакций: 32
В борланде тоже не идиоты работают, и их модуль system.pas переписывался и отлаживался несколько лет, а код на паскале я наваял за несколько минут, и всей разницы в скорости было 5%. Это я все о том же – что заморачиваться и писать асм под конкретную платформу в 99% случаев смысла нет. Хорошо написанный код, собранный нормальным компилятором, по скорости от ассемблерного кода должен отличаться на единицы процентов.
Компиляторы MSVC2005 и intel c показали почти одинаковые результаты.
Кстати, ассимитричные криптоалгоримы ПРИНЦИПИАЛЬНО не могут быть оптимально реализованы на си.
Возьмем например такую операцию, как сложение двух больших чисел. На си это выглядит так (пример из rsaref):
Как вы видите, мы должны специально подсчитывать перенос, и хранить его в отдельной переменной. При реализации на ассемблере, у нас есть флаг переноса и команда adc, которая как будто специально создана для нашей задачи
Разница в производительность – минимум в 2 раза.
Идем далее. Как еще можно оптимизировать работы с большими числами? Очевидно, что чем меньше операций на это тратится, тем больше будет производительность. Пусть мне кто нибудь ответит: как в си можно работать с числами 128 битного размера? А никак! Максимум поддерживается int64 тип, и то он компилируется всегда в add/adc. На ассемблере я могу легко использовать sse расширения, и вычислять не порциями по 32 бита, а сразу по 128. Тут разница производительности уже вырастает до 5 раз.
Идем далее. Если нужно постоянно переваривать большие массивы данных в памяти (например вычисления связаные с 3d), то на си нельзя даже выполнить такую необходимую операцию, как предвыборку блока данных, который нам понадобиться позднее. На ассемблере это делается prefetchxx командами, так что в таких тяжелых случаях разница становиться уже в десятки раз.
Ну и наконец программирование на ассемблере несколько перестраивает подход к алгоритмам. В многих алгоритмах есть места, которые при небольшом изменении реализовались бы гораздо оптимальнее, но компилятор об этом догадаться не может.
комментариев: 5 документов: 3 редакций: 0
комментариев: 11558 документов: 1036 редакций: 4118
%% code %%
комментариев: 9796 документов: 488 редакций: 5664
Просто вероятность фатальной ошибки велика. Мне помнятся и примитивные ошибки, вроде того как если первый байт в ключе равен нулю, то и все другие байты обнулялись и более труднообнаружимые.
Есть вероятность и "изобретения велосипеда".
Методы реализации криптоалгоритмов изучены в тысячах научных работ, где расписаны все трюки оптимизации от 8-битных контроллеров до многопроцессорных машин. Тот же AES можно реализовать с просчитанными заранее комбинациями S-блоков и операцией MixColumn. Тогда он будет быстрее, когда разменивается память на скорость.
Наверняка и все методы реализации алгоритмов под ассемблер изучены вдоль и поперёк. И если они не используются то есть какие-то соображения неперспективности. Поищите сами уже имеющиеся материалы в этой области, если это Вас интересует.
Если есть возможность подвести под свою работу солидную научную базу с выкладками, графиками, и целью является в первую очередь научное исследование и экспериментирование, тогда есть смысл. А если просто что-то сделать "на коленке", то смысла нет. Лучше проверенные, консервативные решения и устоявшиеся стандарты.