Шифрование, хеши и архивация - что нужно в библиотеке?

Discussing libraries simplifying applications development
  • В archiver.obj есть реализация SHA256 и AES, правда, наружу они не торчат.
    Процедуры для RSA писал halyavin, они есть в cpuid (где используются для тестов скорости).
    Реализация MD5 тоже есть (svn://kolibrios.org/programs/develop/examples/md5/trunk/md5.asm), правда, код там мог бы быть и получше.
    Ушёл к умным, знающим и культурным людям.
  • А где исходники этого archiver.obj? В svn я что-то не нашел...
    Ксати такой вопрос как оптимально сложить числа больше чем 32бита?
    кстати RC6 - это не AES, так что тоже теперь почти есть.
    Ну md5 - уже ушел в прошлое, а вот sha1 надо написать для совместимости
  • XVilka wrote:А где исходники этого archiver.obj? В svn я что-то не нашел...
    Они там есть, но в неочевидном месте, связанном с тем, что изначально он был только плагином к kfar, а теперь в основном является плагином. svn://kolibrios.org/programs/fs/kfar/kfar_arc/.
    XVilka wrote:Ксати такой вопрос как оптимально сложить числа больше чем 32бита?
    64-битное сложение edx:eax += ebx:ecx:

    Code: Select all

    add eax,ecx
    adc edx,ebx
    
    Ушёл к умным, знающим и культурным людям.
  • XVilka
    кстати, с точки пользователя - программы и библиотеки на fasm переписывать не обязательно. компилятор Си выдаёт результирующие файлы не намного хуже ассемблерных (по размеру и скорости исполнения), зато скорость разработки существенно повышается. хотя согласен, разработка на Си выпадает из концепции KOS.
  • XVilka
    Пока написал и довожу до ума SHA256, CRC32, RC6.
    В очереди стоит LZMA как архивация.
    Весьма нужная вещь. Успехов в реализации!

    diamond
    Они там есть, но в неочевидном месте, связанном с тем, что изначально он был только плагином к kfar, а теперь в основном является плагином.
    Ну, вот уже как минимум 2 человека. Может таки переименуешь? :mrgreen:

    Albom
    хотя согласен, разработка на Си выпадает из концепции KOS.
    Как только ты или кто-нибудь напишут компилятор Си++ (и прочего ЯВУ) под Колибри оно перестанет выпадать, а до этого это все пустые разговоры.
  • По поводу переписывания на fasm - криптоалгоритмы всегда стараются писать на ассемблере, кроме того при написании на ассемблере начинаешь понимать суть самого алгоритма. Кроме того думаю поскольку основная система написана на fasm, вполне резонно сделать библиотеку доступной любой программе, и легкой для расширения\улучшения другими. Весь код под public domain выложу, чтобы не было проблем.
    Постараюсь реализовать все необходмые криптоалгоритмы для будущей реализации ssh )
    Часть кода уже есть, но выкладывать пока не буду - не люблю краснеть ))) Требуется время на "вылизывание".

    Да, поскольку на ассемблере x86 начал писать совсем недавно, код может быть не оптимальным, но это лучше чем его отсутствие ))

    P.S. сам шелл буду на си пилить и дальше.
    P.P.S. для ускорения разработки md5 и aes взял из указанных мест, надеюсь никто не против (шапки с лицензиями сохраняться, только код поправлю)
  • Albom wrote:компилятор Си выдаёт результирующие файлы не намного хуже ассемблерных (по размеру и скорости исполнения)
    По скорости - возможно. По размеру - нет. Потому что сейчас разработчиков компиляторов интересует практически только скорость работы сгенерированного кода, оптимизация по размеру получается в основном как приложение в случаях, когда какие-то преобразования улучшают и скорость, и размер, а как самостоятельная задача оптимизация по размеру идёт по остаточному принципу. Особенно для gcc и g++ (у MS с этим заметно получше, icc не особо смотрел). Примеры: при компиляции одного и того же кода с одними и теми же опциями в gcc3 и gcc4 более новый компилятор генерирует код большего размера (проверял лично на Колибри-версиях dosbox и atikms); опция -fomit-frame-pointer имеет два состояния, выключенное (при этом оптимизация не применяется) и включённое (при этом оптимизация применяется ко всем функциям, даже если она раздувает размер функции - ведь скорость повышается за счёт отказа от пролога, а на размер кода разработчикам наплевать); g++ при определённых (достаточно распространённых) условиях тупо дублирует код конструктора, создавая две идентичные функции (одна из них никогда не вызывается, пенальти по скорости отсутствует, а на размер никто не смотрит).
  • XVilka wrote:...криптоалгоритмы всегда стараются писать на ассемблере
    ага, особенно факторизацию и длинную арифметику ))
    Посмотри FreeLIP вряти кто то согласится повторить это на ассемблере.
  • Ghost
    Дык 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? Он же просто в реализации.
  • да, base64 очень прост. кодер/декодер на Си - около 50 строк... может когда-нибудь и перепишу на асме...
  • Ghost
    90% времени занимают 10% кода. В случае работы с большими числами это примитивные операции - собственно длинная арифметика, сложение/вычитание/умножение/деление, а прочие, опирающиеся на них (например, возведение в степень и алгоритмы факторизации), сами по себе уже не критичны ко времени исполнения, вот их и пишут на сях.
    Ушёл к умным, знающим и культурным людям.
  • Who is online

    Users browsing this forum: No registered users and 6 guests