А твой расшифровывающий проц тут ни при чём, для него это не проблема, а вот для сервака норм такая нагрузка, кмк

для сервака норм такая нагрузка, кмк

Это да.

А твой расшифровывающий проц тут ни при чём, для него это не проблема, а вот для сервака норм такая нагрузка, кмк

man симметричный шифр

Современные процы умеют делать AES чуть ли не на скорости оперативной памяти.

Умоляю Вас! =)))

Современные процы умеют делать AES чуть ли не на скорости оперативной памяти.

Только не говорите им что современные процы (что для Intel-совместимых архитектур, что для ряда ARM например вот) уже и сразу имеют набор инструкций AES-NI, прямо в проце. Никаких софтовых либ в принципе и не нужно в большинстве случаев.

man симметричный шифр

Да, в этом случае нагрузка с гулькин х… «член», в общем. А блочному шифру вообще пофиг чё «жевать» – хоть сетевой трафик, хоть данные на диске.

Вот с «Кузнечиком» или «Магмой» или ГОСТом проблемы будут. Но вовсе не потому, что это блочные шифры. Реализаций в проце нетути и не предвидится. Да и «Кузнечик» это отдельная тема – либо по кешу, либо по шине но просрёте. Но в случае с AES это роли не играет.

современные процы (что для Intel-совместимых архитектур, что для ряда ARM например вот) уже и сразу имеют набор инструкций AES-NI, прямо в проце

Ну я об этом и говорю.

Да.

Извините что вмешался, я просто немного уточнил. А то народ тут думает по простоте душевной что крипта целиком и полностью их проц захавает и ещё добавки попросит. =)

Современные ОС умеют в sendfile, а с шифрованием оно не работает.

И что, даст твой процессор 10 гигабитов шифрования? Сеть даст.

Вы это серьёзно? =)))

А в «сети» оно откуда возьмётся? Ветром надует или от сырости заведётся? =)))

Ну есть у меня реализации и по 40G крипты дают и чё дальше? Вот только там… Немного не «просто Linux», ессичё. Но да, на базе.

Денег я себе этим зарабатываю. На свой достаточно высокий уровень жизни. =))) Поэтому и в курсе откуда это шифрование в «сети» берётся. И не только у Cisco или Juniper. =)))

Современные процы умеют делать AES чуть ли не на скорости оперативной памяти.

Ой, правда? В таком случае бегу майнить битки.

А в «сети» оно откуда возьмётся? Ветром надует или от сырости заведётся? =)))

Кто откуда возьмётся? 10 гигабитов? Оно же сейчас у любого школьника в локалочке.

Ну да...

Кто-же энтиму школию код-то пишет, которым они на своих девайсах пользуются? Вот крипта как раз, это одна из моих «полянок» и есть.

Только одна оговорочка – как правило, нормальной крипты в «домовых сетях» можно не искать (она и «бизнеса» не всегда есть, т.к. всё то же школие вырастает и становится одминами-девляпсами). Тут, в массе своей такое творится, что хоть стой, хоть падай. В общем, это отдельная и довольно нудная тема. По сути (если для простоты), то можно считать что в массе своей конечный потребитель про крипту знает только одно – что она есть. Где-то. Наверное. Исключения редки и только подтверждают правило.

Ты случайно AES со SHA не путаешь?

(путаешь, разумеется. Хотя SHA extensions тоже существуют, но тебе это особо не поможет.)

Нет, не путаю, а ты не путаешь? Ты говоришь что

Современные процы умеют делать AES чуть ли не на скорости оперативной памяти.

Со скоростью оперативки всё понятно, но в чём ты измеряешь скорость «деланья AES». Старый добрый майнинг на алгоритме sha256 с aes-ni ну как минимум в 10 раз медленнее опертивки если пересчитать хэшрейт как пропускную способность оперативки. Пояснишь о чём ты? И как у тебя получается скорость почти как у оперативки?

Повторюсь ещё раз, что сервам похрен какой у тебя там быстрый проц, https ответ всегда медленнее http, можешь сам чекнуть

в https на хендшейк время тратися

проц в 10-20раз быстрее https://static.techspot.com/articles-info/2135/bench/AES-o.png

И "да" и "нет".

https ответ всегда медленнее http, можешь сам чекнуть

https (как протокол) ни чем не отличается от http. Те же сущности – методы, URI, вот это вот всё. Но проблема заключается в том, что это протокол транспортного уровня, т.е. не имеющий никаких защит (аутентификация не в счёт, она не закрывает сам по себе канал связи) на уровне самого по себе протокола. Как только мы внедряем закрытие канала, т.е., прикручиваем сверху шифрацию-дешифрацию, мы получаем замедление на обработке каждого пакета, на установлении соединения («рукопожатие») и т.д. и т.п. Ведь по сути, https это http + ssl.

Вот поэтому он и медленнее. Если посчитать по скорости криптопреобразований локально, то картина будет не столь удручающа, если мы не перегоняем файл по сети, а просто шифруем его локально. Плюс, какой алгоритм ещё выбрать (и как он реализован – с поддержкой процом или чисто софтово).

Дальше вопрос какой алгоритм мы пытаемся использовать. Они не все одинаковы по криптостойкости и скорости работы. Например, можно посмотреть что именно у Вас на проце будет твориться командой openssl speed или openssl speed -multi число_ядер_проца. И оттуда уже выбрать нужный алгоритм для конкретной реализации. Кстати, для https-серверов так и делают. Подбирают.

Так что, здесь есть вопросы, которые требуют ответа и нельзя сразу и влёт сказать что именно вот такой вот алгоритм будет лучше всего. По какому из критериев подбираем?

Нет, не путаю

Да, путаешь.

Старый добрый майнинг на алгоритме sha256 с aes-ni

Каким образом у тебя SHA256 связано с AES-NI?

Повторюсь ещё раз, что сервам похрен какой у тебя там быстрый проц, https ответ всегда медленнее http, можешь сам чекнуть

Повторюсь ещё раз вслед за десятком высказавшихся выше — https медленнее http за счёт хендшейка.

https ответ всегда медленнее http

Попробовал скачивать по приведённой тобой ссылке на Contents-s390x.gz много раз по http и https. Результаты получились в диапазоне от 5 до 11 секунд, что для http, что для https. Медиана — в районе 7 секунд. При желании можно выбрать пары результатов так, чтобы показать любое соотношение. Что https в два раза быстрее http, что http быстрее https в те же два раза.

вот этот как обычно шарит