| 1.1, PereresusNeVlezaetBuggy (ok), 22:01, 23/02/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 >Изменен порядок применение методов шифрования, начиная с текущей версии по умолчанию приоритетными методами являются AES CTR и переработанный "arcfour256". Приоритет выбора CBC метода понижен до минимума, так как он подвержен уязвимости, теоретически позволяющей перехватывать и изменять SSH трафик. Кроме того, в OpenSSH 5.2 изменено поведение сервера при обнаружении аномалий в CBC шифровании, что сводит на нет возможность проведения вышеупомянутых атак.
Следует отметить, что результатом этого изменения является фактически отмена использования аппаратных ускорителей шифрования, т.к. они поддерживают в основном CBC. Впрочем, они и так редкость, во всяком случае, в России. Подробнее: http://www.nabble.com/SSH-cipher-preference-change-(was:-Re:-CVS:-cvs.openbsd)-td21627217.html
| | |
| |
| 2.3, deskpot (?), 22:25, 23/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
С удовольствием почитал бы анализ, насколько эти «аппаратные ускорители шифрования» могут быть хоть сколько-то полезны в свете openssh на текущем железе (хоть в каких-то ситуациях, у меня это пока не bottleneck ни разу). Или в свете openvpn, это даже интереснее.
| | |
| |
| 3.4, PereresusNeVlezaetBuggy (ok), 22:51, 23/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>С удовольствием почитал бы анализ, насколько эти «аппаратные ускорители шифрования» могут быть
>хоть сколько-то полезны в свете openssh на текущем железе (хоть в
>каких-то ситуациях, у меня это пока не bottleneck ни разу). Или
>в свете openvpn, это даже интереснее.
Пример из гугля:
"Our evaluation shows that, despite its addition in the system as a device/service virtualization layer, the OCF is extremely efficient in utilizing cryptographic accelerator functionality, attaining 95% of the theoretical peak device performance. In another configuration, we were able to achieve a 3DES aggregate throughput of over 800 Mbps, by employing a multi-threaded application and load-balancing across multiple accelerators. Furthermore, use of hardware accelerators can remove contention for the CPU and thus improve overall system responsiveness and performance for unrelated tasks."
http://www.openbsd.org/papers/ocf.pdf
А так — прогуляйтесь на http://www.hardware-ciphers.com/ , ознакомьтесь со спеками и посчитайте для себя. Это не x86-процессоры последних поколений, производительность просчитать несложно (главное, не забывать учитывать шину, на которой чип сидит, и накладные расходы в виде ОС).
| | |
| |
| 4.5, deskpot (?), 23:00, 23/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
а в реальной ситуации? вот есть у меня сервер с openvpn. я туда поставлю железку — и, что, responsiveness для клиентов увеличится?
в теории список таких ситуаций крайне мал. а на практике ещё меньше.
подумайте об этом и у вас больше не будет вопросов по поводу непопулярности железных шифро-процессоров.
| | |
| |
| 5.6, PereresusNeVlezaetBuggy (ok), 23:40, 23/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>а в реальной ситуации? вот есть у меня сервер с openvpn. я
>туда поставлю железку — и, что, responsiveness для клиентов увеличится?
Может быть. А, может быть, и нет. Опять-таки, считать надо.
>в теории список таких ситуаций крайне мал. а на практике ещё меньше.
>
>
>подумайте об этом и у вас больше не будет вопросов по поводу
>непопулярности железных шифро-процессоров.
А у меня как-то вопросов и не было, это вы спрашивали. ;)
| | |
| |
| 6.8, deskpot (?), 23:47, 23/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Может быть. А, может быть, и нет. Опять-таки, считать надо.
вот я именно хоть сколько-то нормальных замеров и просил два сообщения назад. :-)
> А у меня как-то вопросов и не было, это вы спрашивали. ;)
нет, я благодарен за замечание про крипто-акселлераторы. но я как бы намекаю на то, что потеря невелика.
| | |
| |
| 7.11, PereresusNeVlezaetBuggy (ok), 00:34, 24/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Может быть. А, может быть, и нет. Опять-таки, считать надо.
>
>вот я именно хоть сколько-то нормальных замеров и просил два сообщения назад.
>:-)
Замер я привёл, ну а конкретно это всё равно надо считать. Вообще тенденция судить о чём-то по бенчмаркам, которые делаются в отличных от ваших условиях, ИМХО, череповато. Можно ту или иную степень достоверности им присваивать "для себя", но не более. Повторяю, посчитать несложно. От себя скажу, что если у вас криптотраффик составляет заметную часть загрузки системы, то результат будет заметен. Я встречал цифры порядка 6-8 кратного ускорения шифрования-дешифрования, но насколько это поможет в конкретной конфигурации — никто, кроме вас самого, не скажет. А так можно заявить, как некоторые фряшники, о десятикратном приросте обработки пакетов в 7.0, забывая о том, что это относится лишь к определённой части сетевого стека. :)
Я бы сказал так: если у вас машина занимается в основном OpenVPN (читай, OpenSSL) и SSH, то нагрузка снизится раза в два-три. Заметно дешевле нового сервера, ИМХО. А если эта прибавка идёт ещё и бесплатно, скажем, вместе с процессором (Via C3), то вообще жить хорошо и замечательно. Пока не утыкаемся в обсуждённые выше проблемы с CBC. :)
>> А у меня как-то вопросов и не было, это вы спрашивали. ;)
>
>нет, я благодарен за замечание про крипто-акселлераторы. но я как бы намекаю
>на то, что потеря невелика.
В большинстве случаев — да.
| | |
| |
| 8.14, crick (ok), 13:13, 24/02/2009 [^] [^^] [^^^] [ответить] | +/– | В чем проблема Включаем в настройках и радуемся Разработчики ведь не закрыли... текст свёрнут, показать | | |
|
| 7.13, User294 (ok), 03:45, 24/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>на то, что потеря невелика.
А это смотря что делать.Представьте себе проксирование или vpn порядка гигабита по ssh например.Вы все еще уверены что это ерунда?А если гигабитных интерфейсов несколько а сервак, допустим, юзает орава народа (VDS там и так далее).Вообще, ssh особой скромностью в плане юзежа проца при большоем траффике не отличается.Подозреваю что за счет шифрования как раз.А случаи бывают разные.
P.S. arcfour'у довольно много досталось от криптографов и нафиг его (даже переработанный) делать приоритетным - не очень понятно.Или их переработка устраняет все известные проблемы и надежность оного проверена криптографами?
| | |
|
|
| 5.7, PereresusNeVlezaetBuggy (ok), 23:43, 23/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>непопулярности железных шифро-процессоров.
Кстати, некоторые виды оборудования (например, репитеры для оптоволокна) трудно назвать шибко популярными, но тем не менее в определённых, пусть и узких сферах, они активно используются и вопросы их использования, соответственно, весьма актуальны. ;)
| | |
| |
| 6.9, deskpot (?), 23:49, 23/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> репитеры для оптоволокна
кстати, насколько для них актуален вопрос отмены ряда крипто-железок для openssh? правильно — нинасколько вообще.
| | |
| |
| 7.10, PereresusNeVlezaetBuggy (ok), 00:24, 24/02/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> репитеры для оптоволокна
>
>кстати, насколько для них актуален вопрос отмены ряда крипто-железок для openssh? правильно
>— нинасколько вообще.
Угу. Это был абстрактный пример. Лопата ;)
| | |
|
|
| 5.12, User294 (ok), 03:38, 24/02/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>туда поставлю железку — и, что, responsiveness для клиентов увеличится?
Больше ресурсов проца другим достанется.А вы думаете, шифровать, например, гигабит - это ерунда?Черта с два, проц пригрузится как делать нефиг.Если в него вообще не упрется все.
| | |
|
|
|
|
| 1.16, 2deskpot (?), 15:37, 24/02/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Нужны числа?
Начните качать с сайта большой файл на хорошей скорости (скажем, 100 мегабит) по https.
И смотрите загрузку проца в это время.
Если вам не нравится такая загрузка, то вам может помочь аппаратные решения.
Особенно, если скорость канала в интернет данного сервера куда больше скорости, на которой качался файл.
Можно обосновать математически:
Имеем уравнение:
(ширина канала)/(скорость закачки) = 100%/(загрузка проца одной такой закачкой)
Если правая и левая части уровнения равны, значит ваша система справится с шифрованием всего трафика.
Если правая часть меньше, значит не справится.
Пример:
ширина канала = 1000Mb/s
скорость закачки = 100Mb/s
100% = 100%
загрузка одной закачкой = 10%
1000/100 = 100%/10% - проц справляется (правда при 1Gbps будет загружен на 100%)
Другой пример:
загрузка одной закачкой = 20
1000/100 = 100/20 - проц сможет осилить только половину скорости канала (если весь трафик будет шифроваться)
Ну и т.д.
Вывод:
В каждом случае будет свой ответ на вопрос "а нужна ли железяка?".
| | |
|
