Исходное сообщение
"Язык программирования Go переходит с Mercurial на Git и GitH..." Отправлено Аноним, 15-Ноя-14 06:11
> Ручное управление памятью, все дела. Зато быстро. Сдуру можно и х... сломать. И root cause тут не сишечка, а 1) Переусложненный протокол с кучей легаси и костылей. * Для начала, фича просить у ремоты энное количество байтов - не должна была существовать, даже в проекте. Ну и багов в ней - соответственно, быть не должно. * А вон тут соседняя атака - с буферами ничего не делает вообще. MITM просто даунгрейдит протокол с TLS'а до SSLv3 и потом радостно вскрывает древний и слабый вариант протокола. И ничего вы с этим отказом от управления памятью не сделаете. 2) Как известно, сдуру можно и х... сломать и в криптографии автоматическое управление памятью - последнее что может помочь криптографу. Ключи должны изничтожаться предсказуемо, etc. Без этого будет много неочевидных ламоватым кидизам но от того не менее опасных в плане утечки ключей дыр. Ключ должен существовать ровно столько сколько он требуется и на этом пути GC с отложенной сборкой может очень сильно нагадить. И вообще, идея использовать криптографическую либу от тех кто не может даже памятью управлять - очень сомнительна. А сколько там тогда багов в алгоритмах криптографии и обвязке? 3) У OpenSSL дурное апи и дурной код. Ее авторы вообще не криптографы. Поэтому не так уж принципиально какой ЯП они возьмут. Сильно безопаснее не станет. Наворачивание хитрозадых конструкций на сях лишь немного дополняет эту картину. И не более того. А вовсе и не перекраивает весь ландшафт.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Ручное управление памятью, все дела. Зато быстро. > Сдуру можно и х... сломать. И root cause тут не сишечка, а > 1) Переусложненный протокол с кучей легаси и костылей. > * Для начала, фича просить у ремоты энное количество байтов - не > должна была существовать, даже в проекте. Ну и багов в ней > - соответственно, быть не должно. > * А вон тут соседняя атака - с буферами ничего не делает > вообще. MITM просто даунгрейдит протокол с TLS'а до SSLv3 и потом > радостно вскрывает древний и слабый вариант протокола. И ничего вы с > этим отказом от управления памятью не сделаете. > 2) Как известно, сдуру можно и х... сломать и в криптографии автоматическое > управление памятью - последнее что может помочь криптографу. Ключи должны изничтожаться > предсказуемо, etc. Без этого будет много неочевидных ламоватым кидизам но от > того не менее опасных в плане утечки ключей дыр. Ключ должен > существовать ровно столько сколько он требуется и на этом пути GC > с отложенной сборкой может очень сильно нагадить. И вообще, идея использовать > криптографическую либу от тех кто не может даже памятью управлять - > очень сомнительна. А сколько там тогда багов в алгоритмах криптографии и > обвязке? > 3) У OpenSSL дурное апи и дурной код. Ее авторы вообще не > криптографы. Поэтому не так уж принципиально какой ЯП они возьмут. Сильно > безопаснее не станет. Наворачивание хитрозадых конструкций на сях лишь немного дополняет > эту картину. И не более того. А вовсе и не перекраивает > весь ландшафт.
	Введите код, изображенный на картинке: