The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Настройка SSH для использования только заслуживающих доверия..."
Отправлено stargrave, 19-Янв-15 19:51 
В общем у вас полная убеждённость что из-за сложности TLS нет возможности его и ревьювить — не согласен с этим. У вас полная убеждённость что атаки которые на деле крайне сложно использовать вовсю будут применены и сразу же технологии можно закапывать. На факт что SSH не делает ETM и что можно 4 байта plaintext-а у него тырить: вы закрываете глаза, ведь практическую атаку не так же просто сделать. А что данные можно тырить черезе side channel кэша -- на практике конечно же безусловно, по вашему, гораздо легче применить. RSA видители не имеет много криптоанализа, Шамиры и прочие видители куда менее доверяемые люди чем Бернштейн (хотя не Шамиры принимают политические решения о той же рекоммендации Dual). То что downgrade атаку не провести если чётко прибиты гвоздями используемые режимы -- вы игнорируете. По вашему легче изобретать и изобретать каждый год велосипеды простые: с одной стороны надо бы сделать что-то простое и ясное, но как-то вот не выходит у людей нисколько. Потому-что все считают что у них выйдет лучше, тогда как другим достаточно допилить/донастроить TLS/IPsec и они вполне себе будут работать. Но конечно: Blowfish и AES морально устарели и каждая АНБ легко может использовать side channel, ну ну. И оказывается ваша ОС очень усложняет жизнь по доступу к памяти другого процесса, хотя почти все атаки как бы заключаются в этом на практике, на деле. В теории AES side channel можно использовать, так же как и в теории ОС должна обеспечивать хорошую защиту памяти — вот только всё наоборот. Бернштейн наше всё, а Тео Де Раадт видители ничего не смыслит. Шнайер видимо лысый потому-что ужаснулся использованию S-box-ов и ринулся переделывать это в Threefish. Ваше право конечно же так думать, но векторы атаки как-то совсем не такие на деле будут: надёжность безопасности ОС априори как правило куда хуже чем кому-то в голову придёт возиться с атакой на S-box. AES оказывается можно сделат безопасным против cache side channel атак, я рад что признали, а вопрос скорости не встанет когда нужна безопасность основанная на тьме криптоанализов, не то что у salsa20.

>Не буду настаивать что это лучшая софтина на свете. И доверять особо не буду, т.к. как
>верно замечено что авторы не производят впечатления компетентных в вопросе людей. Но я не
>думаю что они смогут переплюнуть вышеупомянутое.

Ну, ваше право так думать конечно. По моему OpenSSL не так уж и плох, а CryptoCat это какие-то школьники которые в принципе лучше бы не брались за криптографию.

>EPIC!!!

Да уж, что не уязвимость, то у вас epic, как я погляжу. А то что SSHv2 не использует ETM, то говорит что они даже книжек не читали по крипто. Хотя! на то время это простительно, так как эта тема ещё не так хорошо изучена.

Сложность протоколов это безусловно беда. Но я уже показал выше что даже тупо передавать VPN трафик это уже нужен протокол, в котором будут точно такие же баги и ошибки которые возникали везде кто это писал с нуля. Просто факт. И никто не занимается толком атакой на низкоуровневые примитивы, так как всё гораздо проще бывает.

>>SSHv2 без -etm, cryptocat.
>Они смогли фатально облажаться на уровне heartbleed, так чтобы через это хакеры разнесли
>целые энтерпрайзы?

Никто не знает в относительных величинах как навредил SSH и как навредил heartbleed. Heartbleed не во всех библиотеках проявился, а в абсолютных числах TLS куда больше SSH используется. Никто не скажет правду о том как где-то крупно-крупно была беда из-за утечки данных по SSH, так как если речь о госах или банках — этого никто не скажет.

>Ну вот видите, я ему могу кое-что предъявить даже при том что я в общем то не криптограф.
>В том плане что я понимаю что моей квалификации недостаточно для конструирования
>"кульного алгоритма шифрования".

Все могут что-то предъявить, вот только на деле использовать как-то не очень получается, даже против морально всего такого устаревшего Blowfish.

>А с чего вдруг авторам алгоритма такое безоговорочное доверие при сомнительных делишках
>основанной ими компании?

Не вижу с какой стати математики, пускай и основавшие компанию, мешаются с политикой, где никто не говорил что они принимают решения. Да и опять же все люди: у всех есть цена. Бернштейн запросто уже давно куплен АНБ, почему нет? Ну и то что допустим даже они и сейчас стали продажными -- не означает что они всегда такими были. RSA очень хорошо изученный алгоритм.

>Он какой-то скромный академик, сделавший 25519, salsa, chacha и прочее довольно давно, не
>пиарившись и не создавая корпорации на тот момент. И не продавливаемый в стандарты.

Ага, прям идеал чтобы его подсадить и ни в чём не заподозрить. В тихом омуте черти водятся.

>Я предпочитаю открытые исходники в том числе и потому что разные люди могут посмотреть на
>это и независимо друг от друга высказать мнения. Если мнения специалистов хорошо
>согласуются между собой - значит, истина скорее всего где-то рядом. А если мнения
>существенно разнятся - это может быть индикатором спорной схемы, подкупленности или
>недобросовестности части участников, ну и так далее.

Чую что я подобное как-то говорил по поводу ревью уже ☺. Не работает это.

>1) Он сам по себе шлет идентити юзера влобешник. Отлично, гудбай приваси. Всему миру
>видно что на сервак в хренадцать часов логинился именно Вася.

Не стоит мешать разные задачи в одну кучу. Если до конца не решена задача ZK, аутентификации и конфиденциальности: то об анонимности рано ещё думать. Если она нужна, то никто не мешает сделать обычный DH, а дальше гонять данные по симметричному каналу.

>1.1) Конечно там что-то про TLS, но что я думаю о этом выводке протоколов и куда ему
>пойти - вы в курсе, да?

SRP и TLS? Я слышал что SRP встроили в TLS недавно. Разрабатывался он как-то вообще не соприкасаясь с TLS. Ах да, если коснулся TLS, то видимо всё: epic fail.

>2) Оно почему-то переклинено на клиентсерверной модели и потому однобокое. Вообще-то, по
>идее хотелось бы верификацию *обоих* участников линка друг другом, НО чтобы остальным не
>было видно какие идентити представили друг другу эти участники.

В качестве identity можно легко использовать CHAP-based протокол, Skey или что-то подобное. Это уж не хитрое дело и второстепенное. Просто не надо мешать совершенно задачи в одну кучу. Не везде нужна анонимность.

>Субъективно - такое можно сделать хоть из DJBшного
>криптобокса.

Можно, но у SRP есть удобные преимущества которые могут оказаться решающими. Как например то что он не использует как таковые протоколы шифрования.

>Перекидывая минимум пакетов и храня минимум информации. И симметрично.

Именно это я и сделал в GoVPN в виде DH-EKE.

>>Вот например в языке Go соорудили собственную TLS библиотеку с нуля.
>Я их с этим поздравляю. Языку для хипстеров и секурити под стать.

Ну вот вы не видели и не знаете какого уровня там люди, а сразу судите. Одни сплошные стереотипы и epic fail-ы по каждому щелчку.

>Так что они годятся для дежурного сокрытия просмотра порева от
>корпоративного админа как самый максимум. А так они не для требовательных применений, имхо.

Мда, дожили, чтобы делать так сложно обфускацию траффика.

>Их нельзя использовать хотя-бы из-за тайминг атак, потому что когда ключи может
>выколупать любой кто на том же проце пристроился - это безобразие и отрыв от реалий.

Ну ну. А GOST поломан до 2**178: epic fail, использовать нельзя!

>>до сих пор те же HMAC-MD5, в отличии от MD5 можно [..]
>Можно даже бегать в ластах и противогазе по снегу вместо того чтобы взять лыжи. Но зачем?

Если не известно насколько лыжи хороши для снега, то ради того чтобы выжить, а не рисковать непроверенной технологией.

>В обозримом будущем 128 битов и более - должно хватить. Даже с учетом Мура, 2^128 -
>довольно много.

