В современных процах есть много новых векторных команд типа MMX SSE4 AVX. Почему не разработанны криптоалгоритмы заточенные под эффективное использование данной архитектуры ? А наоборот в проц ввели апаратную поддержку AES ? Ведь на том же SSE4 AVX можно реализовывать быстрое блочное шифрование по 128 бит до 256 бит (регистры YMM0 — YMM15).
Аппаратная реализация все равно будет быстрее программной, в не зависимости от того, какую программную реализацию ты сделал. Ну так реализуй и сравни с аппаратной по скорости.
Rel, На процессоре общего назначения эти вычисления врядле будут быстрее софт реализации, так как большую часть тайминга занимают проверки безопасности, выборки в память(трансляции) и прочие нужды(сам же вычисляющий хард блок весит наверно несколько процентов от общего тайминга. Поэтому эти вычисления проводят на гпу/асик, простом спец железе. Так что думаю грамотной математикой можно и хард импл обойти по профайлу.
У меня версия что алгоритмы разрабатывают без оглядки на архитектуру потому что они могут быть реализованны на разных архитектурах. Воответственно если они будут заточенны под одну то будут тормозить на другой .....
asmlamo, для надёжной криптографии и простой ксор катит == главное убрать избыточность из файла, что вполне разрешимо чрез сжатие.
Палка-то о двух концах: ультра-оптимизированность алгоритма будет минусом к его стойкости. Когда-то очень давно читал Брюса Шнаера (автор blowfish), он вообще утверждает, что вся эта криптоаналитическая отрасль живет своими суевериями, нельзя просто так туда сунуться со своим суперстойким алгоритмом и сразу получить признание.
нужны не псевдо, а случайные и сжатие их вполне даёт. как-то общался с этим субъектом. он мне честно признался, что разработка реально криптостойких -- это преступление, но в своих книжечках он такую крамолу не поминает.
БЛИН! Я ТАК И ЗНАЛ! СПАСИБО --- Сообщение объединено, 21 май 2020 --- не прокатит. заголовки одинаковые, чем ближе к началу, тем больше одинаковости и при сжатии. ксорим два крытых текста и получаем часть ключа. --- Сообщение объединено, 21 май 2020 --- т.е. в теории да, избыточность корень зол, а на практике нет
Сталкивался. Сильно тебе помогут 10 байт gzip-заголовка, когда зашифровано гаммированоием (по сути ксор на функцию чего-нибудь) и длина последовательности измеряется килобайтами? Опять же можно привязать начальный индекс к чему-нибудь (да хоть к рандом сиду, добавляемому в начало зашифрованных данных) и заголовки совпадать перестанут. И в качестве троллинга округлять размер буфера на степень двойки бит, чтобы казалось, что это rsa.
f13nd, гаммирование и заксорить архивы пусть и с килобайтами но повторно используемых значений - это сильно разные вещи. При толковом гаммировании архивация и так не нужна, а без него -> индекс совпадений - узнали длину ключа. 80 бит уже есть. Дальше путем мутаций условно 11-го байта и с помощью тервера угадываем что там было. В таких делах как с инжектами - всё решает конкретика.
Накладываемая гамма это именно поток от псевдослучайного генератора. То есть на вход генератора приходит пароль на основе которого начинают генерить псевдослучайную гамму. А по энтропии данных это отдельный вопрос.
q2e74, В таких делах как всегда - если хоть раз пароль потёк, то дальнейшая защита смысла не имеет вместе со всей эльфийской гаммой, всё тупо копируется и никого не парит что энтропия не сошлась
много данных уже пожаты == файл с малым процентом избыточности и есть дешёвый да надёжный источник энтропии.
