Добрый день!
Сначала писал реализацию на С+inline asm, потом подумал, надо сделать библиотеку и для всей Колибри, поэтому переписываю на fasm
Пока написал и довожу до ума SHA256, CRC32, RC6.
В очереди стоит LZMA как архивация.
Реализую все в виде каждого отдельного файла с одной-двумя экспортируемыми процедурами:
sha256.asm, rc6.asm и т.д.
Собираюсь использовать вызовы из нее в SHELL.
Во первых, вопрос: есть ли какие либо особенности для написания алгоритмов так, чтобы можно было по типу системной библиотеки сделать?
Второй вопрос: какие в ПЕРВУЮ очередь надо добавить алгоритмы?
Естественно временной ресурс ограничен, поэтому по 1-2 алгоритма шифрования, 1-2 архивации ну и хэш
Сам планирую еще реализовать Trivium (поточный шифр), RSA и простенький zip
Код выложу сюда в течение нескольких дней.
Шифрование, хеши и архивация - что нужно в библиотеке?
В archiver.obj есть реализация SHA256 и AES, правда, наружу они не торчат.
Процедуры для RSA писал halyavin, они есть в cpuid (где используются для тестов скорости).
Реализация MD5 тоже есть (svn://kolibrios.org/programs/develop/examples/md5/trunk/md5.asm), правда, код там мог бы быть и получше.
Процедуры для RSA писал halyavin, они есть в cpuid (где используются для тестов скорости).
Реализация MD5 тоже есть (svn://kolibrios.org/programs/develop/examples/md5/trunk/md5.asm), правда, код там мог бы быть и получше.
Ушёл к умным, знающим и культурным людям.
А где исходники этого archiver.obj? В svn я что-то не нашел...
Ксати такой вопрос как оптимально сложить числа больше чем 32бита?
кстати RC6 - это не AES, так что тоже теперь почти есть.
Ну md5 - уже ушел в прошлое, а вот sha1 надо написать для совместимости
Ксати такой вопрос как оптимально сложить числа больше чем 32бита?
кстати RC6 - это не AES, так что тоже теперь почти есть.
Ну md5 - уже ушел в прошлое, а вот sha1 надо написать для совместимости
Они там есть, но в неочевидном месте, связанном с тем, что изначально он был только плагином к kfar, а теперь в основном является плагином. svn://kolibrios.org/programs/fs/kfar/kfar_arc/.XVilka wrote:А где исходники этого archiver.obj? В svn я что-то не нашел...
64-битное сложение edx:eax += ebx:ecx:XVilka wrote:Ксати такой вопрос как оптимально сложить числа больше чем 32бита?
Code: Select all
add eax,ecx
adc edx,ebx
Ушёл к умным, знающим и культурным людям.
XVilka
кстати, с точки пользователя - программы и библиотеки на fasm переписывать не обязательно. компилятор Си выдаёт результирующие файлы не намного хуже ассемблерных (по размеру и скорости исполнения), зато скорость разработки существенно повышается. хотя согласен, разработка на Си выпадает из концепции KOS.
кстати, с точки пользователя - программы и библиотеки на fasm переписывать не обязательно. компилятор Си выдаёт результирующие файлы не намного хуже ассемблерных (по размеру и скорости исполнения), зато скорость разработки существенно повышается. хотя согласен, разработка на Си выпадает из концепции KOS.
XVilka
diamond
Albom
Весьма нужная вещь. Успехов в реализации!Пока написал и довожу до ума SHA256, CRC32, RC6.
В очереди стоит LZMA как архивация.
diamond
Ну, вот уже как минимум 2 человека. Может таки переименуешь?Они там есть, но в неочевидном месте, связанном с тем, что изначально он был только плагином к kfar, а теперь в основном является плагином.
Albom
Как только ты или кто-нибудь напишут компилятор Си++ (и прочего ЯВУ) под Колибри оно перестанет выпадать, а до этого это все пустые разговоры.хотя согласен, разработка на Си выпадает из концепции KOS.
По поводу переписывания на fasm - криптоалгоритмы всегда стараются писать на ассемблере, кроме того при написании на ассемблере начинаешь понимать суть самого алгоритма. Кроме того думаю поскольку основная система написана на fasm, вполне резонно сделать библиотеку доступной любой программе, и легкой для расширения\улучшения другими. Весь код под public domain выложу, чтобы не было проблем.
Постараюсь реализовать все необходмые криптоалгоритмы для будущей реализации ssh )
Часть кода уже есть, но выкладывать пока не буду - не люблю краснеть ))) Требуется время на "вылизывание".
Да, поскольку на ассемблере x86 начал писать совсем недавно, код может быть не оптимальным, но это лучше чем его отсутствие ))
P.S. сам шелл буду на си пилить и дальше.
P.P.S. для ускорения разработки md5 и aes взял из указанных мест, надеюсь никто не против (шапки с лицензиями сохраняться, только код поправлю)
Постараюсь реализовать все необходмые криптоалгоритмы для будущей реализации ssh )
Часть кода уже есть, но выкладывать пока не буду - не люблю краснеть ))) Требуется время на "вылизывание".
Да, поскольку на ассемблере x86 начал писать совсем недавно, код может быть не оптимальным, но это лучше чем его отсутствие ))
P.S. сам шелл буду на си пилить и дальше.
P.P.S. для ускорения разработки md5 и aes взял из указанных мест, надеюсь никто не против (шапки с лицензиями сохраняться, только код поправлю)
По скорости - возможно. По размеру - нет. Потому что сейчас разработчиков компиляторов интересует практически только скорость работы сгенерированного кода, оптимизация по размеру получается в основном как приложение в случаях, когда какие-то преобразования улучшают и скорость, и размер, а как самостоятельная задача оптимизация по размеру идёт по остаточному принципу. Особенно для gcc и g++ (у MS с этим заметно получше, icc не особо смотрел). Примеры: при компиляции одного и того же кода с одними и теми же опциями в gcc3 и gcc4 более новый компилятор генерирует код большего размера (проверял лично на Колибри-версиях dosbox и atikms); опция -fomit-frame-pointer имеет два состояния, выключенное (при этом оптимизация не применяется) и включённое (при этом оптимизация применяется ко всем функциям, даже если она раздувает размер функции - ведь скорость повышается за счёт отказа от пролога, а на размер кода разработчикам наплевать); g++ при определённых (достаточно распространённых) условиях тупо дублирует код конструктора, создавая две идентичные функции (одна из них никогда не вызывается, пенальти по скорости отсутствует, а на размер никто не смотрит).Albom wrote:компилятор Си выдаёт результирующие файлы не намного хуже ассемблерных (по размеру и скорости исполнения)
ага, особенно факторизацию и длинную арифметику ))XVilka wrote:...криптоалгоритмы всегда стараются писать на ассемблере
Посмотри FreeLIP вряти кто то согласится повторить это на ассемблере.
Ghost
Дык GMP же. Там длинная арифметика как таковая как раз на ассемблере (точнее, на ассемблерах для разных архитектур).
Дык GMP же. Там длинная арифметика как таковая как раз на ассемблере (точнее, на ассемблерах для разных архитектур).
An implementation of the DES encryption algorithm would also be much appreciated
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
Не отказался бы от кодера/декодера base64. Как жаль, что у меня сейчас нет свободного времени для Колибри!!!
diamond хм, не встречался раньше с этой библиотекой, посмотрел, действительно асм встаки, но они занимают процентов десять от всего кода )
Albom для чего тебе base64? Он же просто в реализации.
Albom для чего тебе base64? Он же просто в реализации.
да, base64 очень прост. кодер/декодер на Си - около 50 строк... может когда-нибудь и перепишу на асме...
Ghost
90% времени занимают 10% кода. В случае работы с большими числами это примитивные операции - собственно длинная арифметика, сложение/вычитание/умножение/деление, а прочие, опирающиеся на них (например, возведение в степень и алгоритмы факторизации), сами по себе уже не критичны ко времени исполнения, вот их и пишут на сях.
90% времени занимают 10% кода. В случае работы с большими числами это примитивные операции - собственно длинная арифметика, сложение/вычитание/умножение/деление, а прочие, опирающиеся на них (например, возведение в степень и алгоритмы факторизации), сами по себе уже не критичны ко времени исполнения, вот их и пишут на сях.
Ушёл к умным, знающим и культурным людям.
Who is online
Users browsing this forum: No registered users and 41 guests