Ага, пока не найдут атаку снижающую brute force взлом на несколько порядков. А был бы 256bit, то запаса как у ГОСТа вон был бы! Вопрос о том сколько нужно хранить секрет: если это SSH с какими-то командочками, то это уже не интересно через несколько лет будет запросто. А вот для гостайн не пойдёт. Поэтому и говорю что у Бернштейна наверное поэтому и не исследуют так много его алгоритмы потому-что запаса в них никакого. Всё мол ради скорости.

>А почему тогда в DNSSEC смеют использовать 1024-битные ключи и впаривать сие?

Потому-что DNSSEC это DNSSEC: свой какой-то протокол. 1k ключи -- политика и компромисс между скоростью и безопасностью (от 15 лет кракеров спасёт — уже хорошо), порог вхождения для подмены записей достаточный чтобы отсеять 99.99% атак. Это не уберрешение, которое не нужно простым людям. А не простые и так аутентифицируют сервисы заранее вбивая их данные.

>Осталось найти тех кто реально пользовался бы 4096 битными ключами RSA.

Ключей таких размеров тьма. Например у Шнайера, у Столлмана с ходу вспоминаю.

>Смотря что понимать под запасом. Если мы рассматриваем взлом 128 бит - это наверное про
>квантовые компьютеры. А в этом случае есть мнения что для публичной криптографии которая
>устоит даже против них - надо смотреть на иную математику, где есть уверенность что
>специфичные свойства квантовых компьютеров не приведут к серьезному повышению
>эффективности взлома. Если эти упрощения получатся, RSA при этом завалится не лучше и не
>хуже эллиптических кривых, насколько я понимаю мнения криптографов. Симметричные шифры -
>где как, но сам по себе лобовой перебор 256 битов - не получится вообще совсем никак.
>Энергии не хватит на обсчет, чисто технически.

Вы плохо понимаете криптографов. Считается что квантовые компьютеры могут максимум: сбить в два раза длину ключа (был 128 бит, стал для brute force фактически 64). Для эллиптических: вообще не доказано что вся безопасность их сводится к проблеме поиска коэффициентов кривых. Не исключено что найдут реальный epic fail делающий их игрушкой бесполезной. У RSA/ElGamal если 2k ключ считается равным 128 бит симметричному, то опять же 2k ключ равносилен как бы будет 2**64, тогда как у ECC не доказано что они безопасны в принципе.

>По логике вещей, если бы был связан и там было бы что-то не так - его схемы внедряли бы
>намного раньше, нахраписто продвигали бы в стандарты и заваливали деньгами на успешные
>стартапы и масс-впаривание. Уж NIST наверняка смотрел бы не на какие-то свои кривые, а
>первым делом и схапал бы 25519, бонусом к dual EC. Вот только почему-то к Dual EC
>предъявы были, а 25519 с нами уже не первый год, но ничего такого этой кривой не предъявили.

Хм, вы считаете госструктуры полными дураками не разбирающимися в психологии? Всем очевидно что если активно что-то проталкивают, значит дело запросто не чисто. В итоге чего проще протолкнуть то, что ещё на своих сайтах показывает недостатки официально выбранных алгоритмов/кривых? Конечно для отвлечени внимания делаем говно, его Бернштейн поливает, он круче всех, хотя госы уже давно со своими математиками ржут над его решениями и радуются что их везде впихивают.

>Теории заговора это круто, но если в способность АНБ платить крутым спецам
>конкурентоспособные зарплаты и создать не слишком дискомфортную рабочую атмосферу я еще
>со скрипом поверю, то способность ФСБ делать это вызывает определенные сомнения.

У вас есть сомнения -- у меня нет, не скажу откуда.

>Ну и если так посмотреть - наука как-то сильнее всего продвинулась публично. Да-да, даже
>описание конструкции атомной бомбы найти не проблема. И термоядерной. Проблема в основном
>с ингредиентами, которые на дороге не валяются и в подвале тихой сапой не получаются. А
>огроменный завод - штука заметная, как ни крути. Утверждается что для математики это иначе?

Атомные бомбы известно в теории как делать, верно. Вот только технологий хватает на это у считанного кол-ва стран. Математика… математиков заприметят гораздо раньше и возьмут под контроль чем он успеет ляпнуть что-то лишнее. Инструменты в виде компьютеров и Интернета у нас есть, вот только люди остаются людьми.

>Ну да, а то что табличная сущность утекает состояние алгоритма наружу мы будем
>игнорировать? Пока не долбанет в лоб на уровне heartbleed, да?

Много кого долбануло? Ну ну.

>А для меня нежелание криптографов использовать схемы с таблицами - аргумент.

Я у того же Шнайера не видел нигде "нежелание". Есть "если можно, то попробуем сделать без этого", а не нежелание.

>Если честно - по моему нескромному мнению ssh давно пора переделать. По итогам грабель. И
>снеся совметимость с старьем. Сделав padding, убив все граблеопасные алгоритмы и кучу
>легаси барахла. А личное пожелание - вытряхнуть оттуда все кроме секурного шелла. А
>остальное - оформить либу и отдельные программы, на основе той же технологии, но - именно
>отдельные. А не макаронный монстр который и поганый впн и инопланетный портфорвардер и
>горбатая файлокачалка и что там еще.

Да, в целом это неплохая идея. Вот только опять же это будет нечто чем-то хорошее, а чем-то совершенно не удовлетворительное. Padding лично мне много где не то что не сдался: а не нужен из-за трафика, который стоит денег. Плюс какие вы алгоритмы оставите? Опять купленного властями Бернштейна и всё? А если я для Рф хочу сделать железку, то для этого надо ГОСТ, который медленный, но в железке вполне себе безопасный будет. Но у вас же его не будет? У вас из-за DJB не будет запаса по прочности. В общем… на любителя. Таких поделий сделано куча и уже давно.

>Я как минимум вижу что Шнайер и еще кучка криптографов вместе надизайнили Threefish. И он
>сделан вполне в духе остальной криптографии - регистровая математика и никаких таблиц.

Да, сделали так. Потому-что вроде как лучше, а не потому-что прошлый вариант был в плане безопасности сильно хуже.

>Зато twofish с его s-box - хорошая заявка на грабли по линии кэша. Я понимаю что
>вопросами утечек через кэш серьезно озадачились лишь сравнительно недавно, но это не
>значит что грабель нет или что они незначительные. Это очень существенная проблема,
>сильно лимитирующая область применимости. Для лично меня - меня не устраивает требование
>что на процессоре в принципе не может крутиться никаких посторонних процессов. Это дико
>оторвано от современных реалий с виртуалками и контейнерами.

Дико оторвано от реалий это паранойа по поводу кэшей, когда перед ними стоит ОС из миллионов строк кода. Атаковать будут её/библиотеки, и сделают это успешно в 99% случаев, которых и происходят все атаки.

>А вон та толпа криптографов предупреждает что таблицы текут через кэш. Так что ну его
>этот ваш twofish в современных реалиях.

Реалии это подставить ведро и менять его, если на всю крышу многоквартирного дома идёт тоненькая струйка, а не бросаться менять всю крышу полностью, которая аналогично сможет долбануть и прорваться. Вы вне реалий. Криптографы предупреждают что имейте возможную протечку, а не то что это равносильно отсутствию крыши.

>Большинство ошибок фатальны обычно в использовании криптографии или прикручивании оной к протоколу.

Не правда. Большинство связаны с тупо обычным программированием которое ещё и до крипто не успеет дойти как будет с ошибками.

>И это при прочих равных шаг вперед. Если сравнить с RSA2048, можно ключ напрямую
>передавать, работает намного быстрее. Ну и нафига пользоваться RSA2048?

Потому-что я меньше доверяю продавшемуся DJB у которого никакого запаса прочности.

>PRNG как раз может быть довольно быстрым. Собственно ряд поточных алгоритмов шифрования
>по сути и являются PRNG где ключом является инициализация PRNG, так то на разные ключи -
>разные последовательности.

PRNG ОС отличается от того что в потоковом шифре. В ОС энтропия постоянно (должна) поступает, тогда как в потоковом шифре один раз заseedилась и всё. Хотя да: примитивы могут быть схожими.

>Ну если люди не могут выполнить даже пару простых требований - тогда им лучше идти
>веселую ферму кодить. Впрочем даже это при таких фиговых умениях не выйдет.

Ага, с вашим подходом типа только Бернштейн в состоянии что-то кодить. Все — люди: и все люди допускают ошибки. А также продаются.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру