Опубликован (http://www.opennet.me/tips/2877_ssh_crypt_setup_security_nsa...) вольный перевод статьи "Secure Secure Shell (https://stribika.github.io/2015/01/04/secure-secure-shell.html)", в которой проанализированы проблемные алгоритмы шифрования, которые потенциально могут быть использованы (http://www.opennet.me/opennews/art.shtml?num=41356) АНБ для организации атак на SSH, а также даны практические рекомендации по повышению защиты SSH. В том числе показано, как запустить SSH-сервер в виде скрытого сервиса Tor.URL: http://www.opennet.me/tips/2877_ssh_crypt_setup_security_nsa...
Новость: http://www.opennet.me/opennews/art.shtml?num=41411
Есть ещё и небольшие дополнения и коррекции к данной статье: http://www.cypherpunks.ru/articles/securing_ssh.html
> Есть ещё и небольшие дополнения и коррекции к данной статье: http://www.cypherpunks.ru/articles/securing_ssh.htmlДа, забавные там мнения. AES - это неплохой ... шанс спи...ть ключ шифрования, если есть возможность запускать непривилегированные процессы на том же процессоре. Процессу не надо доступ куда либо - ключ спирается через тайминг атаки на кэш проца. При том если кому кажеся что это эфемерная угроза - ФИГ, были практические реализации.
Полностью поддерживаю и согласен по поводу AES! Но если непривилегированные процессы не запускаются, то AES сойдёт.
Если подумать, виртуалка или контейнер вполне могут оказаться на одном проце с чем-то еще. Такой вот не совсем очевидный но обидный факап.
> Если подумать, виртуалка или контейнер вполне могут оказаться на одном проце с
> чем-то еще. Такой вот не совсем очевидный но обидный факап.А могут и не оказаться, если под рукой собственно настроенный и управляемый сервер дома или в охраняемом помещении на работе :-). У кого какие исходные данные и опасности.
Грубо говоря - я считаю что алгоритм шифрования не имеет право настолько ограничивать рамки применений. Особенно в *никсах которые испокон веков многозадачные и многопользовательские системы и не учитывать этот факт - ну, знаете ли, мне ни к чему алгоритмы которые нормально работают только в сферическом вакууме а в остальных случаях от них ВНЕЗАПНО тырят ключ.
А может АНБ и дал эту рекомендацию? Щас побегут все себе не думая копипастить.
> А может АНБ и дал эту рекомендацию?АНБ врядли обрадуется предложению вырубить нистовские алгоритмы и всякую окаменелую не слишком секурную дрянь, оставшуюся со времен царя Гороха.
Может им накладно держать спецов по этой окаменелой дряни? К тому ж уверенные в секурности современных алгоритмов хомячки будут сидеть на попе ровнее и вряд ли будут кипишить.
Ну вы можете верить в секурность DES. А у меня тем временем видеокарта весь keyspace за недельку переберет. Ну так, утрированно. Благо 56 битов - это не дофига.
> Ну вы можете верить в секурность DES. А у меня тем временем
> видеокарта весь keyspace за недельку переберет. Ну так, утрированно. Благо 56
> битов - это не дофига.Если внимательно бы почитать и хотя бы посмотреть на названия алгоритмов, то DES никто не предлагал и он не используется. Речь про 3DES, секурность которого 112 бит. А это дофига и всех видеокарт в мире не хватит для перебора keyspace.
> DES никто не предлагал и он не используется.Но вообще по логике вещей он древнее и провереннее временем чем тройной DES :).Который и появился как хоть какая-то попытка вкостылить надежность до более разумных величин.
я бы просто запретил доступ извне к компу и все. а в сети просто не светить важные данные. и все. обычно прокладка между клавой и монитором всегда самая слабая часть))
> я бы просто запретил доступ извне к компу и все.Круто. А как сервером в вон том датацентре в буржуиндии управлять? Лично ехать к буржуям в датацентр? Это долго, дорого и утомительно.
У меня для тебя есть патриотичное решение ))
> У меня для тебя есть патриотичное решение ))Наверное предложение поселиться жить в каком-нибудь датацентре. Спасибо, но что-то не хочется: там холодно и сервера воют как реактивный самолет.
А накой хрен тебе супер шифрование, если сервак в жопе мира,
доступно втыкание клавы, снятие дампа диска, и не факт, что
весь трафик не дампит АНБ
> весь трафик не дампит АНБТак пусть дампят шифрованный то, мне не жалко. А беспаливно что-то куда-то воткнуть ... ну, если ты креативный тип - отруби модули HID и прочая. Прикинь как товарищмайоры будут рады такому западлу? :) И case open детектор нехило бы настроить.
Кстати говоря, это эффективный метод завернуть атаки типа badUSB в ряде случаев. Если USBшный 3G свисток похакали и там ВНЕЗАНО отросла USB клава - хаксоров может ждать злой облом если свисток воткнут в нечто типа TL3020 с опенврт, где модуля HID тупо нет. Ну получил ты там клаву. И чего?
> я бы просто запретил доступ извне к компу и все.Доступ изнутри тоже надо запретить.
127.0.0.1 обязательно закрыть фаерволлом!
А то там 3306, 22, 9000, и т.д. порты светят на всю 127.0.0.0/8Насчет прокладки - да, но настройка безопасных протоколов - это тоже делается "прокладкой".
вот и я о том же. кстати если трафик реально снимают то и шифрование ваше не поможет. поскольку алгоритмывсе известные и анб давно похакало их вскрытие. ну как впрочем и наши. но вот беда достойного шифрования нет пока на горизонте.
> достойного шифрования нет пока на горизонте.Нас посетили крЮтые Ыксперды по шифрованию.
> вот и я о том же. кстати если трафик реально снимают то
> и шифрование ваше не поможет. поскольку алгоритмывсе известные и анб давно
> похакало их вскрытие. ну как впрочем и наши. но вот беда
> достойного шифрования нет пока на горизонте.До Сноудена "мозг не включай, шифрованию доверяй".
После "мозг не включай, ничему не доверяй".
Некоторые вещи (типа выключенного мозга) никогда не выходят из моды, как классика
>В том числе показано, как запустить SSH-сервер в виде скрытого сервиса Tor.А вот это полный фейл.
Почему? Например вашему провайдеру станет намного менее очевидно что вы ходили вон туда и рулили вон тем сервером. А то что в tor узлы не обязаны быть дружелюбными - так роутеры по пути к серверу тоже не обязаны. Не вижу чем узлы Tor фундаментально хуже роутеров по пути.
Потому что для защиты от АНБ ты на свой сервер ставишь АНБ-шный Тор. // Йа все еще КОъ
Да и в принципе усилить SSH, выставив вместо него голую _____^W^W Тор это весьма.
> Потому что для защиты от АНБ ты на свой сервер ставишь АНБ-шный Тор.А что - тор? Нет, если тебя зовут Бин Ладен и за тобой гоняется все АНБ и они имеют представление где тебя искать - тор тебя не особо спасет, разумеется. Но в обычном случае - на роль дежурной маскировки траффа от местечкового прова вполне сойдет. А контролировать 100% траффа в тор анб обломно будет (а если не обломно - ну мы им скажем спасибо за бесплатный бандвиз для обхода фаеров и фильтров и будем качать исошки убунты).
>> Потому что для защиты от АНБ ты на свой сервер ставишь АНБ-шный Тор.
> А что - тор? Нет, если тебя зовут Бин Ладен и за
> тобой гоняется все АНБ и они имеют представление где тебя искать
> - тор тебя не особо спасет, разумеется. Но в обычном случае
> - на роль дежурной маскировки траффа от местечкового прова вполне сойдет.
> А контролировать 100% траффа в тор анб обломно будет (а если
> не обломно - ну мы им скажем спасибо за бесплатный бандвиз
> для обхода фаеров и фильтров и будем качать исошки убунты).А ты сабж пробовал читать?
> А ты сабж пробовал читать?КрЮтая и аргументированная аргументация, как обычно у нашего профессионала. Скажи-ка, крутой профи, а с чего ты взял что роутеры по пути до сервака ведут себя лучше чем узлы Tor?
>> А ты сабж пробовал читать?
> КрЮтая и аргументированная аргументация, как обычно у нашего профессионала. Скажи-ка,
> крутой профи, а с чего ты взял что роутеры по пути
> до сервака ведут себя лучше чем узлы Tor?Слона то ты и не приметил. Ты на собственный сервер ставишь странное пoделие, спонсированное АНБ.
Смысл ssh — прикрывать твой зaд, а ты укрепил sshd выставлением гoлого зaда перед ним.
> Слона то ты и не приметил. Ты на собственный сервер ставишь странное
> пoдeлие, спонсированное АНБ.Ну я и говорю - они еще и SELinux проспонсировали. Ты уже сносишь линух по этому поводу?
> Смысл ssh — прикрывать твой зaд, а ты укрепил sshd выставлением гoлого зaда перед ним.
Это, несомненно, крутой и исчерпывающий анализ проблем программы с открытыми исходниками от видного эксперта в безопасности. Э не, порция FUD вместо аргументов - не катит.
В смысле, tor конечно имеет ряд грабель в дизайне и не обеспечивает супер-пупер уровень анонимности, НО с другой стороны траффик все-таки шифруется, никаких бэкдоров там нет (на него куча глаз смотрит) и несколько размазывается характер траффика. В целом выглядит немного более удачной идеей чем напрямую - маскирует характер активности от промежуточных роутеров. С которых скорее всего собирают как минимум netflow. В Tor вот так нагло шлангом собирать сведения о всем траффе несколько напряжно. Особенно в hidden services где никаких выходных узлов с расшифрованным траффиком нет. А так - очередная болтовня лишний раз подтверждающая соотношение вашего ЧСВ к квалификации.
>> Слона то ты и не приметил. Ты на собственный сервер ставишь странное
>> пoдeлие, спонсированное АНБ.
> Ну я и говорю - они еще и SELinux проспонсировали. Ты уже
> сносишь линух по этому поводу?zgrep SELINUX /proc/config.gz
# CONFIG_SECURITY_SELINUX is not set
> В смысле, tor конечно имеет ряд грабель в дизайне и не обеспечивает
> супер-пупер уровень анонимности, НО с другой стороны траффик все-таки шифруется, никаких
> бэкдоров там нет (на него куча глаз смотрит)Они так и до Heartbleed говорили.
> А так - очередная
> болтовня лишний раз подтверждающая соотношение вашего ЧСВ к квалификации.Над твоей квалификацией уже поглумились в теме про OpenNTPD.
> # CONFIG_SECURITY_SELINUX is not setА ты как, проверил что при этом весь АНБшный код остается не у дел? :)
> Они так и до Heartbleed говорили.
А я до нахождения POODLE'я сказал что TLS гуано и его куча легаси и сложность позволяют пакости типа атак на даунгрейды. Как в воду глядел - не прошло и года как нашли пуделя. И как это я так ухитряюсь, право? :)
> Над твоей квалификацией уже поглумились в теме про OpenNTPD.
Я и вижу - мегаэкспертов понабежало. В качестве аргументов в основном громкий ор и ломовое ЧСВ. А я вот пуделя предсказал еще до того как он случился. Потому что с TLS/SSL вообще и OpenSSL в частности мне уже давно все понятно.
>я вот пуделя предсказал еще до
> того как он случился. Потому что с TLS/SSL вообще и OpenSSL
> в частности мне уже давно все понятно.Подайся в экстрасенсы что ли, потому что в ИТ тебе дальше эникея не подняться. Не твое это. Ты для усиления SSH на сугубо секретный сервер установил ТОРоян, с тем самым OpenSSL для надежности слива, чтоб наверняка. Неуд.
Остальное ты уже прочитал в удаленном сообщении.
> Подайся в экстрасенсы что ли, потому что в ИТ тебе дальше эникея
> не подняться. Не твое это.Несомненно, мнение такого крутого и компетентного эникея как ты для меня очень ценно :)
> Ты для усиления SSH на сугубо секретный сервер установил ТОРоян,
И, конечно, ты покажешь там троянскую функциональность? Вон исходники лежат - дерзай.
И да, если что - алгоритм tor обеспечивает padding траффика. Что нагибает реконструкцию содержимого сессии, тем самым зарубая ряд возможностей атакующих. И хоть я и соглашусь с тем что openssl вывешенный в сеть это грабли, на типовом серваке оно будет и без всякого tor, так что новых векторов атаки на таких машинах добавляется не так уж и много.
> с тем самым OpenSSL для надежности слива, чтоб наверняка. Неуд.
На третий день Крутой Гуру заметил что openssl был нужен для начала самому ssh ;). Хотя теперь оборвать этот кусок крапа там при сильном желании все-таки можно. Тогда останутся аж целые алгоритмы дяденьки Бернштейна.
> Остальное ты уже прочитал в удаленном сообщении.
Я не мониторю этот тред ежесекундно и поэтому понятия не имею что за удаленные сообщения. Но со своей стороны всячески приветствую попытку модераторов вправить мозг некомпетентному но наглому хамью.
>> Ты для усиления SSH на сугубо секретный сервер установил ТОРоян,
> И, конечно, ты покажешь там троянскую функциональность?Да, уже писал в позапрошлом сообщении. https://blog.torproject.org/blog/openssl-bug-cve-2014-0160
> Вон исходники лежат - дерзай.
В г___е копаться я и за деньги не буду. С чего бы?
> И да, если что - алгоритм tor обеспечивает padding траффика
Охренеть рокет саенс. Подумашь бекдоры, АНБ и опенссл, зато есть паддинг. Срочно в продакшн.
>> с тем самым OpenSSL для надежности слива, чтоб наверняка. Неуд.
> На третий день Крутой Гуру заметил что openssl был нужен для начала
> самому ssh ;). Хотя теперь оборвать этот кусок крапа там при
> сильном желании все-таки можно. Тогда останутся аж целые алгоритмы дяденьки Бернштейна.http://www.youtube.com/watch?v=DrzRUr5AL98
Поясню, это про тебя.>> Остальное ты уже прочитал в удаленном сообщении.
> Я не мониторю этот тред ежесекундно и поэтому понятия не имею что
> за удаленные сообщения. Но со своей стороны всячески приветствую попытку модераторов
> вправить мозг некомпетентному но наглому хамью.Круто ты заврался. Ты ответил на то безобидное сообщение и удалили из-за твоего хамства, чтобы не провоцировать. Слишком ты разбуянился благодаря собственному дилетантству.
Поясните, пожалуйста.
Пока, для меня это выглядит заманчивым. И вот почему:
1. Создать такой же адрес, как мой, будет технически сложно
2. Создав такой же адрес, будет технически сложно подменить мой ssh-сервер, с его фингерпринтом.
Наш ответ Чемберлену с его замечаниями:
> DES — сломан, но не 3DES. Если уровень безопасности в 112 бит достаточен, то
> его использование приемлемоТройной DES - гуано. Во первых, он тормозной как черти-что, во вторых, никакой особой стойкостью не обладает. Выбор некрофила который прикипел к DES.
> RC4/Arcfour имеет особенности из-за которых некоторые реализации
> действительно можно считать сломанными.Arcfour в чистом виде имеет уйму дурных проблем. Самая жестокая - утечка ключевого материала в первых примерно 256 байтах вывода его PRNG. Поэтому уважающие себя реализации обычно отбрасывают первые 768...1024 байта. Если этого не делать - прецеденты взлома имеются. Далее arcfour имеет статистические отклонения от настоящей случайности, что намекает что его случайность не совсем случайная. Это с точки зрения криптографии плохо. Кроме того, сам по себе arcfour остро нуждается в дополнительных схемах костылирования, ибо если просто юзать вывод PRNG от одного и того же ключа на нескольких разных шифротекстах, атакующий знающий некий известный текст - узнает часть последовательности. И сможет расшифровывать куски неизвестных шифротекстов. Лечится схемами с шифрованием случайного временного ключа постоянынм и далее использованием этого ключа, разного для каждого потока. Но если влобовую применить arcfour - можно встать на эти грабли. В целом специфичный алгоритм, которым лучше бы не пользоваться. Есть некие доразвития идеи на его основе, избавленные от утечки ключевого материала и прочая - см. вику :).
> Конечно дело паранойи и недоверия, но даже скептики типа Брюса Шнайера не
> видят особый смысл использования 256 бит ключей против 128.Может помочь в случае если в схеме шифрования окажется ощутимое упрощение. Запас прочности у 256 битов будет выше.
> сомнений (а это существенная экономия трафика,
Забота о экономии траффика это круто. Вот только чем экономнее траффик - тем лучше реконструкция активности пользователя в шелле по размерам пакетов, даже без расшифровки.
А автору оригинала - нехило бы обосновывать выбор алгоритмов.
//если не сильно обосновывать, я бы вообще выпилил все кроме 25519+poly1305+salsa/chacha. Хотя-бы потому что все шифрование могло бы быть в микроскопическом TweetNaCl который реалистично прочитать глазами за обозримое время.
> Тройной DES - гуано. Во первых, он тормозной как черти-что, во вторых,
> никакой особой стойкостью не обладает. Выбор некрофила который прикипел к DES.Его стойкость 112 бит. Не особая, но имещющаяся. То что он в разы медленнее всех остальных вместе взятых -- безусловно. Но он не insecure для своих 112 бит.
> Arcfour в чистом виде имеет уйму дурных проблем. Самая жестокая - утечка
> ключевого материала в первых примерно 256 байтах вывода его PRNG. Поэтому
> уважающие себя реализации обычно отбрасывают первые 768...1024 байта.Как говорит стандарт для SSH-а 1536 байт надо откинуть. Речь как-раз про то что его нужно прявильно применять, а не в чистом виде.
> Если этого не делать - прецеденты взлома имеются.
Ещё какие!
> Далее arcfour имеет статистические отклонения от
> настоящей случайности, что намекает что его случайность не совсем случайная.Имеет в первых выхлопах шифра.
> остро нуждается в дополнительных схемах костылирования, ибо если просто юзать вывод
> PRNG от одного и того же ключа на нескольких разных шифротекстах,
> атакующий знающий некий известный текст - узнает часть последовательности.В целом это всё касается любых потоковых алгоритмов шифрования. Об этом и речь: их надо правильно применять, ибо любая ошибка и цена за неё куда выше (полная дешифрация текста запросто) чем в блочных шифрах.
> В целом специфичный алгоритм, которым лучше бы не пользоваться.
Лучше не пользоваться если не сможешь правильно реализовать. Полностью согласен. Поэтому от греха подальше всегда и везде говорят что лучше его выпилить и забыть. Но конкретно OpenSSH реализация вполне себе годная и грамотная к использованию. И если нет аппаратного ускорения AES/GCM, нет ChaCha20, а скорости хочется, то почему бы и нет?
> Забота о экономии траффика это круто. Вот только чем экономнее траффик -
> тем лучше реконструкция активности пользователя в шелле по размерам пакетов, даже
> без расшифровки.Ну SSH всё же не ставит задачи противодействовать traffic analysis. Увеличив размер tag-а MAC-а мы же всё-равно не сгладим утечки в канале по времени: они точно такие же детерминированные для shell-а останутся. Ну и это уже не так сильно играет для передачи файлов (scp, sftp).
> //если не сильно обосновывать, я бы вообще выпилил все кроме 25519+poly1305+salsa/chacha.
Поддерживаю! Но пока это прососётся в стандарты, RFC, тем более какие-нибудь TLS-ы кроме SSH…
> Его стойкость 112 бит. Не особая, но имещющаяся.Во первых, криптографы нынче недолюбливают подобные схемы с s-box'ами.
Во вторых, любое нечто использующее таблицы - объект для тайминг атак. Любым имеющим доступ к локальной машине, даже под другим пользователем.
В третьих, каких-то особых достоинств у него просто нет. Зато есть недостаток - тормознyтый.
Ну и зачем этот окаменелый шит упоминать?
> То что он в разы медленнее всех остальных вместе взятых -- безусловно.
> Но он не insecure для своих 112 бит.Он просто дyрной по совокупности параметров. Его место - на клaдбище космических кораблей.
> Как говорит стандарт для SSH-а 1536 байт надо откинуть. Речь как-раз про
> то что его нужно прявильно применять, а не в чистом виде.Нужда сделать полторы тысячи итераций вхолостую кроме убивает достоинство в виде скорости в ряде применений (e.g. шифрование мелких пакетов с разными ключами). А наличие статистических отклонений - просто плохо и возможно что однажды кто-то на основе этого сможет что-то извлечь. На самом деле он симпатичен простотой и отсутствием блоков. Но, к сожалению, выявились дyрные проблемы, а простоту приходится костылировать. Из очевидных плюсов - скорость. Из минусов - кроме упомянутых еще и операции на таблице в памяти, которая источник утечек информации в сторону других процессов. В целом как-то криптографы нынче охладели к таким схемам.
А какой-нибудь salsa/chacha - быстрые, никаких операций на таблицах. Сугубо математика в регистрах. В память особо не лезет, времянки наружу не утекают даже на более-менее обычных процах. А ssh все-таки крутится на многопользовательской машине. Особенно весело на всяких виртуалках и вдсках - мало ли что там на том же физическом проце крутится...
> Имеет в первых выхлoпах шифра.
Насколько я помню, там еще проблема в том что достаточно большой выхлoп имеет отклонения от случайного.
> В целом это всё касается любых потоковых алгоритмов шифрования.
Однозначно. Просто НАДЕЖНАЯ схема получается не такой простой как казалось бы на первый взгляд.
> Лучше не пользоваться если не сможешь правильно реализовать. Полностью согласен.
Для начала я бы предпочел чтобы про arcfour забыли и если уж так сильно хочется попрыгать по этим граблям - в вике можно найти более интересных последователей, лишенных ряда проблем с утечками ключей в начальном выводе. Но в целом там своих грабель есть и я бы сильно советовать не стал.
> Но конкретно OpenSSH реализация вполне себе годная и грамотная
> к использованию.Оно как бы да, но...
> И если нет аппаратного ускорения AES/GCM, нет ChaCha20, а
> скорости хочется, то почему бы и нет?Например, потому что мало ли где там этот ssh юзается (VM/контейнер), а state в памяти в виде таблицы - по идее может утекать информация о ключе или состоянии алгоритма.
> Ну SSH всё же не ставит задачи противодействовать traffic analysis.
А смысл в шифровании, которое не противодействует анализу трафика? Так можно и телнетом пользоваться, если уж анализ пофиг :).
> tag-а MAC-а мы же всё-равно не сгладим утечки в канале по
> времени: они точно такие же детерминированные для shell-а останутся.Это да - там скорее блоки по типу того что в tor надо.
> Ну и это уже не так сильно играет для передачи файлов (scp, sftp).
Файлов - да. Передачи траффика на форварде портов или впн - нет. Работа с шеллом - совсем нет.
> Поддерживаю! Но пока это прососётся в стандарты, RFC,
Всякие там NSA уж постараются чтобы этого не случилось. Чего ожидать от NIST мы уже видели на примере их нового PRNG.
> тем более какие-нибудь TLS-ы
Использовать TLS - хорошая заявка на залeт. Слишком дофига опций и легаси - он просто не может быть секурным. Я даже предсказал атаку на даyнгрейд. SSH это кстати тоже касается.
> кроме SSH…В нем кстати на мой вкус тоже слишком дофига опций и легаси накопилось. В результате оно умет сильно больше чем ожидает админ и позволяет сильно много манипуляций со стороны атакущего.
p.s. гаццкий вордфильтр.
Возможно меня не так поняли, но я нисколько не собирался давить на то что 3des или arcfour стоит рассматривать к применению если под рукой есть chacha20. Вне всяких сомнений chacha20/poly1305/25519 должны использоваться если имеются. То что от rc4/3des и прочего стоит избавляться (так же как и от aes) и их место на кладбище -- всеми руками за. Мой point лишь в том что допустим у человека нет достаточно современного SSH-сервера где бы эти chacha были. По мне так нельзя сказать что это вообще ни на что уже не годно: годно, но тормознуто и так далее.Обращу внимание, как автор "заметок", что в них я никаких 3des и rc4 и не встроил осознанно. aes остался, но после него сразу blowfish и больше ничего. Лучше обновлять софт, чем пытаться с этим работать. Хотя blowfish возможно тоже не стоит, ведь он работает в SSH только в CBC режиме, а многие серверы подвержены атаке когда под 32 бита plaintext-а может утечь, именно в CBC режимах.
По поводу AES и S-box-ов и вообще всего что касается поиска в таблицах и то что криптографы от этого избавляются -- бесспорно, верно, вне всяких сомнений. Если есть выбор в виде Salsa, Chacha, Threefish/whatever -- лучше сделать этот выбор. Но у меня опять же речь про тех у кого нет обновлённых SSH-серверов и они находятся в относительно доверяемом окружении: на железе которое можно потрогать, поглядеть на него, зная что посторонние к нему не подойдут (конечно же не про дата-центры речь). Банально например Wifi домашний между сервером и ноутбуком, где на сервере известно что ничего постороннего не крутится (как и на ноутбуке), а доверять Wifi шифрованию конечно же просто нельзя и приходится делать какой-нибудь канал шифрованный. Хотя... уж в домашних условиях для себя любимого SSH обновить то не сложно должно быть.
Если, как вы и говорите, мало ли где этот SSH-сервер находится/используется, то рисковать лучше конечно не надо и лучше и про AES забыть однозначно.
>А смысл в шифровании, которое не противодействует анализу трафика?
Не, я имел в виду под анализом трафика -- его статистический анализ, то бишь размеры и частота/время прохождения пакетов.
Про TLS: если это TLS канал между собственно настроенным сервером и клиентом, где вырезаны все legacy алгоритмы (хотя бы на уровне строк приоритетов GnuTLS/OpenSSL), где чётко явно задаётся как и с чем он должен работать -- не вижу ничего опасного в этом, если есть доверие к реализации. В целом, в общем случае, когда это HTTPS например с которым общаются сотни самых разных клиентов (и соответственно разное чего поддерживающих), то тут конечно речи о безопасности не будет идти. Но я согласен без сомнений что если есть чем заменить TLS, то лучше это сделать.
То что в SSH накапливается бесполезный хлам -- печально конечно. lsh вон видел что делают свой SSH2-only сервачок и действительно много выпилено. Не знаю насколько качественные там реализации, но всяких chacha/25519 там не видно. Зато приятно что сделали SRP поддержку.
> то что 3des или arcfour стоит рассматривать к применению если под
> рукой есть chacha20.Ну а если под рукой нужных алгоритмов нет - это как раз то чем стоило бы озаботиться.
> Мой point лишь в том что допустим у человека нет достаточно современного SSH-сервера
Мой пойнт в том что если некто не контролирует свое окружение НАСТОЛЬКО - какая там нафиг безопасность? Кивания на стандарты и прочая показали что те кто выбирают стандарты - как правило отказываются от безопасности.
> не годно: годно, но тормознуто и так далее.
Морально устаревший и потенциально проблемный по ряду пунктов вариант, имхо. Ну то-есть если выбор какой кактус грызть - этот как бы не самый колючий, но зачем грызть кактусы - загадка природы.
> зная что посторонние к нему не подойдут
При таких допущениях можно хоть телнет использовать. Со своей стороны я думаю что алгоритм должен по возможности создавать минимум проблем и минимум возмущений во внешней среде. Иначе будет много трудноучитываемых факторов которые долбанут в лоб.
> ноутбуке), а доверять Wifi шифрованию конечно же просто нельзя и приходится
> делать какой-нибудь канал шифрованный.С wi-fi все довольно забавно:
- Во первых, подставную точку доступа сделать не так уж сложно.
- Во вторых, фабричные прошивки роутеров редкий крап, начиная от наличия там бэкдоров и заканчивая реализацией какого-нибудь WPS, позволяющего сунуться в сеть с ним за полдня кому угодно.> любимого SSH обновить то не сложно должно быть.
Да и не в домашних - тоже. Если кто не может даже это - как они остальной софт разворачивают?
> Если, как вы и говорите, мало ли где этот SSH-сервер находится/используется,
Ну как бы случаи когда на сервере есть только ssd и более нишиша - достаточно редки. Поэтому на мой взгляд лучше использовать алгоритмы ориентированные на регистровую арифметику - так будет меньше неожиданностей.
> Не, я имел в виду под анализом трафика -- его статистический анализ,
> то бишь размеры и частота/время прохождения пакетов.Если честно я не вижу принципиальной разницы как именно декодируют мой траффик. Лобовым ли расшифровыванием или косвеной реконструкцией. Результат одинаковый.
> Про TLS: если это TLS канал между собственно настроенным сервером и клиентом,
> где вырезаны все legacy алгоритмы (хотя бы на уровне строк приоритетов
> GnuTLS/OpenSSL), где чётко явно задаётся как и с чем он должен
> работать -- не вижу ничего опасного в этом,В целом и протокол и либы - полное г-но! Почему?
- Разобраться каким ауторити кто доверяет по дефолту без поллитры невозможно. И любая доверяемая ауторити может выписать правдоподобно выглядящий и рабочий сертификат.
- Уйма легаси, несекурного и проблемного. Зачастую дающего возможность даунгрейда и подстав.
- Очень сложный протокол, с кучей явно лишних опций. Обречен иметь много проблем безопасности в реализациях. Большой либе - куча багов.
- Редкий апликушник заморачивается какие там алгоритмы и версии протокола. Он думает что ему сделют безопасно. А оказывается - фиг!
- Более того, половина апликушников вообще не делают самых базовых вещей. Скажем запомнить и проверить совпадение фингерпринта (стандартно для любого клиента ssh) в TLS допирают только особо избранные. Я из таких видел целый пиджин. И ... всё?!
- Получить лучшие свойства которые может предоставить современная криптография - гемор и рокетсайнс.А с другой стороны у нас есть какой-нибудь tweetnacl дяденьки Бернштейна. Его можно прочитать глазами, там мизер кода. Там по дефолту нормальная подборка алгоритмов. По дефоту все безопасно. Апи примитивное и лохануться там еще надо суметь. Крутейший diffie-hellman на эллиптических кривых - "почти без key exchange". Да и сами ключи столь компактны что их можно напрямую передавать вместо fingerprint. А perfect forward secrecy на основе этого может сделать даже неглупый школьник. А кому хочется готовое - CurveProtect есть. Но вот почему-то это - не стандарт. Но - здорово лучше стандартов, имхо.
> если есть доверие к реализации.
Не вижу оснований доверять переросточной либе и переусложненому протоколу лишний раз. Огромный код в протоколе с кучей костылей гарантирует кучу багов. Последнее что нужно в конструкции призванной кого-то от чего-то защищать. Heartbleed не должен был существовать - потому что этой фичи не должно было быть в протоколе, для начала. А если в протокол напхать хлама "чтобы было" - будет как-то так.
> я согласен без сомнений что если есть чем заменить TLS, то
> лучше это сделать.А тут уж каждый за себя решает что ему. Или стандарты толку с которых ноль, или фактическая результативность.
> знаю насколько качественные там реализации, но всяких chacha/25519 там не видно.
В правильном направлении смотрели вон те граждане - http://www.opennet.me/opennews/art.shtml?num=39752
> Зато приятно что сделали SRP поддержку.
Не знаю чего в этом такого приятного.
> что те кто выбирают стандарты - как правило отказываются от безопасности.Это верно. Но стандарты означают широкое распространение софта и то что его увидят больше глаз. А те кто выбирают безопасность могут выбирать мало кому что известное, а значит запросто менее читаемое глазами -- review кода минимальный. Для меня хороший вопрос что важнее и лучше. Математические алгоритмы это одно, а реализация это совершенно другое и реализация не зависят от того aes ли это или chacha20. Кроме самого шифрования ещё тьма банального кода не относящегося к криптографии как таковой напрямую -- который тоже можно будет атаковать. Это не повод слепо доверять OpenSSL столь распространённому, но и не повод слепо верить в то что компактность кода chacha/poly1305 автоматом сделают всё лучше, вот только запросто написано оно будет несколькими людьми которые никто не гарантирует что хорошие программисты и что тем более умеют хорошо реализовывать криптоалгоритмы и знают например про то что нельзя зачастую просто так сравнивать строки между собой в коде (ибо это не константное время).
> Морально устаревший и потенциально проблемный по ряду пунктов вариант, имхо. Ну то-есть
> если выбор какой кактус грызть - этот как бы не самый
> колючий, но зачем грызть кактусы - загадка природы.Потому-что например blowfish технически может быть и более ущербный, но он приемлимый для использования и он проверен уже десятилетиями. Chacha20/Poly1305 на бумагах хороши, и в коде ешё лучше и короче и эффективнее, но просто не прошло достаточно времени чтобы сказать что он проверен этим самым временем. Появился Chacha20 допустим день назад и какие-то криптоанализы заимел -- вы бы стали использовать? Я бы нет, ибо рано, не проверен временем. Прошло 2-3 года. Вы бы стали использовать? Кто-то да, кто-то нет.
> С wi-fi все довольно забавно:
> - Во первых, подставную точку доступа сделать не так уж сложно.
> - Во вторых, фабричные прошивки роутеров редкий крап, начиная от наличия там
> бэкдоров и заканчивая реализацией какого-нибудь WPS, позволяющего сунуться в сеть с
> ним за полдня кому угодно.Именно про это и говорю: приходится предполагать что Wifi абсолютно кем угодно прослушивается и поверх его коннекта вынуждены применять IPsec/OpenVPN/SSH/whatever. Wifi безопасность это именно crap, реально. Проще считать что её нет и это plaintext открытый broadcast канал.
> Ну как бы случаи когда на сервере есть только ssd и более
> нишиша - достаточно редки. Поэтому на мой взгляд лучше использовать алгоритмы
> ориентированные на регистровую арифметику - так будет меньше неожиданностей.Лучше да, но их поведение всё-равно ещё не так хорошо изучено как старых добрых Blowfish и подобных. Плюс я не имею в виду что кроме SSH ничего не крутится: но если там out-of-box OpenBSD с Postfix-ом дополнительно поставленным, то для меня это доверяемая система.
> Если честно я не вижу принципиальной разницы как именно декодируют мой траффик.
> Лобовым ли расшифровыванием или косвеной реконструкцией. Результат одинаковый.Если вы не видете разницы, то меня удивляет как же вы можете пользоваться хоть чем-то из нами упоминаемого: ничто из этого не пытается скрыть статистические отклонения (например ввод "top" и его "выхлопы" в stdout довольно хорошо заметны в размерах и частоте пакетов). Собственно этим страдают любые real-time системы. Ну кстати Tor хотя бы минимальный размер передаваемых единиц вроде как делает минимальным в 512 байт, что хоть что-то даёт (хотя с GNUnet-ами это не сравнится).
> - Разобраться каким ауторити кто доверяет по дефолту без поллитры невозможно. И
> любая доверяемая ауторити может выписать правдоподобно выглядящий и рабочий сертификат.Я опять же про случай когда само собой третьи лица не участвуют. Чётко заданные сертификаты с одной и другой стороны.
> - Уйма легаси, несекурного и проблемного. Зачастую дающего возможность даунгрейда и подстав.Зачастую, но не всегда, особенно когда руками в конфигурации прибить что надо использовать.
> - Редкий апликушник заморачивается какие там алгоритмы и версии протокола. Он думает
> что ему сделют безопасно. А оказывается - фиг!Про тех кто думает что ему сделают хорошо просто так: я само собой не беру в счёт ибо тут о безопасности нельзя говорить.
> - Более того, половина апликушников вообще не делают самых базовых вещей. Скажем
> запомнить и проверить совпадение фингерпринта (стандартно для любого клиента ssh) в
> TLS допирают только особо избранные. Я из таких видел целый пиджин.
> И ... всё?!
> - Получить лучшие свойства которые может предоставить современная криптография - гемор
> и рокетсайнс.Верно. Поэтому всегда компромис между безопасностью и негеморрностью с юзабилити. Если кто-то хочет чтобы легко и просто -- будет не безопасно :-). Это факт само собой. Люди оказывается считают web-of-trust какой-то непонятной сложнейшей неподнимаемой штукой. Хотя ему опять же сколько десятков лет. Нет все хотят доверять одному единственному честному и верному CA какой-нибудь корпорации "добра".
> А с другой стороны у нас есть какой-нибудь tweetnacl дяденьки Бернштейна. Его
> можно прочитать глазами, там мизер кода. Там по дефолту нормальная подборка
> алгоритмов. По дефоту все безопасно. Апи примитивное и лохануться там еще
> надо суметь.Да, действительно всё просто. Но и в таком мизере кода ошибок можно совершить уйму. Для меня это просто факт, ибо сам программист. И одно дело когда его смотрят N людей, а другое дело когда на порядки больше. Хотя лично я конечно доверяю Бернштайну: это не какой-то школьник и его репутация и работы говорят о многом, да и собственно софт который он делал.
> А тут уж каждый за себя решает что ему. Или стандарты толку
> с которых ноль, или фактическая результативность.И не забывать о кол-ве людей делающий ревью кода. TLS или IPsec (о чём Шнайер и говорит) это конечно крайность где сложность такая что проще сказать что априори не безопасно. Другая крайность это результативность, где каждый волен пилить свои безопасные простые реализации которых будет под сотни и само собой речи о безопасности тоже не будет идти, уже как минимум из-за реализаций.
> В правильном направлении смотрели вон те граждане - http://www.opennet.me/opennews/art.shtml?num=39752
Относительно. 15k строк кода -- уже сильно не мало. Их реализации я явно не буду доверять потому-что банально она не прожила N лет. Они собираются всё-равно встроить ecdsa и прочее NIST-отравленное дерьмо. Идея в целом конечно хороша, но по мне так надо бы и лучше отказаться от SSH совметимости и сделать более простой и ясный протокол. Плюс лично мне совсем не нравится что они полностью отказываются от RSA и фактически только на эллиптических кривых сидят: пока ещё не доказано что они так же безопасны как старый добрый знакомый RSA. Да его геморройно реализовать, куча подвохов, но за десятилетия это хорошо изученный вопрос. А ECC слишком нова, недоказана что не имеет фатальных критических недостатков которые могут её свести на нет (что проблема их решения сводится реально только исключительно к нахождению решений уравнений кривых фактически). Опять же кому как, но лично для меня ECC под вопросом ещё остаётся.
>> SRP
> Не знаю чего в этом такого приятного.Хотя бы эффективность чтобы не делать отдельно по две асимметричные аутентификации двух сторон и ещё отдельно обменивать ключи. Более проверенный временем (по мне) протокол и криптография чем в 25519 как минимум.
> Это верно. Но стандарты означают широкое распространение софта и то что его
> увидят больше глаз.Только буйный психопат захочет читать код реализации какого-нибудь TLS от и до. Со всеми опциями и легаси. А в openssl столько кода что там неизбежно будут баги. Если вкратце, я не думаю что шитец типа openssl реально сделать вменяемым с хоть каким там ревью. К тому же компетентность тех кто ревьюит - под вопросом. Авторы OpenSSL вообще не криптографы, судя по лаже которую они допускают. Чтобы понять насколько они дилетанты - помогает почитать ченжлог хоть того же Tor. Да, если вы просите аппаратное ускорение - эти красавцы выдадут вам как рандом вывод железного RNG, если он есть. Пул энтропии? Подмешивание из разных источников? Не, не слышали! Доверие железке стопроцентное. А теперь сравним с, допустим, тем что делает линевый кернель. Там почему-то догадываются что слепо верить железячному RNG - затея очень на любителя. Так где эти ваши ревью были столько лет?
> кому что известное, а значит запросто менее читаемое глазами -- review
> кода минимальный.Я думаю что один Бернштейн легко заменяет сотню макак пишущих openssl. Так, глядя на плюхи которые они вешают. Я вообще не понимаю чего ради эти люди криптографическую либу писать полезли. Они не криптографы и даже не обладают минимальным уровнем паранои для того чтобы совать лапы в криптографию.
> Для меня хороший вопрос что важнее и лучше.
Я выбираю осмысленность действий индивидов. Нормальные криптографы это могут. А вот авторы openssl показали что у них не богато с довольно базовыми вещами...
> Математические алгоритмы это одно, а реализация это совершенно другое
В случае криптографии одно не сильно далеко от другого. Более того - когда реализаторы лезут донавесить 100500 сервисных функций, как опенссл - можно налететь на тот факт что эти плюшки были с цианидом, тудыть их растудыть.
> OpenSSL столь распространённому, но и не повод слепо верить в то
> что компактность кода chacha/poly1305 автоматом сделают всё лучше,Для начала там будет минимум багов. А если это еще и писал нормальный криптограф типа Бернштейна, повернутый на безопасности - там будут нормальные дефолты и минимум внезапностей. А вот авторы openssl могут немало огорошить, например. Ну как с аппаратным RNG скормленым софту напрямую, если попросить аппаратное ускорение. Пипец логика - при использовании криптоакселератора можно бонусом получить нерандомный рандом чего доброго.
> например про то что нельзя зачастую просто так сравнивать строки между
> собой в коде (ибо это не константное время).Про это знают все нормальные криптографы. А вот то что про это в курсе какие-нибудь деятели типа авторов openssl - я бы за это зуб не дал.
>> колючий, но зачем грызть кактусы - загадка природы.
> Потому-что например blowfish технически может быть и более ущербный, но он приемлимый
> для использования и он проверен уже десятилетиями.MD5 тоже проверенный временем. Проверка показала: он г-но. Ну и sha1 туда же куда-то отправляется. Хотя про blowfish никакого особенно крутого криминала мне не известно так сходу. Но тут еще вопрос в том - а сколько человек проблемы искало?
> Chacha20/Poly1305 на бумагах хороши, и в коде ешё лучше и короче и эффективнее,
> но просто не прошло достаточно времени чтобы сказать что он проверен этим самым временем."Насыщает не время проведенное в столовой а количество съеденных беляшей".
> Появился Chacha20 допустим день назад и какие-то криптоанализы заимел --
> вы бы стали использовать? Я бы нет, ибо рано, не проверен временем.См. выше. Логику построения salsa/chacha я более-менее понимаю и вижу криптоанализ. При том - с пониманием дела и даже "частично успешный". Это значит что алгоритм проверяли не какое-то сферическое время в вакууме а вполне себе криптографы, разбирающиеся в предмете и даже нащупавшие некие упрощения. А мнение 10 профессиональных криптографов - ценнее чем мнение 10 000 кодеров, не имеющих понятия о криптографии.
> Прошло 2-3 года. Вы бы стали использовать? Кто-то да, кто-то нет.
Если уж на то пошло, 25519 и прочие появились далеко не вчера. Вчера на них лишь обратили внимание из-за кризиса доверия к NIST и прочая.
> Именно про это и говорю: приходится предполагать что Wifi абсолютно кем угодно
> прослушивается и поверх его коннекта вынуждены применять IPsec/OpenVPN/SSH/whatever.Ну да. Если защита траффика нужна. Хотя честно говоря, прецедентов вскрытия WPA2 если нет WPS и сложный пароль - мне не известно.
> и это plaintext открытый broadcast канал.Я считаю что доверяемая прошивка на роутере без явных ляпов мне все-таки друг и товарищ и потому предпочиаю openwrt, где все это реализовано не сильно архаичным линем и дровами из его комплекта.
> Лучше да, но их поведение всё-равно ещё не так хорошо изучено как
> старых добрых Blowfish и подобных.Тут еще вопрос в количестве изучавших и их квалификации. От того что миллион быдлoкодеров посмотрит в код - криптография лучше не станет. Потому что они в этом ни бум-бум. А вот если криптографы потратят время на серьезные попытки атак - совсем иное дело. Открытость кода необходима для аудита разными криптографами. Но вот то что качество этого аудита стопроцентно коррелирует со временем или числом глаз - не факт. Я склонен придавать вес еще и компетенции тех кто смотрел, этот параметр сам по себе не коррелирует с временем или количеством глаз.
> с Postfix-ом дополнительно поставленным, то для меня это доверяемая система.
Весьма зависит от того ломанут ли его или нет. Неприятно если скажем разделение прав удержится, но ключ все-равно утянут по косвенным признакам. Не вижу причин почему это должно быть так.
> скрыть статистические отклонения (например ввод "top" и его "выхлопы" в stdout
> довольно хорошо заметны в размерах и частоте пакетов).И это одна из вещей которые мне в ssh не нравятся. Ксати если уж мы о птичках - идея завернуть ssh в hidden сервис тор имеет место быть и как минимум он здорово нагнет подобные инициативы, минимизировав полезность сведений за счет фиксированного размера cells.
> любые real-time системы. Ну кстати Tor хотя бы минимальный размер передаваемых
> единиц вроде как делает минимальным в 512 байт, что хоть что-то даётУ них фиксированный размер cells, насколько я помню. Он один на все. Шлете 1 байт? В провод полетит cell фиксированного размера. Как и на 20 байтов. Или на 100. Это достаточно неплохо нагибает подобный анализ. Хотя будучи low latency оно неизбежно утекает времянки.
> (хотя с GNUnet-ами это не сравнится).
А там довольно компетентные авторы с неплохими идеями. Но вот реализация какая-то странная.
> Я опять же про случай когда само собой третьи лица не участвуют.
> Чётко заданные сертификаты с одной и другой стороны.Опять же - отучить ssl'ную либу доверять посторонним ауторити или проверить кому оно доверяет здесь и сейчас - могут быть весьма отдельные телодвижения, далекие от тривиальных. В том же ssh подобные вещи по крайей мере логично и без подстав сделаны. А ssl/tls by design такие подставы предполагали.
> Зачастую, но не всегда, особенно когда руками в конфигурации прибить что надо
> использовать.Я не счтиаю что использование криптогрфии должно требовать квалификации ракетного инженера от эксплуатационщика. Такой подход обречен на провал.
> Про тех кто думает что ему сделают хорошо просто так: я само
> собой не беру в счёт ибо тут о безопасности нельзя говорить.Аудитить код всех приложений использующих tls крайне мерзко и геморно и ведет к массе растройств. И даже опытный субъект может прощелкать что-то клювом. Потому что сложная хреновина с дофига опций, при том дефолтные их состояния отнюдь не заточены на маесимальную секурность, отсутствие подлян и наилучшие свойства (e.g. PFS). Все это делает применение TLS больше похожим на запрыг по граблем. Ну да, полтора джедая может и допрыгают до финиша без шишек на лбу, если нигде не споткнутся и не запнутся.
> Верно. Поэтому всегда компромис между безопасностью и негеморрностью с юзабилити.
Булшит. Дяденька Бернштейн в его либах показал что хорошая безопасность - не синоним адового гемора. Вот этим либа сделанная криптографом понимающим проблематику отличается от либы которую писали какие-то лабухи не имевшие к криптографии никакого отношения.
> Если кто-то хочет чтобы легко и просто -- будет не безопасно :-).
Нет никаких законов природы которые бы делали неизбежным такой tradeoff.
> хотят доверять одному единственному честному и верному CA какой-нибудь корпорации "добра".
А нормальный вариант - доверять самому себе. Ну и добавлять тех кому мы доверяем явно. С проверкой фингерпринта пятком разных методов по разным каналам (сколь-нибудь реалистичный атакующий не сможет перехватить их все, выполняемые в произольный момент времени). А когда предлагается доверять какой-то корпорахе которая мамой клянется - тут уже все понятно.
> Да, действительно всё просто. Но и в таком мизере кода ошибок можно
> совершить уйму. Для меня это просто факт, ибо сам программист.Я еще и посмотрел как этим пользоваться. И попользовался. В отличие от openssl - там просто на порядки меньше мест где можно дать маху. Для "просто кодеров" сделаны вызовы которые dead simple и не оставляют места для лажи. Если кто понимает что он хочет - может и на кусочки относительно высокоуровневый вызов разобрать. А тем кто не понимает что это и зачем - пара вызовов в которых просто негде облажаться. А вот openssl - эталонный пример того как библиотеку криптографии делать не надо. В смысле, хрен с два кто этот крап из апликушников поюзает секурно, а аудитить за всеми макаками код я могу и задолбаться. Особенно учитывая его количество потребное для секурного использования openssl.
> какой-то школьник и его репутация и работы говорят о многом, да
> и собственно софт который он делал.У него для начала групка криптографов по интересам. Он там не один. И по крайней мере он говорит логичные и дельные вещи. И компонует алгоритмы используя понятную мне логику, которая вроде как работает и никаких крутых атак на его алгоритмы вроде как и не нашлось. Ну и исторически он с его qmail и djbdns показал что можно даже на си написать очень секурные программы. То-есть гражданин реально разбирается в тематике и ему как-то так не повезло что его маловато слышат. Есть подозрение что это не совсем случайность.
> И не забывать о кол-ве людей делающий ревью кода. TLS или IPsec
> (о чём Шнайер и говорит) это конечно крайность где сложность такая
> что проще сказать что априори не безопасно.Именно. Сколько это не ревьювят - результат будет FAIL.
> где каждый волен пилить свои безопасные простые реализации которых будет под
> сотни и само собой речи о безопасности тоже не будет идти, уже как минимум из-за реализаций.В реализации например использующей nacl - облажаться довольно сложно: API сделан так чтобы им мог пользоваться даже не криптограф. В отличие от openssl где если вы не гуру от криптографии - то вас ждет два зиллиона грабель активных по дефолту.
> явно не буду доверять потому-что банально она не прожила N лет.
ИМХО это тyпой критерий. Софт не вино чтобы настаиваться. И насыщает не время в столовой а беляши. Так что со своей стороы лично я склонен смотрть на то есть ли попытки взлома от криптографов. Если есть и не особо результативные - хороший сигнал. Если есть и результативные - ну, по крайней мере мы честно узнаем свойства. А то что нечто валялось 20 лет под сyкнoм, никто это не изучал, но 20 лет прошло - вовсе не означает что алгоритм такой уж хороший лишь потому что прошло 20 лет и ничего не нашли. Вопрос еще в количестве тех кто искал и, главное, их квалификации.
> Они собираются всё-равно встроить ecdsa и прочее NIST-отравленное дерьмо.
Ну да. Зачем это - я не понял. Они не криптографы и делают странное. Но изначальное направление мысли - в правильную сторону имхо.
> отказаться от SSH совметимости и сделать более простой и ясный протокол.
Вот и у меня есть такое ощущение. OpenSSH давно стал блоатваре с кучей легаси и подпорок. И даже если забыть о дырах, стайка ботов возжелавших сделать брут без расстановки костылей адово клинит проц на публичной криптографии. Потому что всякие RSA и прочие - тормозные.
> доказано что они так же безопасны как старый добрый знакомый RSA.
Лично мне RSA как раз не нравится. Чтобы он был безопасным - надо огромные ключи которые считать упухнуть можно. И костыли с фингерпринтами потому что сами ключи - немеряные.
> изученный вопрос. А ECC слишком нова, недоказана что не имеет фатальных
> критических недостатков которые могут её свести на нетВ конечном итоге оба сводятся к математическим проблемам которые неплохо изучены. А у RSA есть ряд дурных проблем за которые я с ним лишний раз вообще связываться не желаю и на фоне 25519 на свой страх и риск считаю динозавром.
> Опять же кому как, но лично для меня ECC под вопросом ещё остаётся.
Тем не менее, я склонен считать что дядюшка Бернштейн сделал один из наиболее симпатичных мне вариантов Диффи Хеллмана которые я когда либо видел. И да, его либой можно например один сетевой пакет зашифровать. ОДИН, БЛИН. А слабо так с остальными? Без многоэтажных костыльных схем с посылкой дюжин пакетов? :)
> Более проверенный временем (по мне) протокол и криптография чем в 25519 как минимум.
Ну вон md5 тоже временем проверили. И sha1. Вот только результат проверки - не очень, а пользуются. "Потому что стандарт".
А что вы всё только в OpenSSL тычите? Я уже подчеркнул: OpenSSL это крайность, однако частенько куда более вменяемая чем куча поделок типа CryptoCat.> Я думаю что один Бернштейн легко заменяет сотню макак пишущих openssl. Так,
> глядя на плюхи которые они вешают. Я вообще не понимаю чего
> ради эти люди криптографическую либу писать полезли.Это ваше личное мнение, конечно же. Против Бернштейна у меня ничего нет. Но я вижу как работают Шнайеры и Фергусоны: они тоже делают ошибки. Для меня они бОльшие авторитеты чем Бернштейн. В OpenSSL много говн, но ещё больше в 99% остального софта которые пытается назваться крипто-что-то там. NaCl -- превосходен. Считаное количество (по пальцам посчитать) других библиотек или реализаций -- превосходны. Вот только их считанные единицы. Тьма других аналогично безграмотна. В вашем представлении, насколько погляжу, весь свет сходится на Бернштейне, ибо криптографы не пишут софт, по факту. Шнайер способен на C накодить алгоритм, но не законченную реализацию софта который можно запускать в UNIX-like (например) системах. Криптографы конечно знают про устройство ЭВМ, кэшей и прочего, но опять же людей вменяемо что-то могущих писать и понимать в криптографии как например тот же Тео Де Радт как-то единицы. Доверять паре человек и их реализациям -- я не стану, потому-что маловато их будет, опять же не проверены достаточно временем.
>> Для меня хороший вопрос что важнее и лучше.
> Я выбираю осмысленность действий индивидов. Нормальные криптографы это могут. А вот авторы
> openssl показали что у них не богато с довольно базовыми вещами...И где эти криптографы? Бернштейн есть. С ходу я никого больше не могу назвать. Zooko ещё (автора (одно из) BLAKE2). А вот больше как-то с ходу и не могу и знаю что те же разработчики Skein не шибко много делают реализаций (промышленных, а не неких эталонных).
> В случае криптографии одно не сильно далеко от другого. Более того -
> когда реализаторы лезут донавесить 100500 сервисных функций, как опенссл - можно
> налететь на тот факт что эти плюшки были с цианидом, тудыть
> их растудыть.Всё вы тычите в крайность в виде OpenSSL. Крайне не согласен что криптография от реализации в софте конкретной не далеко друг от друга. Далеко и ещё как. Поэтому в мире единицы пишущих код криптографов и тьма программистов не смыслящих в криптографии. Дальше уже не буду комментировать то что вы постоянно тычите в OpenSSL. Я не говорил что эта библиотека яркий пример того что ревью будет делаться и тому подобное и качественно. Но это и не означает что оно не будет делаться. ssl это крайность, как и ipsec, когда никто не захочет делать, а власти с законами требуют использовать хоть что-то. У меня свои требования и видение на то что я бы считал безопасным: пока я не доверяю в достаточной мере ECC и использовать lsh например в котором не ECC не будет -- я не буду. Тем более что они туда собираются встраивать и AES. Да и в любом случае по мне так это провальный проект который опять же тянет за собой совместимость с SSH-протоколом, отнюдь не простым и не очень. В SSH ни в какую нет наработок по аутентифицированным обмена ключей, одновременной двусторонней zero-knowledge аутентификацией: а ведь это всё идёт ещё с 80-х годов. Как-раз создаётся впечатление что это пишут люди как-раз не очень глубоко знающие криптографию и почему-то просто не затрагивающие превосходные хорошо исследованные наработки, кстати использующие всё же же известные примитивы. Разве что только lsh выделяется поддержкой SRP.
> Про это знают все нормальные криптографы. А вот то что про это
> в курсе какие-нибудь деятели типа авторов openssl - я бы за
> это зуб не дал.Мне кажется вы совершенно не знакомы с его кодом. Это там много где учитывается.
> MD5 тоже проверенный временем. Проверка показала: он г-но. Ну и sha1 туда
> же куда-то отправляется. Хотя про blowfish никакого особенно крутого криминала мне
> не известно так сходу. Но тут еще вопрос в том -
> а сколько человек проблемы искало?Думаю из-за своей старости и относительной простоты Blowfish излюбленный алгоритм для большинства кто собирается заниматься криптоанализом. MD5, SHA1, итд -- показали что говно. Dual-EC-чего-то-там показали что вообще неприменимое. А вот для меня совершенно не факт что в Salsa/Chacha ещё не найдут чего-то реально критичного сводящего на нет всю его безопасность, как и в 25519 и то что из-за него весь PFS идёт нафиг и смогут дешифровать ранее сохранённый трафик. Однозначно его будут и яро анализируют, но лично для меня должно пройти ещё время. А это годы, ведь и AES не сразу оказался поломанным (до какой-то степени конечно).
> См. выше. Логику построения salsa/chacha я более-менее понимаю и вижу криптоанализ. При
> том - с пониманием дела и даже "частично успешный". Это значит
> что алгоритм проверяли не какое-то сферическое время в вакууме а вполне
> себе криптографы, разбирающиеся в предмете и даже нащупавшие некие упрощения. А
> мнение 10 профессиональных криптографов - ценнее чем мнение 10 000 кодеров,
> не имеющих понятия о криптографии.Мнение кодеров меня тоже не волнует, а вот мнение 10 криптографов -- маловато. На полном серьёзе. AES анализировали многие годы явно больше 10 и не находили сильных подвохов.
> Если уж на то пошло, 25519 и прочие появились далеко не вчера.
> Вчера на них лишь обратили внимание из-за кризиса доверия к NIST
> и прочая.Я про них довольно давно знаю. Быстро начали проникать его реализации. Но по мне это всё ещё молодые алгоритмы и Бернштейн может ошибаться очень серьёзно где-то.
> Ну да. Если защита траффика нужна. Хотя честно говоря, прецедентов вскрытия WPA2
> если нет WPS и сложный пароль - мне не известно.Лучше не рисковать :-)
> Я считаю что доверяемая прошивка на роутере без явных ляпов мне все-таки
> друг и товарищ и потому предпочиаю openwrt, где все это реализовано
> не сильно архаичным линем и дровами из его комплекта.Я не доверяю конкретно самому алгоритму: он куда сложнее чем NaCl с cryptobox-ами его, плюс делали его люди с участием корпораций и госструктур, что априори вводит в недоверие.
> Тут еще вопрос в количестве изучавших и их квалификации. От того что
> миллион быдлoкодеров посмотрит в код - криптография лучше не станет. Потому
> что они в этом ни бум-бум. А вот если криптографы потратят
> время на серьезные попытки атак - совсем иное дело. Открытость кода
> необходима для аудита разными криптографами. Но вот то что качество этого
> аудита стопроцентно коррелирует со временем или числом глаз - не факт.
> Я склонен придавать вес еще и компетенции тех кто смотрел, этот
> параметр сам по себе не коррелирует с временем или количеством глаз.В том что Blowfish смотрели тьма профессиональных криптографов у меня сомнений нет. Кодеры не интересуют само собой. Компетенция глаз -- выше всего. Опять же для алгоритма. Но код криптографы смотреть не будут. Тут могут пригодится и быдлокодеры.
> И это одна из вещей которые мне в ssh не нравятся. Ксати
> если уж мы о птичках - идея завернуть ssh в hidden
> сервис тор имеет место быть и как минимум он здорово нагнет
> подобные инициативы, минимизировав полезность сведений за счет фиксированного размера
> cells.Либо "профиксить" SSH-протокол (добавить опцию?) чтобы он сам делал нужный padding. Хотя бы! Само собой просто минимальный размер или константный у всех пакетов это не панацея. Но в real-time штуках всегда так. В идеале кстати по мне так "шуметь" в канал. Надёжнее не бывает (ну кроме когда совсем связи нет), хотя и накладно. GNUnet всё ж выбирает безопасность/анонимность превыше всего и поэтому шум есть всегда и везде.
> У них фиксированный размер cells, насколько я помню. Он один на все.
> Шлете 1 байт? В провод полетит cell фиксированного размера. Как и
> на 20 байтов. Или на 100. Это достаточно неплохо нагибает подобный
> анализ. Хотя будучи low latency оно неизбежно утекает времянки.Ага, и я про это же.
> А там довольно компетентные авторы с неплохими идеями. Но вот реализация какая-то
> странная.GNUnet по мне так собрал вообще все наработки и всю теорию что с 90-х по середину 2000-х придумало человечество чтобы сделать убер-правильную сеть. Очень уважаю их. Но реализация не простая, даже поднять не просто бывает.
> Я не счтиаю что использование криптогрфии должно требовать квалификации ракетного инженера
> от эксплуатационщика. Такой подход обречен на провал.Либо вменяемый человек, либо тот который даже fingerprint не будет проверять и в качестве парольной фразы будет использовать 12345. По моему опыту как бы только "ракетные инженеры" способны выполнить хотя бы сверку fingerprint-а. Это конечно крайности, так быть не должно, но по факту либо это человек-ракетчик, либо тот кто тыкает ok на всё подряд.
> Булшит. Дяденька Бернштейн в его либах показал что хорошая безопасность - не
> синоним адового гемора. Вот этим либа сделанная криптографом понимающим проблематику отличается
> от либы которую писали какие-то лабухи не имевшие к криптографии никакого
> отношения.Ага. Именно поэтому Шнайер перестал в своих книгах советовать ну всем вот лучший CTR режим вместо CBC и теперь советует CBC, потому-что люди даже не в состоянии передавать ему nonce-ы которые бы не повторялись или чтобы люди не использовали ключи для потоковых шифров дважды. Чего может быть проще, почему люди не замечают на каждой странице крупным шрифтом что для потоковых шифров нельзя повторять ключ. В 90-х он рекомендовал CTR. Потом перестал ибо люди не могут сделать даже этого. Вот просто применить в правильном режиме шифр в котором два входа и один выхлоп (как любой AES, Blowfish, Twofish, whatever) это может быть сложно? cryptobox NaCl-овский как-то помогает. Но если брать его алгоритмы по отдельности, то я скажу что, нет... я гарантирую что Бернштейновские алгоритмы будут использоваться неправильно из-за большей сложности. В HMAC передают ключ и данные. В его Poly1305 ещё и nonce и прочее. В Salsa/ChaCha аналогично бОльшее количество входов. Они сложнее к пониманию. А люди даже обычный блочный шифр не в состоянии заюзать. Неправильно заюзанные потоковый шифр -- куда опаснее чем блочный. Ошибка имеет куда большую цену. И то что сейчас тьма людей-программистов начитавшись о прелестях Salsa/Chacha побегут её всюду реализовывать приведёт я уверен к большей катастрофичности из-за того что фигово будут это делать, из-за сложности алгоритмов. Бернштейн всё явно описал в своих довольно простых бумагах: как, что и почему, даёт советы. Но, повторюсь, просто Blowfish не могут использовать. И я солидарен с Шнайером что блин лучше пусть чего проще порекомендовать если это ориентируется быть чем-то широким к применению. Например VCAS шифрование для HLS тупое CBC с тупым padding-ом: нельзя распараллелить (хотя для декодирования довольно приличного видеопотока было бы полезно ещё как), но зато это можно реализовать всем быдлокодерам. Salsa сложнее и это пусть создаст код с меньшим количеством чисто программных багов (из-за его размеров), зато с большим количеством, так сказать, архитектурных (когда ключ resuse-атся будет). cryptobox вот простой, но не эффективный если его фигачить на каждый отправляемый TCP-пакет например. Надёжно, но сомневаюсь что старый Blowfish с старым HMAC-RIPEMD160 будет медленнее, а надёжность у них для меня выше.
>> Если кто-то хочет чтобы легко и просто -- будет не безопасно :-).
> Нет никаких законов природы которые бы делали неизбежным такой tradeoff.Нет, но факт остаётся фактом что даже CTR криво делают или CBC в SSH-е где утекает plaintext.
> А нормальный вариант - доверять самому себе.
Согласен. Но люди не хотят ответственности. Хотят просто, легко и чтобы не париться.
>[оверквотинг удален]
> openssl - там просто на порядки меньше мест где можно дать
> маху. Для "просто кодеров" сделаны вызовы которые dead simple и не
> оставляют места для лажи. Если кто понимает что он хочет -
> может и на кусочки относительно высокоуровневый вызов разобрать. А тем кто
> не понимает что это и зачем - пара вызовов в которых
> просто негде облажаться. А вот openssl - эталонный пример того как
> библиотеку криптографии делать не надо. В смысле, хрен с два кто
> этот крап из апликушников поюзает секурно, а аудитить за всеми макаками
> код я могу и задолбаться. Особенно учитывая его количество потребное для
> секурного использования openssl.OpenSSL -- повторюсь, согласен, делать не надо такое. NaCl будут юзать коряво, с криптогрфической точки зрения.
> В реализации например использующей nacl - облажаться довольно сложно: API сделан так
> чтобы им мог пользоваться даже не криптограф. В отличие от openssl
> где если вы не гуру от криптографии - то вас ждет
> два зиллиона грабель активных по дефолту.Не согласен. Уже выше написал. Примитивов меньше, а сами по себе они сложнее. Даже если и не сложнее, то всё-равно их так же не правильно будут юзать как и не в состоянии сделать Blowfish-CTR допустим. NaCl не предоставляет протоколов как-таковых. Ошибки и засады делают почти всегда не в алгоритмах шифрования, а том что касается банальной рутины типа обработки сообщений. NaCl тут не поможет. Разве что кроме того что сам сделает проверку MAC-а, ибо написано это будет Бернштейном. Интересно: один Бернштейн получается способен просто нормально отвалидировать MAC? Очевидно что нет. NaCl это низкоуровневые примитивы которых грамотно реализованых в том же libgcrypt полно. По поводу протоколов он не поможет, а ломают в первую очередь их.
> ИМХО это тyпой критерий. Софт не вино чтобы настаиваться.
IMHO это основной критерий. По мне так нет ничего глупее чем криптограф выпускает свой убер-алгоритм, за пару недель его ревьювят с десяток Шнайеров с Фергуссонами и круто его можно использовать. Вроде бы история с MD5, SHA1, AES показала что нужны многие годы чтобы нашёлся тот самый криптограф который надёт жопу. Вы считаете что тот же Blowfish или RIPEMD видимо просто мало криптоанализировали: это просто ваше заблуждение. Уж что MD5 с AES-ом криптоанализировали постоянно я думаю сомнений быть не должно. Сколько долгих лет понадобилось чтобы найти фатальные недостатки? Тот же Адм Шамир и Эли Бихам вроде бы только и делают что занимаются криптоанализами постоянными самого разного: какие-то алгоритмы взламывают через несколько часов после их выхода, какие-то годами. Этот критерий не вижу смысла обсуждать или доказывать, так как по мне тут всё очевидно и история показала неоднократно. Те же методы анализа для DES через сколько десятилетий появлялись которые то так, то эдак его позволяли ломать? Само собой например Serpent или возможно CAST на порядки меньше трогали криптографы, и это можно отнести к 20 лет тому кто никто не трогал. Но Blowfish не просто так внедряется в кучу софта, хотя Шнайер давно уже советует использовать Twofish, которые тоже свободен к приминению. (CAST конечно по политике). Ну и мне кажется вы как-то мало хотя бы просто публикаций смотрите (хотя бы заголовки) с того же iacr.org. Известнейшие криптографы (Бихамы и Шамиры регулярно видел) и криптоаналитики просто регулярно штампуют исследования и подходы даже к старью.
> Ну да. Зачем это - я не понял. Они не криптографы и
> делают странное. Но изначальное направление мысли - в правильную сторону имхо.Вот у меня уже впечатление что просто прочитали какой у Бернштейна всё быстрое и ещё не сломанное и внедрили первым, плюс код простой. А дальше раскрыли свою суть что в целом пофиг на безопасность и NIST. Всё как я и "предсказал" параграфами выше: толпы пойдут реализовывать потоковые шифры Бернштейна, которые использовать сложнее.
> Лично мне RSA как раз не нравится. Чтобы он был безопасным -
> надо огромные ключи которые считать упухнуть можно. И костыли с фингерпринтами
> потому что сами ключи - немеряные.Медленно ещё как, трафика ещё как. Но если на другой чаше весов ещё фигово проверенные в бою ECC -- мой выбор за RSA, старый недобрый но надёжный. Если есть под рукой доверяемая реализация.
> В конечном итоге оба сводятся к математическим проблемам которые неплохо изучены. А
> у RSA есть ряд дурных проблем за которые я с ним
> лишний раз вообще связываться не желаю и на фоне 25519 на
> свой страх и риск считаю динозавром.Всё относительно. По мне так ECC ещё не доказано что полностью сводится к проблемам нахождения точек на кривых. Возможно докажут и можно разжать булки. Возможно не докажут, но и обратного утверждения нет. А возможно уже всякие NIST и ФСБ знают чего-то, до чего Шнайеры с Бернштейнами не дошли. Ведь Dual-ECDRBG не сразу "раскрылся". Сколько его использовали и сколько PRNG фактически не работали в мире? ECC пока для меня (опять же для меня) тёмная лошадка: что надо конкретно обезопасить я делаю с RSA, а всякие сессии до серверов где работа или домашняя утварь: ради уж производительности на 25519.
> Тем не менее, я склонен считать что дядюшка Бернштейн сделал один из
> наиболее симпатичных мне вариантов Диффи Хеллмана которые я когда либо видел.Это вне всяких сомнений. Среди ECC и потоковых шифров: реально неоспоримо.
> И да, его либой можно например один сетевой пакет зашифровать. ОДИН,
> БЛИН. А слабо так с остальными? Без многоэтажных костыльных схем с
> посылкой дюжин пакетов? :)Ой вот сомневаюсь что долго будет жить сам по себе софт в котором нет никакого протокола :-). Я вот даже для себя писал VPN с 25519/salsa20/poly1305 и без всяких cryptobox-ов весь код уходит на протокол. А все ошибки будут только и только в нём, а не в примитивах низкоуровневых. https://github.com/stargrave/govpn
> Ну вон md5 тоже временем проверили. И sha1. Вот только результат проверки
> - не очень, а пользуются. "Потому что стандарт".25519 ещё и не проверили так же дотошно, а пользуются даже несмотря на то что стандарт :-)
> А что вы всё только в OpenSSL тычите?А то что SSL/TLS один из наиболее массовых вариантов шифрования. И самых грабельных.
> Я уже подчеркнул: OpenSSL это крайность,
Примеры НеКрайностей можно?
> однако частенько куда более вменяемая чем куча поделок типа CryptoCat.
TLS пожалуй даже хуже чем это. Ну то-есть чрезмерного доверия этот кус вебни не вызывает. С другой стороны, сложно сказать что он принципиально хуже большинства иного софта.
> Это ваше личное мнение, конечно же.
Оно основано на наблюдениях кто и что делает и как это потом работает.
> Против Бернштейна у меня ничего нет.
> Но я вижу как работают Шнайеры и Фергусоны: они тоже делают ошибки.Тут вопрос в компетентности. Те кто компетентен в своей области - лажают редко. А те кто не компетентен - сажают глупые ошибки там и тут. Просто потому что не знают (или не задумываются) о том что это несет какие-то последствия. У криптографа должен быть определенный набор личных качеств. Умение думать и способность параноидально просчитывать разные ситуации. Иначе ничего хорошего не жди.
> Для меня они бОльшие авторитеты чем Бернштейн.
Каждый человек имеет выбор. А потом выбор имеет человека. Я считаю что увиденного мной было достаточно для дискредитации авторов OpenSSL в плане квалификации и TLS как протокола.
> В OpenSSL много гoвн,
Он целиком г-но. От переусложненного протокола до грабельной реализации и дурного апи с дефолтами выбранными левой пяткой и кучи легаси.
> но ещё больше в 99% остального софта которые пытается назваться крипто-что-то там.
Сдалать хуже чем ssl - надо крепко постараться. Пора уже это признать - АНБ успешно накормили мир г-ном.
> библиотек или реализаций -- превосходны. Вот только их считанные единицы.
Ну да, придется разбираться в сортах и кто за кого держит. И?
> на C накодить алгоритм, но не законченную реализацию софта который можно
> запускать в UNIX-like (например) системах.Бернштейн тоже NaCl написал своеобразно. Но осознал ошибки и сделал TweetNaCl, мелкий и легко встраиваемый куда угодно.
> как-то единицы. Доверять паре человек и их реализациям -- я не стану,
Что-то не хочется доверять толпе обезьян с гранатами по типу openssl.
> потому-что маловато их будет, опять же не проверены достаточно временем.
Как сказано в китайской поговорке - насыщает не время проведенное в столовой, а количество съеденных беляшей. А про это вы ничего не сказали.
> разработчики Skein не шибко много делают реализаций (промышленных, а не неких эталонных).
А "промышленности" подсунули "секурный" крап типа ssl. Кушайте г-но в промышленных масштабах.
> Всё вы тычите в крайность в виде OpenSSL.
А во что бы тыкали вы?
> Крайне не согласен что криптография от реализации в софте конкретной не далеко друг от друга.
ИМХО зависит от.
> что эта библиотека яркий пример того что ревью будет делаться и
> тому подобное и качественно.Это яркий пример того что ваша толпа обезьян с гранатами мало что решают. Оно с нами давно, сорцы есть. А крЮтые плюхи находят через много лет после того как это появилось. И еще найдут. Много и злых.
> считал безопасным: пока я не доверяю в достаточной мере ECC и
> использовать lsh например в котором не ECC не будет --А как по мне - так я лучше буду доверять Бернштейну и его ECC, чем RSA. У той же RSA было много неудачных или в лучшем случае заурядных алгоритмов на которые они не забывали давиться жабой. И dual ec с бэкдором они продавали.
> я не буду. Тем более что они туда собираются встраивать и AES.
Они - кто? Те перцы с мелким ssh серваком? Это было лишь как пример мышления в правильном направлении.
> поддержкой SRP.
Я опять же не особо понимаю чем этот SRP так хорош. Его как-то агрессивно сватают без внятных аргументов за. Мне это не нравится.
> Мне кажется вы совершенно не знакомы с его кодом. Это там много
> где учитывается.Мне кажется что я в состоянии прочитать матюки авторов Tor в ченжлоге на такую подставу в поведении openssl. Им пришлось ЯВНО ВОРКЭРАУНДИТЬ это западло.
> Думаю из-за своей старости и относительной простоты Blowfish излюбленный алгоритм для большинства
> кто собирается заниматься криптоанализом.Одного взгляда на оный достаточно для того чтобы понять что cache timing и его скорее всего пробирают от души. А еще там слабые ключи нашлись. Хилые аргументы "за".
> Dual-EC-чего-то-там показали что вообще неприменимое.
Ну так это ж NIST. По этому поводу NISTовским кривым я доверять не буду. Мало ли как они их там выбирали. А вот DJB рассказал откуда взялся 25519.
> что в Salsa/Chacha ещё не найдут чего-то реально критичного сводящего
> на нет всю его безопасность,Поскольку Бернштейн криптограф, кучка народа компетентного в области это добро проанализировали и предствили результаты. Ну то-есть у них есть не время проведенное в столовой, а, собственно, беляши. Для меня это аргумент.
> как и в 25519 и то что из-за него весь PFS идёт нафиг и смогут дешифровать ранее
> сохранённый трафик.Возможно, но с другой стороны это же теоретически может случиться и для RSA. С другой стороны RSA тормозной и у него огромные ключи (при желании хоть какой-то надежности). А криптография - о том чтобы заменить большой секрет маленьким. RSA на больших ключах так тормозит, что для получения приемлимой скорости часто жертвуют стойкостью. Прозрачные намеки DJB на то что у "спецов по безопасности" - ключ RSA всего 1024 бита. Больше видите ли тормозит. А у DJB стойкость на уровне RSA 2048, при скорости многократно выше RSA 1024.
> Однозначно его будут и яро анализируют, но лично для меня должно пройти ещё время.
Он появился не вчера и прямо под носом толпы криптографов. При том относительно независимых, а не прикормленных, как NIST.
> А это годы, ведь и AES не сразу оказался поломанным (до какой-то степени конечно).
С точки зрения криптографической стойкости самой по себе - к AES до сих пор нет больших претензий. Но вот сама схема с таблицами как минимум проблемна в современных реалиях с многозадачными многопользовательскими системами и тем более контейнерами/виртуалками. Более того, репорт от NIST утверждающий что эти операции завершаются за постоянное время или некомпетентен или специально врет. Оба варианта NIST не украшают.
> Мнение кодеров меня тоже не волнует, а вот мнение 10 криптографов -- маловато.
Криптография штука сложная и компетентных криптографов не так уж и много. Так что 10 человек которые предприняли реально хороший криптоанализ - достаточно прилично. И некие результаты будут. Бернштейн опубликовал таковые. Там нашлись атаки на ослабленный вариант, но ничего практически значимого.
> На полном серьёзе. AES анализировали многие годы явно больше 10
> и не находили сильных подвоховКроме его табличной сущности и возможности в результате умыкнуть ключ на половине конфиг. И вранья от NIST про это.
> Я про них довольно давно знаю. Быстро начали проникать его реализации. Но
> по мне это всё ещё молодые алгоритмы и Бернштейн может ошибаться очень серьёзно где-то.Древность алгоритма не влияет на наличие или отсутствие в нем ошибок. А на поиск ошибок влияет количество компетентных криптографов сунувших туда нос. Бернштейн достаточно известен в кругу криптографов - на его художества посмотрит толпа народа. Более того - все эти алгоритмы взяли в ssh. И вы уж извините, но если авторам ssh нормально, а какому-то чудаку с опеннета нет - я как-нибудь им и DJB больше верю.
>> если нет WPS и сложный пароль - мне не известно.
> Лучше не рисковать :-)С этим не поспоришь - ценные данные лучше по проводу или с добавочным шифрованием.
> делали его люди с участием корпораций и госструктур, что априори вводит в недоверие.
Ну да. С другой стороны фундаментальных проблем пока вроде не нашли. И нахрапистый внедреж бэкдорообразного WPS и инженерных паролей наводит на мысль что случайно вышло слишком стойко для произвольного вламывания в сеть за обозримое время.
> В том что Blowfish смотрели тьма профессиональных криптографов у меня сомнений нет.
Ну так они и нашли там слабые ключи, http://www.iacr.org/archive/fse2007/45930168/45930168.pdf Ну и опять нечто с s-box. На это забил даже автор - см threefish.
> Кодеры не интересуют само собой. Компетенция глаз -- выше всего. Опять
> же для алгоритма.Так возможность за разумное время прочитать алгоритм и все что вокруг и позволяет проверить что все честно. А навали кучу хлама как в openssl или ssh, с кучей костылей, легаси и прочее - да там чтобы въехать надо месяц убить. Желающих это читать будет мало. Особенно среди криптографов.
> Тут могут пригодится и быдлoкодеры.
Они ничего не смыслят в применении криптографии и даже просто безопасности. Толку с них?
> Либо "профиксить" SSH-протокол (добавить опцию?) чтобы он сам делал нужный padding.
Может быть. Но ssh уже обвешан костылями и легаси как собака блохами. Когда фича опциональна - плохо. Админ не в курсе на что он может рассчитывать если видит "вот это соединение".
> кстати по мне так "шуметь" в канал. Надёжнее не бывает
Это было бы хорошо, в плане затруднения анализа активности админа на машине.
> GNUnet всё ж выбирает безопасность/анонимность превыше всего и поэтому шум есть всегда и везде.
У них есть немало интересных изобретений/наработок, не отнять.
> Очень уважаю их. Но реализация не простая, даже поднять не просто бывает.
Реализация у них получилась странная. Но ряд идей у них очень интересные.
> Либо вменяемый человек, либо тот который даже fingerprint не будет проверять
Любого неглупого человека можно попросить проверить fingerprint. Хотя в 25519 это излишне - размер ключа позволяет прямое указание ключа вместо fingerprint.
> По моему опыту как бы только "ракетные инженеры" способны выполнить хотя бы сверку fingerprint-а.
Имеется опыт объяснения этой операции чайниковатым юзерям.
> человек-ракетчик, либо тот кто тыкает ok на всё подряд.
Этот мир не черно-белый. Между полюсами немало градаций.
> даже не в состоянии передавать ему nonce-ы которые бы не повторялись
У DJB размер nonce таков что можно даже просто random. И, заметим, про nonce все предельно четко и подробно расписано.
> или чтобы люди не использовали ключи для потоковых шифров дважды.
Практически существующие схемы обычно это учитывают.
> быть сложно? cryptobox NaCl-овский как-то помогает.
Ну да, апи для совсем не криптографов, требований минимум, сущности простые, понятные и логичные.
> Но если брать его алгоритмы по отдельности, то я скажу что, нет... я гарантирую
> что Бернштейновские алгоритмы будут использоваться неправильно из-за большей сложности.Составные части - для тех кто понимает что и зачем он делает.
> даже обычный блочный шифр не в состоянии заюзать. Неправильно заюзанные потоковый
> шифр -- куда опаснее чем блочный. Ошибка имеет куда большую цену.Поэтому для таких людей есть cryptobox.
> И то что сейчас тьма людей-программистов начитавшись о прелестях Salsa/Chacha побегут
> её всюду реализовывать приведёт я уверен к большей катастрофичностиЛюбую криптографию можно профакапить некомпетентностью.
> описал в своих довольно простых бумагах: как, что и почему, даёт советы.
Основная его заслуга - апи для чайников, с нормальной подборкой дефолтов и алгоритмов. Есть несколько простых требований понятных любому кодеру средней руки. Если эти требования выполнены - при использовании этих апи все будет ОК. А обезьяна с гранатой - это всегда обезьяна с гранатой.
> Но, повторюсь, просто Blowfish не могут использовать.
Blowfish морально устарел и никакого смысла в нем имхо нет.
> приличного видеопотока было бы полезно ещё как), но зато это можно
> реализовать всем быдлoкодерам.Бернштейн имхо в этом правее: таким людям *нечего* делать в низкоуровневых деталях алгоритмов. Таким надо апи по типу криптобокса. Это он очень правильно заметил.
> Salsa сложнее и это пусть создаст код с меньшим количеством чисто программных багов (из-за его размеров),
У DJB есть либа. У нее есть вызовы, которые если дергать как описано - все будет ок. А вручную заморачиваться с salsa есть смысл только для тех кто знает что это, зачем и как это правильно применять. А обычные апликушники должны дергать криптобокс, а вовсе не.
> например. Надёжно, но сомневаюсь что старый Blowfish с старым HMAC-RIPEMD160 будет
> медленнее, а надёжность у них для меня выше.Вот вы ими и пользуйтесь. А мне как-то неохота греть мозг вопросом "а что еще может работать на том же процессоре".
> в SSH-е где утекает plaintext.
И дофига информации о характере траффика. Если некто смог угадать что там передавали по параметрам траффика - толку то с шифрования?
> Но люди не хотят ответственности. Хотят просто, легко и чтобы не париться.
Для таких и сделано апи в духе криптобокса.
> NaCl будут юзать коряво, с криптогрфической точки зрения.
Для тех кто не Шнайер - есть криптобокс. И там если следовать нехитрым правилам из коротенькой инструкции - все будет ок. Если кто не может даже это - пусть идет выращивать овощи. Кому надо симметричное шифрование - там и для него есть похожий вызов. А если кто полез в детали и лоханулся - так обезьян с гранатой лучше обойти сторонкой.
> Не согласен. Уже выше написал. Примитивов меньше, а сами по себе они сложнее.
Еще раз: апликушники должны дергать cryptobox и не должны париться какие там алгоритмы. Возможность дергать составные части - для тех кто в курсе что это и как этим пользоваться.
> не правильно будут юзать как и не в состоянии сделать Blowfish-CTR допустим.
Апликушники понятия не имеют что такое CTR и чем он отлчиается от других режимов. Им надо простой вызов - зашифровать от забора и до обеда, вон тем ключом. Бернштейн просек это дело и дал им именно такое апи.
> NaCl не предоставляет протоколов как-таковых.
В данном случае фокус в том что по сути люди могут просто шифровать криптобоксм порцию данных и кидать в провод. На том конце провода или криптобокс расшифруют их, или они получат ошибку. Просто, эффективно, работает. Базовый кирпичик шифрования в сети.
> NaCl это низкоуровневые примитивы которых грамотно реализованых в том же libgcrypt
> полно. По поводу протоколов он не поможет, а ломают в первую очередь их.NaCl - это базовый кирпичик для передачи данных в шифрованном виде с использованием публичных или симметричных ключей. С апи которое обычные апликушники могут использовать не наломав дров. Продвинутости - не для них.
> IMHO это основной критерий.
Тогда шифр Цезаря FTW.
> выпускает свой убер-алгоритм, за пару недель его ревьювят с десяток Шнайеров
> с Фергуссонами и круто его можно использовать.Упомянутые алгоритмы существуют как минимум несколько лет. И да, вы знаете, по ходу пьесы всплывают разные нюансы, типа возможности реконструкции ключей по состоянию кэша. И это приходится дорабатывать на ходу. А в вашем настое это ТАК И ОСТАНЕТСЯ. И даже те кто оригинал blowfish делал - признали ошибки, "наследник" threefish - без s-box. Но куда там Шнайеру и его работе над ошибками до ваших догм про настой.
Вот лично я предпочитаю видеть осмысленное и поддающееся логическому пониманию конструирование алгоритмов. А догмы высосанные из пальца - не ко мне.
> Вроде бы история с MD5, SHA1, AES показала что нужны многие годы
Про MD5 уже через пару лет после его выхода была критика и предлагали списать в утиль. Но вылезли удоды вякавшие про скорость и стандарты и заглохди лишь когда массово поперли коллизии. Да и с AES предъявы к таблицам были давно по части кэшей. Но всякие "умники" зачем-то втюхивают алгоритмы с неочевидными проблемами, накладывающими много ограничений на область применения. Всего ничего: возможность для соседнего процесса/вм/контейнра упереть ключ.
> самый криптограф который надёт жщпу.
В md5 ее нашли быстро. Но любителей "стандартов" это не остановило. Им понятен только pwnage.
> Вы считаете что тот же Blowfish или RIPEMD видимо просто мало криптоанализировали:
Я уточнил. Blowfish криптоанализировали. И нашли проблемы. Да что там, даже я их вижу - пачка s-box это отрыв от современных реалий и пофигизм на проблемы эксплуатационщиков.
> это просто ваше заблуждение.
А может ваше? Я существо рациональное. Мне нормальные аргументы подавай и внятную логическую цепочку. А этого я не вижу. В частности ваши сведения про AES и MD5 имхо неверны. И грабли в blowfish видят все. Даже его автор. Который (совместно с еще рядом людей) сделал работу над ошибками. Threefish называется.
> Сколько долгих лет понадобилось чтобы найти фатальные недостатки?
Мало. Про md5 предупреждения о его фиговых свойствах появились довольно быстро. То что до некоторых как до жирафов доходило и понадобилось чтобы конкретно бомбануло - второй вопрос. И грабли с утечкой через кэш - штука не новая. Но NIST их почему-то проигнорировал. Еще и соврали про постоянное время. Подозрительная некомпетентность.
> через несколько часов после их выхода, какие-то годами.
С основателями RSA все довольно интересно. Как-то так оказалось что большинство их алгоритмов - гэ. И вообще, RSA - контора которая единственная обнаглела и подсунула клиентам пробэкдоренный Dual EC :).
> очевидно и история показала неоднократно.
Похоже на слепое следование ничем не обоснованной догме, если не подтасовку фактов.
> Те же методы анализа для DES через сколько десятилетий появлялись
Многие криптографы сказали еще на момент принятия DES что его сломают. Просто потому что ключ короткий. Время лишь показало что они были правы. Но предупреждения о том что ключ 56 битов мало были буквально на момент принятия. То что до некоторых долго доходит, а железо стало практичным для этого не сразу - не вина криптографов.
> Но Blowfish не просто так внедряется в кучу софта,
MD5 или даже Dual EC тоже внедряется, а openssl вообще везде. И?
> хотя Шнайер давно уже советует использовать Twofish,
...и принял участие в создании threefish. Который работа над ошибками. В частности - никаких s-box! И чего бы это вдруг? Ах, он тоже догадался что утекать состояние через кэш - хреновая идея :). Но вы цепляйтесь, изгибайтесь буквой зю, ставьте 100500 условий где это нельзя пользовать. Ведь грабли хороши именно тогда, когда про них забыли и они все-таки е...ли по лбу.
> того же iacr.org. Известнейшие криптографы (Бихамы и Шамиры регулярно видел) и
> криптоаналитики просто регулярно штампуют исследования и подходы даже к старью.Там у них как раз вон дока с описанием слабых ключей blowfish. А Шнайер пошел переделывать алгоритм, чтобы не утекал данные через кэш. Для него это аргумент, в отличие от вас. Но если хочется упереться рогом - можно использовать и устаревший алгоритм и греть себе мозг отсевом слабых ключей и вопросами что еще запущено на том же CPU. Дело хозяйское. А мне так не нравится.
> Вот у меня уже впечатление что просто прочитали какой у Бернштейна всё
> быстрое и ещё не сломанное и внедрили первым, плюс код простой.Скорее, почитал и подивился что довольно разумно сделано, либа удачно подогнана, алгоритмы скомпонованы с умом и попытками избежать типичные грабли предшественников при хороших свойствах (качественная диффузия не в ущерб скорости). Но все юзают какой-то проблемый кривой шит или как минимум алгоритмы вызывающие вопросы. На мое персональное мнение DJB здорово недооценен по целому ряду пунктов (еще он мнение про IPv6 высказывал). Что характерно, хуже от этого будет в основном не ему.
> А дальше раскрыли свою суть что в целом пофиг на безопасность и NIST.
NIST себя делом дискредитировал. Dual EC DRBG с бэкдором кто стандартизировал? А RSA всучили его клиентам. Ну вы как бы пользуйтесь софтом от RSA, по стандартам NIST - идеальный шторм! :).
> Всё как я и "предсказал" параграфами выше: толпы пойдут
> реализовывать потоковые шифры Бернштейна, которые использовать сложнее.Им не надо никуда ходить - Бернштейн вывесил для таких готовое апи. И им совершенно незачем лезть в низкоуровневые детали, если они в них не разбираются.
> ещё фигово проверенные в бою ECC -- мой выбор за RSA, старый недобрый но надёжный.
Вообще-то из за тормозливости надежность часто приносят в жертву. В том числе в DNSSEC. Который судя по всему еще одна бесполезная декорация по типу SSL будет.
> Если есть под рукой доверяемая реализация.
Никакая реализация не меняет общие свойства алгоритма. RSA слоупочное нечто, которому для надежности нужны немеряного размера ключи. Которые сложно передавать и поэтому надо костыли с фингерпринтами. Ибо 2048-битный ключ фиг надиктуешь по телефону, в отличие от 256-битного.
> Всё относительно. По мне так ECC ещё не доказано что полностью сводится
> к проблемам нахождения точек на кривых.А к чему еще оно может сводиться? Ну кроме случаев явного бэкдоринга.
> уже всякие NIST и ФСБ знают чего-то,
Так они это могут знать про AES или RSA. Впрочем про них и так все знают что AES течет ключи через кэш а RSA при нормальном уровне безопасности тормознут до некомфортных величин. Что нагибает ряд применений, как с DNSSEC, где по причинам производительности выбран короткий ключ.
> до чего Шнайеры с Бернштейнами не дошли.
У Шнайера и Берштейна есть жирный плюс: они не были замечены в западлостроительной активности. В отличие от RSA и NIST, например.
> Ведь Dual-ECDRBG не сразу "раскрылся". Сколько его использовали
> и сколько PRNG фактически не работали в мире?Ну да, NIST успел стандартизировать а RSA - втюхнуть клиентам. Такие вот стандартизаторы и криптоаналитики.
> что надо конкретно обезопасить я делаю с RSA, а всякие сессии до серверов где работа
> или домашняя утварь: ради уж производительности на 25519.ИМХО, тезис о том что RSA безопаснее чем нечто еще - вилами по воде писан.
> Это вне всяких сомнений. Среди ECC и потоковых шифров: реально неоспоримо.
Вообще worldwide. Так можно послать ОДИН ПАКЕТ. Без хэндшейков и прочего. Сетевое шифрование должно было быть каким-то таким с самого начала.
> Ой вот сомневаюсь что долго будет жить сам по себе софт в
> котором нет никакого протокола :-).Смотря что от него надо. Cryptobox обеспечивает защиту и неподделываемость пакета. Если ремота может его расшифровать - это пакет который сформировал отправитель. С другой стороны, поскольку это по факту DH, из половинки приватного и публичного ключа, но разные половинки с разных сторон линка - получатель знает shared секрет и может произвольно подделывать содержимое. И не может доказать что ему это прислали а не он сам это сгенерил.
В чем круть? В том что зная 32 байта можно пульнуть сообщение которые расшифрует только обладатель парного им привкея и у него будут гарантии что это сформировал обладатель вон того пубкея. Все это дает ряд интересных возможностей о которых вы, вероятно, никогда не задумывались. Например, обмен ЕДИНИЧНЫМИ ПАКЕТАМИ. DH без хэндшейка? Почему бы и нет?
Универсальная верификация и шифрование 32 байтами - публичным ключом, влобовую. Из очевидных вещей - надо защиту от реплея. Если надо. Ну там timestamp или sequence number. Ну и PFS прикрутить. Несложно сделать путем перекидывания сообщениями с новыми ключами в обе стороны линка. А аутентичность сторон гарантирована на уровне устройства сryptobox.
Т.е. почти нахаляву можно отбабахивать P2P-style протоколы где peer однозначно идентифицирован 32 байтами. Да еще по сути без handshake.
> протокол. А все ошибки будут только и только в нём, а
> не в примитивах низкоуровневых. https://github.com/stargrave/govpnНе очень понятен смысл в PSK при том что с каждой из сторон линка можно было бы просто добавлять долговременый публичный ключ противоположной стороны как "доверяемый" (в конфиг, etc). Он и ключ шифрования (как минимум для начала сессии) и замена fingerprint. Для повышенной анонимности передавать публичные ключи сторон опционально: можно их неявно подразумевать на основе например прописаных в конфиге, etс (можно и более интересные варианты придумать). Ну и PFS разумеется - сделать пару временных ключей с каждой стороны и перекинуть в начале сессии в первых сообщениях новые публичные ключи. Судя по всему получается похоже по смыслу на то что у вас, только с другого бока и можно готовый cryptobox юзануть. Такой вариант чем-то плох?
> 25519 ещё и не проверили так же дотошно, а пользуются даже несмотря
> на то что стандарт :-)А какой 25519 стандарт? Его кто-то успел стандартизировать?
> Примеры НеКрайностей можно?Некрайностей в смысле того что это в состоянии люди посмотреть в плане ревью? GnuTLS.
>> однако частенько куда более вменяемая чем куча поделок типа CryptoCat.
> TLS пожалуй даже хуже чем это. Ну то-есть чрезмерного доверия этот кус
> вебни не вызывает. С другой стороны, сложно сказать что он принципиально
> хуже большинства иного софта.Ну… понятно: у вас хуже TLS как протокола и реализации в виде OpenSSL нет. Понятно. CryptoCat для меня на данный момент ярчайший пример того как людям вообще не стоило даже задумываться о том чтобы что-то делать с криптографией. Его создатели явно в принципе ничего не читали похоже и сделали чуть ли не всё что только можно неправильно и орут какой он у них красивых. Как протокол собственно сам SSH без "-etm@openssh.com" для меня гораздо хуже и не продуманее: они сделали так, как делать нельзя. Им немного это простительно потому-что тогда были времена в которые не столь хорошо всё ещё изучили. С точки зрения реализации конкретно TLS я знаком с OpenSSL и GnuTLS: второй однозначно мой выбор, но увиденное в первом оставляет куда лучшее впечатление от cryptocat-ов.
> Каждый человек имеет выбор. А потом выбор имеет человека. Я считаю что
> увиденного мной было достаточно для дискредитации авторов OpenSSL в плане квалификации
> и TLS как протокола.TLS сложный, как и всё что делается коммитетами. Но у меня нареканий как к протоколу (кроме сложности) не много. Опять же разве что только MAC делается не в виде -etm. А дальше реализации во всём виноваты.
> Сдалать хуже чем ssl - надо крепко постараться.
Сложнее чем TLS могу показать: IPsec. Хуже с криптографической точки зрения: тьма протоколов о которых мало кто знает, о которых знают например SSHv1, SSHv2 без -etm, cryptocat.
> Как сказано в китайской поговорке - насыщает не время проведенное в столовой,
> а количество съеденных беляшей. А про это вы ничего не сказали.В моём мире подразумевается что в столовой не сидят без дела, а едят беляши :-). Всякие Blowfish и прочие до сих пор берутся для "тренировок".
> А "промышленности" подсунули "секурный" крап типа ssl. Кушайте г-но в промышленных масштабах.В промышленности никто никого не заставлял юзать конкретно OpenSSL. Для вас TLS и как протокол на бумаге ужасен, но для меня нет.
> А во что бы тыкали вы?
Ну допустим в OpenVPN вот. Кода там много не касающегося крипто, но само крипто можно посмотреть. Простое и грамотное. Ревью проводилось.
> А как по мне - так я лучше буду доверять Бернштейну и
> его ECC, чем RSA. У той же RSA было много неудачных
> или в лучшем случае заурядных алгоритмов на которые они не забывали
> давиться жабой. И dual ec с бэкдором они продавали.Под RSA я подразумевал только конкретно RSA алгоритм, а не компанию. Этой компании я тоже не доверяю, особенно после dual-а. Хотя… там работают очень и очень крутые криптографы. Кстати нет гарантий что Бернштейн давно куплен и недаром даже Google проталкивает (или уже даже в Chrome реализовала) chacha/poly в TLS. С одной стороны Google может это делать чтобы казаться хорошей, ведь данные она же сливает АНБ/ФСБ уже из датацентров или в линках между ними (которые не шифрованы), с другой стороны может в этом потоковом шифре есть что-то о чём многие не знали как и в случае с Dual-ом. Хотя вроде Бернштейну стоит больше доверять чем Шнайеру, ведь тот же тоже вроде как засветился работой на оборонку.
> Они - кто? Те перцы с мелким ssh серваком? Это было лишь
> как пример мышления в правильном направлении.В корне не согласен что у них правильное направление. Уверен что chacha/poly выбрали из-за скорости и простоты, а ecdsa показал что это только показалось что они "правильные". Вообще не признаю я их уже.
> Я опять же не особо понимаю чем этот SRP так хорош. Его
> как-то агрессивно сватают без внятных аргументов за. Мне это не нравится.Ну я там написал что из-за экономии ресурсов, как минимум. Я бы посоветовал просто посмотреть на страничку его родную: http://srp.stanford.edu/. Он ZKP, патентно и криптографически чист (не юзает шифрование как симметричное, так и асимметричное как таковое), позволяет убрать то "что имею" и заменить "тем что знаю" и при этом иметь отличную криптографическую силу наравне просто с асимметричной аутентификацией. Просто в реализации, ошибок мало где можно сделать. Довольно быстрый.
> Мне кажется что я в состоянии прочитать матюки авторов Tor в ченжлоге
> на такую подставу в поведении openssl. Им пришлось ЯВНО ВОРКЭРАУНДИТЬ это
> западло.Вот например в языке Go соорудили собственную TLS библиотеку с нуля. С первого взгляда мне она очень понравилась: доверяю. А авторы Tor всё ноют и не могут выбрать другую (кроме GnuTLS и ещё есть) или взять и написать свою, свою обёртку? Что-то тут явно не чисто по моему. Уж сбацать свой протокол шифрования чем юзать для них ущербный TLS это как-то не сходится. Хотят наверное скорости и аппаратного ускорения и прочего: чтобы ещё и на всех платформах работа и не пришлось поддерживать руками? То есть обменяли скорость на безопасность. Ох как же не нравится меня этот Tor, ибо ну всё очень не чисто.
> Одного взгляда на оный достаточно для того чтобы понять что cache timing
> и его скорее всего пробирают от души. А еще там слабые
> ключи нашлись. Хилые аргументы "за".Из-за Sbox-ов есть. Но после публикации атака на Sbox-ы (ну точнее их аналог, это же не сеть фейстеля, а SPN) прям вот всё кирдык и ничего на основе Sbox-ов юзать нельзя. Каждый только и будет что из кэша легко доставать данные. Можно написать реализации где кэш будет хорошенько засоряться, не будет прогрет: это медленнее, но безопаснее. Опять же нефиг запускать недоверяемый софт (закрытый и проприетарный в первую очередь подразумеваю). Вот кэш всех пугает, а то что банально память нигде толком не защищается в операционках и просто в RAM все эти ключи шифрования сидят -- никого особо не волнует. Разве что OpenBSD сильно что-то пытается сделать в этих условиях, но опять же от атак в виде какого-нибудь firewire с его DMA тоже не защищали. Вот чего чего, а атаковать кэш будут в последнюю очередь, так как масса способов добраться до просто участка памяти в RAM. По мне так вы не правильно взешиваете риски. Действительно новые протоколы ЛУЧШЕ делать с тем чтобы исключить эту атаку, но опять же до сих пор те же HMAC-MD5, в отличии от MD5 можно всё-таки взять и юзать, они юзабельны.
> Возможно, но с другой стороны это же теоретически может случиться и для
> RSA. С другой стороны RSA тормозной и у него огромные ключи
> (при желании хоть какой-то надежности). А криптография - о том чтобы
> заменить большой секрет маленьким. RSA на больших ключах так тормозит, что
> для получения приемлимой скорости часто жертвуют стойкостью. Прозрачные намеки DJB на
> то что у "спецов по безопасности" - ключ RSA всего 1024
> бита. Больше видите ли тормозит. А у DJB стойкость на уровне
> RSA 2048, при скорости многократно выше RSA 1024.Но сколько RSA лет, а сколько лет DJB. Мой выбор в этом вопросе за первый, тем более что уж его среди всех асимметричных (ну кроме DH) алгоритмов мурыжили больше всех криптографов. Криптография чтобы заменить большой секрет маленьким? Впервые такое слышу, честно говоря. Стремление понимаю, но одноразовые шифроблокноты всё-таки до сих пор используют, у военных, которые могут физически доставить надёжно "блокнот" на другой конец Земного шара. Им там не до производительности, а до надёжности. Криптография всё-таки не только об уменьшении секрета :-). То что кто-то жертвует скоростью: его проблемы. Этот кто-то может не доверять DJB молодому и с ECC. Почему мы решили что ключ RSA это 1kбит? Это не DSA где он чётко ограничен килобитом. RSA юзайте хоть 4k. DJB стойкость на уровне 2k -- верно. Для кого-то этого может быть недостаточно. Шнайеры говорят что хватит, но и они не 100% доверяемые авторитеты. Так же как и AES-128 (да и вообще 128-бит ключей, не только AES) хватит в принципе для всех, но не доверяют же и юзают AES-256. Жертва скорости на спокойствие, для совсем top-secret. RSA-2k это текущий минимальный требуемый уровень, а вот у DJB нет запаса выше ибо он на этом минимуме. То есть его сила схожа с 128-бит симметричным шифром -- что достаточно не для top-secret и прочего. То есть, как уже и говорил, DJB (25519) хорош действительно для именно быстрых временных линков типа SSH/TLS/VPN. Но передавать поверх него что-то убер важное уже рисковано (для меня из-за отсутствия запаса прочности).
> Он появился не вчера и прямо под носом толпы криптографов. При том
> относительно независимых, а не прикормленных, как NIST.Чую что всяких Шамиров вы не признаёте :-). Хотя их компетенция в виду даже возраста и тупо опыта я думаю запросто выше.
> Криптография штука сложная и компетентных криптографов не так уж и много. Так
> что 10 человек которые предприняли реально хороший криптоанализ - достаточно прилично.Ну… я другого мнения. 10 мало, криптографов не так мало. Известных типа Шамира, BS, DJB конечно не очень. И никто не знает не связан ли DJB с госами, ибо остальные в целом уже засветились. А госы это то что может узнают только после столетия что были связи. А если DJB и "чист", то может быть он просто не интересен, может он просто умеет писать красивые статьи и анализы, но там парни в ФСБ и АНБ давно знают уязвимости? Ведь Dual-ы и другие ослабления как в Rijndael и прочих придумывают парни оттуда, а их имён никто не знает. Всё-таки АНБ и наше ФСБ это самые крупные наниматели математиков.
> И некие результаты будут. Бернштейн опубликовал таковые. Там нашлись атаки на
> ослабленный вариант, но ничего практически значимого.Аналогично и со старым добрым нерекомендуемым Blowfish: атаки конечно же есть, но не реализуемы (если юзать реализацию проверяющую на слабые ключи). Даже автор советует юзать Twofish хотя бы, но не говорит что BF надо взять и выкинуть.
> Кроме его табличной сущности и возможности в результате умыкнуть ключ на половине
> конфиг. И вранья от NIST про это.Я бы опасался куда больше ОС которые дадут умыкнуть ключ просто из памяти.
> вы уж извините, но если авторам ssh нормально, а какому-то чудаку
> с опеннета нет - я как-нибудь им и DJB больше верю.Кхм, авторам ssh до недавнего времени (-etm совсем недавно появился) было нормально и делать MAC, а потом шифровать -- их компетенция на нуле у меня после этого. Одно только имя SSH спасает: OpenSSH который имеет корни в Тео Де Раадте, который мужик очень правильный и запросто только благодаря нему мы получили -etm, ну и DJB-related штуки. Но то что это делалось уйму лет -- всё-равно паршиво, очень. SSH до -etm-а для меня был куда более неуважаемым чем TLS как таковой.
> Ну и опять нечто с s-box. На это забил даже автор
> - см threefish.Тут вы не правы в одном: хотели сказать Twofish, а не Threefish. Шнайер рекомендует Twofish, но и не говорит что BF вообще не юзабелен. Новое лучше с TF делать. А Threefish создан исключительно для Skein-а и Шнайер в открытую написал в комментариях своего блога про Skein (на его schneier.com) что Threefish отдельно как блочный шифр не анализировался, он разрабатывался для использования только внутри Skein, для его нужд. И опять же открыто говорит что Skein надёжен, не означает что Threefish тоже. Так же как и HMAC-MD5 надёжен, но не MD5. Он и не говорит что не надо его отдельно юзать, но предупреждает что пока анализов мало -- в общем на свой страх и риск.
> Они ничего не смыслят в применении криптографии и даже просто безопасности. Толку
> с них?Тупые ошибки найти в программах, которые будут, которые касаются чисто программирования как инженерного ремесла, которые не найдут unittest-ы. Верю что низкоуровненвые примитивы в виде шифров и прочего сложно сильно напортачить, но уже реализации протокола это просто тупо много простого кода (но каждая строка это потенциальная ошибка), который к крипто не имеет отношения.
> Любого неглупого человека можно попросить проверить fingerprint. Хотя в 25519 это излишне
> - размер ключа позволяет прямое указание ключа вместо fingerprint.В 25519 FP конечно излишен. А вот люди всё-равно как только ты отвернёшься забьют на проверку или проверят только первый или последний hex и успокоятся (а есть же даже утилиты доступные чтобы генерировать ключи с похожими с первого взгляда отпечатками).
> Имеется опыт объяснения этой операции чайниковатым юзерям.
Ну… у меня вот нет такого. Весь опыт это то что люди… остаются макаками :-). Смотришь за ними: всё ok. Отвернёшься: проверяет последний hex и долбит ok.
> У DJB размер nonce таков что можно даже просто random. И, заметим,
> про nonce все предельно четко и подробно расписано.Всё расписано: подтверждаю. Люди остаются людьми: напоминаю. Просто человек даже CTR делает коряво. Юзать random для nonce чуть понадёжнее, но это если есть доверяемый PRNG под рукой. Да и медленно: PRNG тоже не быстрый и энтропию из системы поглощает. Короче отвратительная реализация. Хотя счётчика было бы достаточно. Но… как уже много раз говорил: люди не способны в массе своей и CTR реализовать.
> Практически существующие схемы обычно это учитывают.
На бумаге учитывают. А в реализации люди забивают.
> Некрайностей в смысле того что это в состоянии люди посмотреть в плане ревью? GnuTLS.Спасиб, но что-то не хочется. В смысле это будет тот же TLS, с теми же граблями в плане кучи кода и 100500 легаси опций. Я допускаю что гнушники покомпетентнее в целом, но даже они ничего не сделают с адово переусложненным протоколом с кучей легаси и костылей. Как и опенбздюки.
> Ну… понятно: у вас хуже TLS как протокола и реализации в виде OpenSSL нет.
Я как-то видел загадочную атаку. Поимели группу серверов. Тогда никто не понял как хакеры смогли унести кучу логинов/паролей на ровном месте, не наследив в системах, да еще с обещанием "мониторить всегда". При том что все SSL было обвешано. А вот heartbleed хорошо объясняет такие особенности. Кренделя видимо уперли через .. протокол защиты траффика. Сдампили память, нашли кренделя. Хорошая защита траффика :).
> Понятно. CryptoCat для меня на данный момент ярчайший пример
Не буду настаивать что это лучшая софтина на свете. И доверять особо не буду, т.к. как верно замечено что авторы не производят впечатления компетентных в вопросе людей. Но я не думаю что они смогут переплюнуть вышеупомянутое.
> тогда были времена в которые не столь хорошо всё ещё изучили.
В криптографии надо думать головой и если уж лезть в низкоуровневые дела самому - надо думать как атакующий. В контексте "а какую информацию можно извлечь?" и "а что если креативно кормить протокол нестандартными данными?". При достаточном уровне паранои удастся отсеять явно провальные решения в пользу решений где очевидных ляпов нет. Если повезет то может так получиться и остальные не смогут найти продолбов.
> С точки зрения реализации конкретно TLS я знаком с OpenSSL и
> GnuTLS: второй однозначно мой выбор, но увиденное в первом оставляет куда
> лучшее впечатление от cryptocat-ов.Как ни реализуй огроменный переусложненный протокол, с кучей левых опций, с грузом легаси и "совместимости" - лажи будет много. Придется писать кучу кода. В куче кода - куча багов. DJB про это недвусмысленно сказал.
> TLS сложный, как и всё что делается коммитетами. Но у меня нареканий
> как к протоколу (кроме сложности) не много.Зато их было у меня. И за некоторое время до пуделя я предположил что атакующие могут даунгрейдить протокол, раз уж там куча легаси. И тут на тебе - пудель. Как раз основанный на даунгрейде до старой верии. EPIC!!!
> А дальше реализации во всём виноваты.
Спецификации виноваты в переусложненности и таскании кучи опций и легаси. Это приводит к тому что написать без ляпов малореально, а выбрать безопасные параметры - рокетсайнс. А какие там где дефолты и насколько безопасны - разобраться в этом при такой сложности протокола тоже рокетсайнс. Апликушники хотели защиту траффа от точки A до точки B. И ни в зуб ногой в этих опциях, требующих для въезда в них квалификацию на уровне "Брюс Всемогущий". Невозможно к каждому автору мелкой софтинки приставить по Шнайеру или Бернштейну. TLS - пример как НЕ НАДО делать такие протоколы. А то что реализаторы лажаются - им сильно помогли. Накидав банановых шкурок под ноги в спеках. Так странно что реализаторы поскальзываются!
> Сложнее чем TLS могу показать: IPsec.
Еще один пример гуано, единственным достоинством которого является "зато стандарт". И уже не сильно новый.
> SSHv2 без -etm, cryptocat.
Они смогли фатально облажаться на уровне heartbleed, так чтобы через это хакеры разнесли целые энтерпрайзы?
> В моём мире подразумевается что в столовой не сидят без дела, а едят беляши :-).
А вот это совсем не факт. Очень зависит от индивидуальных спсобностей людей. И криптографы охотнее поизучают мелкую реализацию алгоритма чем огромный шмат кода типа openssl. Так что многие криптографы считают что все что касается криптографии кроме всего прочего должно быть максимально компактно и прозрачно - для упрощения аудита. В этом плане наиболее симпатично сделан наверное tweetnacl. Его вполне реально прочитать за весьма обозримое время.
> Всякие Blowfish и прочие до сих пор берутся для "тренировок".
Ну вот видите, я ему могу кое-что предъявить даже при том что я в общем то не криптограф. В том плане что я понимаю что моей квалификации недостаточно для конструирования "кульного алгоритма шифрования".
> и как протокол на бумаге ужасен, но для меня нет.
А для меня - да. Потому что переусложненный крап, с кучей лишних опций и легаси. При том все это цепляние за легаси и "совместимость" - как правило приводит к предсказуемым классам атак "MITM может задаунгрейдить протокол". А потом отпинать старенький не особо секурный вариант, сильно скостив трудоемкость задачи. Так заканчиваются блеяния про совместимось и стандарты. Ах да, приветы от пуделя - он как раз об этом. Заметьте, скелетов из шкафов начали немного вынимать только после этого. Но оно такое там ВЕЗДЕ. Так что тот факт что в openssl находят пару CVE той или иной степени серьезности в месяц - перестал удивлять. Да и остальным достанется. Ну может polarssl чуть поменьше, а другим чуть побольше. А то что этот ворох костылей можно реализовать без багов - крайне сомнительно.
> само крипто можно посмотреть. Простое и грамотное. Ревью проводилось.
А тут на опеннетике некий неизвестный сказал что openvpn в дефолтной конфигурации просто небезопасен. И я кажется понимаю что он имел в виду.
Всего ничего. По дефолту там IIRC нет проверки идентити ремотного сервера. Это надо явно возжелать и прописать. Или вот например perfect forward secrecy. Про него надо явно узнать и захотеть. А если вы не спец в криптографии - вас ждет немало подстав, которые вы забудете разминировать (или просто не узнаете что надо). Нет, я думаю что криптография не должна работать в режиме "ха-ха, лох, забыл дома миноискатель? А мы вот удачно положили тебе мину! На!". Спасибо, мне не хочется пользоваться софтом который кишит малоочевидным западлом. И весь SSL/TLS по этому поводу достоен списания в утиль - состоит из западла и капканов чуть более чем полностью. С аргументами что все это для нашей же безопасности или накрайняк совместимости и стандартов.
> Под RSA я подразумевал только конкретно RSA алгоритм, а не компанию.
А с чего вдруг авторам алгоритма такое безоговорочное доверие при сомнительных делишках основанной ими компании? Тут надо детально трассировать в какой момент им стало хотеться денег и они переключились в режим "деньги не пахнут". Мне это обломно, поэтому я им доверять не буду. Хотя на сам RSA из предъяв разве что то что он тормозной и у него огромные ключи. При том для сколь-нибудь серьезной надежности ключи надо реально громадные, а работа с ними происходит крайне медленно. Так что схемы шифрования по этому поводу жестоко костылят. А все-равно какой-нибудь выводок ботов сильно грузит ssh с RSA, если мер не принимать.
> Хотя… там работают очень и очень крутые криптографы.
...озадаченные задачей "как бы втихаря нагадить и не спалиться", например. Так что они может и крутые, а вот их задачи и мотивация может быть и "деньги не пахнут".
> Кстати нет гарантий что Бернштейн давно куплен и недаром даже Google
> проталкивает (или уже даже в Chrome реализовала) chacha/poly в TLS.Он какой-то скромный академик, сделавший 25519, salsa, chacha и прочее довольно давно, не пиарившись и не создавая корпорации на тот момент. И не продавливаемый в стандарты. А то что после ряда кризисов SSL/TLS, краха доверия к NIST из-за стандартизации бэкдореного ГПСЧ и прочая на него и его алгоритмы обратили больше внимания - это предсказуемо. Ибо некая альтернатива стандартному ГOBHУ востребована. И к тому же от человека не рвущегося с пеной у рта МОНЕТИЗИРОВАТЬ!!111 как корпорасы по типу RSA и не запалившиеся на подлянах как стандартизаторы из NIST - это очень кстати. Тем более что на все это смотрит толпа криптографов и их всех покупать задолбаешься. А еще DJB не врет внаглую как NIST, втирающий очки про то что лукап таблиц занимает постоянное время. То что он говорит - согласуется с мнением других криптографов. В отличие от пурги из NIST, которую все независимые криптографы дружно обоcpaли и сделали НеСтандартные алгоритмы, лишенные проблем Стандарта(тм). Ну и ему и его алгоритмам доверяют даже опенбсдшники.
> С одной стороны Google может это делать чтобы казаться хорошей,
Гугл скорее всего не заинтересован в несанкционированном доступе к данным. А криптография такая штука, что если там есть бэкдор то есть шансы что им будут пользоваться не только те кто про него изначально знал.
> Хотя вроде Бернштейну стоит больше доверять чем Шнайеру, ведь тот же тоже
> вроде как засветился работой на оборонку.Я предпочитаю открытые исходники в том числе и потому что разные люди могут посмотреть на это и независимо друг от друга высказать мнения. Если мнения специалистов хорошо согласуются между собой - значит, истина скорее всего где-то рядом. А если мнения существенно разнятся - это может быть индикатором спорной схемы, подкупленности или недобросовестности части участников, ну и так далее.
> В корне не согласен что у них правильное направление.
Правильное только в том что оборвать нафиг все легаси и оставить подборку от DJB. Но они в криптографии не разбираются и судя по всему наворачивают новые алгоритмы выбирая их по принципу "Вася с соседней парты очень просил, потому что Петя ему сказал что это круто".
> показалось что они "правильные". Вообще не признаю я их уже.
Мне тоже не понравились их потуги впихивать новые алгоритмы без особой аргументации "за" и судя по всему без особого понимания что и зачем они делают. Но даже обезьяна с гранатой иногда может метнуть гранату в правильную сторону, хоть это и случайность :)
> посоветовал просто посмотреть на страничку его родную: http://srp.stanford.edu/.
[...]
Посмотрел, именно там (заявы про SSL/TLS меня чуть не спугнули правла).
И имею заметить:
1) Он сам по себе шлет идентити юзера влобешник. Отлично, гудбай приваси. Всему миру видно что на сервак в хренадцать часов логинился именно Вася.
1.1) Конечно там что-то про TLS, но что я думаю о этом выводке протоколов и куда ему пойти - вы в курсе, да?
2) Оно почему-то переклинено на клиентсерверной модели и потому однобокое. Вообще-то, по идее хотелось бы верификацию *обоих* участников линка друг другом, НО чтобы остальным не было видно какие идентити представили друг другу эти участники. Иначе какая ж это секурити с учетом современных реалий, когда NSA и даже ФСБ даже не скрывают что хотят знать какие учетки, куда и когда. Субъективно - такое можно сделать хоть из DJBшного криптобокса. Перекидывая минимум пакетов и храня минимум информации. И симметрично. Хотя при желании можно и даунгрейднуть до однобокого. Хоть я и не понимаю почему на проблемы клиента должно быть пофигу и почему надо вообще жестко делить на клиента и сервера.
2.1) Общая идея напомнила мне какую-то странную и несколько однобокую реализацию диффи-хеллмана, чтоли.> Вот например в языке Go соорудили собственную TLS библиотеку с нуля.
Я их с этим поздравляю. Языку для хипстеров и секурити под стать. Пусть пользуются им наздоровье, верят в безопасность TLS и прочая, а я пешком постою. Мне этот ваш Go - ни в п..., ни в красну армию. А что я думаю про TLS - вы уже видели. Ну и их кульные библиотеки на go с TLS понятно куда могут идти, имхо. И гугле я в целом не особо доверяю - они по жизни барыжат приваси пользователей. Крупным оптом.
> ноют и не могут выбрать другую (кроме GnuTLS и ещё есть)
> или взять и написать свою, свою обёртку?Они просто написали небольшую заметку в ченжлог, показывающую насколько крындец в openssl с пониманием криптографии и как это должно работать.
> них ущербный TLS это как-то не сходится. Хотят наверное скорости и
> аппаратного ускорения и прочего:Это все хотят. А еще хотелось бы чтобы либа не подкладывала при этом свинью. А если некто запросил аппаратное ускорение, а ему в апликуху напрямую сплюнули вывод аппаратного RNG, нисколько не парясь что он может быть пробэкдореный - это пипец! Даже разработчики линуха это понимают, предпочитая подмешивать вывод такого RNG в общий пул, так что в самом плохом случае - качество пула останется на том же уровне что и было, а атакующий не сможет ничего предсказывать, хоть там этот железячный RNG сто раз не случайный будет. А эти напрямую апликухе его. Совсем без пула энтропии и других источников. Вот те раз. Оказывается чтобы поюзать какой-нибудь аппаратный AES или SHA, надо бонусом получить потенциально неслучайные числа везде. Здорово придумано!
> чтобы ещё и на всех платформах работа и не пришлось поддерживать руками?
Начались аргументы в стиле "почему кушать г-но это вкусно и питательно"?
> Ох как же не нравится меня этот Tor, ибо ну всё очень не чисто.
У них на самом деле не особо удачная архитектура сети, куча легаси и много трудноустранимых проблем. Так что они годятся для дежурного сокрытия просмотра порева от корпоративного админа как самый максимум. А так они не для требовательных применений, имхо.
> кирдык и ничего на основе Sbox-ов юзать нельзя.
Их нельзя использовать хотя-бы из-за тайминг атак, потому что когда ключи может выколупать любой кто на том же проце пристроился - это безобразие и отрыв от реалий.
> Каждый только и будет что из кэша легко доставать данные.
Ну я понимаю что некоторым надо крындец размером с heartbleed или как минимум с пуделя чтобы осознать очевидное. А мне такой подход кажется недальновидным.
> Можно написать реализации где кэш будет хорошенько засоряться,
Вот только скорость при этом скорее всего будет никакой - из-за нужды делать серьезную диффузию побочного канала утечки до состояния когда по нему ничего восстановить нельзя будет. А регистровая математика - она и быстрая и кэш не дергает лишний раз. Выводы напрашиваются, не так ли? ;)
> не будет прогрет: это медленнее, но безопаснее.
А операции регистр-регистр и быстрые и вообще не требуют лазить в кэш. Наверное это объясняет почему криптографы обратили на них внимание и забили на схемы с s-box и т.п.? ;)
> Опять же нефиг запускать недоверяемый софт (закрытый и проприетарный в первую
> очередь подразумеваю).На х86 машине почти всегда есть как минимум обработчик SMM в максимально привилегированном режиме. Который нельзя вырубить средствами ОС вообще совсем никак. Если уж мы о грустном.
> Вот кэш всех пугает, а то что банально память нигде толком не защищается в операционках
> и просто в RAM все эти ключи шифрования сидят -- никого особо не волнует.Вообще-то
1) Волнует. Поэтому криптографы в курсе что ключ живет ровно столько сколько нужен.
1.1) есть даже параноидальная версия AES, где ключ хранится в регистрах. Только AFAIK тормозная очень.
2) Память в нормальных ОС все-таки защищается друг от друга и даже чистится при отдаче другой программе. Времена win95 все-таки прошли.
3) Особо любопытные могут посмотреть например как биткоин с шифрованным кошельком поступает в том же линухе для минимизации шансов утечек.> Разве что OpenBSD сильно что-то пытается сделать в этих условиях, но опять же
> от атак в виде какого-нибудь firewire с его DMA тоже не защищали.Если у злодея есть физический доступ - он много чего сможет. Но если уж на то пошло, современное железо обычно имеет IOMMU. Это надо для проброса девайсов в виртуалки, поскольку в виртуалке ничего не подозревающий драйвер будет програмить "свою" железку, понятия не имея что она на хосте, а DMA со стороны железки при этом в два счета выносит память хоста, т.к. железка понятия не имеет что это не хост просил. Это ведет к краху хоста. Так что такие инициативы нынче активно зарубаются IOMMU (в случае виртуализации это будет редиректнуто в VM, а если это "само по себе" - в логе ядра будут вопли, а запись обломается). А что, опенбсдшники уже умеют с IOMMU работать, раз мы про DMA?
> Вот чего чего, а атаковать кэш будут в последнюю очередь,
По идее это удобная атака для утягивания ключей с виртуалок и контейнеров. Все что надо - пристроить свой процесс на тот же проц. Не ахти какое требование при желании подломить например на заказ "вон тот сайт" и наличии немного терпения, так что за несколько попыток машина/контейнер плюхнется на нужный хост и остается сп..ть ключ в удачный момент.
> так как масса способов добраться до просто участка памяти в RAM.
Одно дело если атакующий должен кабель к компу цеплять и его может обломать iommu, и совсем иное - если атакующему достаточно плюхнуть контейнер или вм на тот же хост и подождать. Что там насчет рисков? :)
> По мне так вы не правильно взешиваете риски.
А как по мне - в самый раз. Вышеупомянутый сценарий атаки - подсмотрен на примере реального взлома, только "адаптирован" под иную цель: атаку на виртуализаторы и контейнеры. Заметьте, для этого не надо никакого особого доступа. Достаточно закосить под клиента хостера и за несколько попыток пристроиться на нужную машину. И все.
> до сих пор те же HMAC-MD5, в отличии от MD5 можно [..]
Можно даже бегать в ластах и противогазе по снегу вместо того чтобы взять лыжи. Но зачем?
> Но сколько RSA лет, а сколько лет DJB.
Этот аргумент ничего не говорит про "количество беляшей".
> (ну кроме DH) алгоритмов мурыжили больше всех криптографов.
А в результате нас потчуют DNSSEC с 1024-битными ключами. Замечательно.
> Криптография чтобы заменить большой секрет маленьким? Впервые такое слышу, честно говоря.
Если бы это было не так - пользовались бы одноразовыми блокнотами и не парились. Что-то вы не больно идете создателю опеннета свой блокнот заносить, а? Ну и я тоже.
> одноразовые шифроблокноты всё-таки до сих пор используют,
Только их юзабилити хромает и потому они очень нишевое нечто. Если посмотреть, поточные шифры - попытка получить то же самое, только с сокращением секрета до инициализатора PRNG. Более практично получается.
> Криптография всё-таки не только об уменьшении секрета :-).
Не только. Но если уж на то пошло - я могу и лично отнести письмо, проверив что его прочитал только получатель.
> чётко ограничен килобитом. RSA юзайте хоть 4k.
Только ждать загнешься. А при коммуникациях по сети - ремотные машины могут сильно грузить на ровном месте "интересную мишень". Да и передавать публичный ключ в 4Кбит не сильно практично. В SMS не отправишь, с клавиатуры не набьешь. Для проверки придется отдельный более компактный fingerprint считать. Лишняя операция и куча грабель на ровном месте.
> DJB стойкость на уровне 2k -- верно. Для кого-то этого может быть недостаточно.
> Шнайеры говорят что хватит, но и они не 100% доверяемые авторитеты.В обозримом будущем 128 битов и более - должно хватить. Даже с учетом Мура, 2^128 - довольно много.
> минимальный требуемый уровень,
А почему тогда в DNSSEC смеют использовать 1024-битные ключи и впаривать сие?
> а вот у DJB нет запаса выше ибо он на этом минимуме.
Осталось найти тех кто реально пользовался бы 4096 битными ключами RSA.
> быстрых временных линков типа SSH/TLS/VPN. Но передавать поверх него что-то убер
> важное уже рисковано (для меня из-за отсутствия запаса прочности).Смотря что понимать под запасом. Если мы рассматриваем взлом 128 бит - это наверное про квантовые компьютеры. А в этом случае есть мнения что для публичной криптографии которая устоит даже против них - надо смотреть на иную математику, где есть уверенность что специфичные свойства квантовых компьютеров не приведут к серьезному повышению эффективности взлома. Если эти упрощения получатся, RSA при этом завалится не лучше и не хуже эллиптических кривых, насколько я понимаю мнения криптографов. Симметричные шифры - где как, но сам по себе лобовой перебор 256 битов - не получится вообще совсем никак. Энергии не хватит на обсчет, чисто технически.
> Чую что всяких Шамиров вы не признаёте :-). Хотя их компетенция в
> виду даже возраста и тупо опыта я думаю запросто выше.Если их контора смеет пихать бэкдоры - их репутация резонно подмокает, а на кого в результате работает их компетенция и опыт - большой вопрос.
> Известных типа Шамира, BS, DJB конечно не очень.
При том они известны потому что разбираются в своей области и делом доказали что отличаются от толпы обезьян с гранатами.
> И никто не знает не связан ли DJB с госами,
По логике вещей, если бы был связан и там было бы что-то не так - его схемы внедряли бы намного раньше, нахраписто продвигали бы в стандарты и заваливали деньгами на успешные стартапы и масс-впаривание. Уж NIST наверняка смотрел бы не на какие-то свои кривые, а первым делом и схапал бы 25519, бонусом к dual EC. Вот только почему-то к Dual EC предъявы были, а 25519 с нами уже не первый год, но ничего такого этой кривой не предъявили.
> анализы, но там парни в ФСБ и АНБ давно знают уязвимости?
Наверное именно поэтому они подставили NIST и RSA с алгоритмом, в котором криптографы довольно быстро нащупали бэкдор. А какая логика в такой деятельности тогда, собственно?
> Ведь Dual-ы и другие ослабления как в Rijndael и прочих придумывают парни оттуда,
И что характерно - потом с нахрапом заталкивают в стандарты и размахивают аргументом "зато СТАНДАРТ!".
> наше ФСБ это самые крупные наниматели математиков.
Теории заговора это круто, но если в способность АНБ платить крутым спецам конкурентоспособные зарплаты и создать не слишком дискомфортную рабочую атмосферу я еще со скрипом поверю, то способность ФСБ делать это вызывает определенные сомнения.
Ну и если так посмотреть - наука как-то сильнее всего продвинулась публично. Да-да, даже описание конструкции атомной бомбы найти не проблема. И термоядерной. Проблема в основном с ингредиентами, которые на дороге не валяются и в подвале тихой сапой не получаются. А огроменный завод - штука заметная, как ни крути. Утверждается что для математики это иначе?
> не реализуемы (если юзать реализацию проверяющую на слабые ключи).
Ну да, а то что табличная сущность утекает состояние алгоритма наружу мы будем игнорировать? Пока не долбанет в лоб на уровне heartbleed, да?
> Даже автор советует юзать Twofish хотя бы, но не говорит что BF надо
> взять и выкинуть.А для меня нежелание криптографов использовать схемы с таблицами - аргумент. Они утекают данные о состоянии алгоритма наружу, позволяя рекавери ключа. И это накладывает массу ограничений на то где это можно использовать - только машины где все процессы мои и доверяемые. Ну то-есть использование компьютеров на уровне эпохи MS-DOS примерно.
> Я бы опасался куда больше ОС которые дадут умыкнуть ключ просто из памяти.
Просто - не дадут. Нынче вам не MS-DOS и даже не win95. И MMU появились не вчера.
> их компетенция на нуле у меня после этого.
Если честно - по моему нескромному мнению ssh давно пора переделать. По итогам грабель. И снеся совметимость с старьем. Сделав padding, убив все граблеопасные алгоритмы и кучу легаси барахла. А личное пожелание - вытряхнуть оттуда все кроме секурного шелла. А остальное - оформить либу и отдельные программы, на основе той же технологии, но - именно отдельные. А не макаронный монстр который и поганый впн и инопланетный портфорвардер и горбатая файлокачалка и что там еще.
> имеет корни в Тео Де Раадте, который мужик очень правильный и
> запросто только благодаря нему мы получили -etm, ну и DJB-related штуки.А он вообще в криптографии разбирается? Большинство его аргументов обычно больше похожи на чесание ЧСВ.
> TLS как таковой.
TLS как таковой факинли сложный и речь о аудите просто не идет.
> Тут вы не правы в одном: хотели сказать Twofish, а не Threefish.
Я как минимум вижу что Шнайер и еще кучка криптографов вместе надизайнили Threefish. И он сделан вполне в духе остальной криптографии - регистровая математика и никаких таблиц.
> Новое лучше с TF делать.
А технические аргументы за это мнение будут? И нет, я не хотел сказать про twofish. Он также использует S-box, что означает что в половине юзкейсов любезно разложены грабли. Они ЗАВЕДОМО ЕСТЬ, в отличие от тех которые "может быть найдутся" в threefish.
> И опять же открыто говорит что Skein надёжен, не означает что
> Threefish тоже. Так же как и HMAC-MD5 надёжен, но не MD5.Зато twofish с его s-box - хорошая заявка на грабли по линии кэша. Я понимаю что вопросами утечек через кэш серьезно озадачились лишь сравнительно недавно, но это не значит что грабель нет или что они незначительные. Это очень существенная проблема, сильно лимитирующая область применимости. Для лично меня - меня не устраивает требование что на процессоре в принципе не может крутиться никаких посторонних процессов. Это дико оторвано от современных реалий с виртуалками и контейнерами.
> предупреждает что пока анализов мало -- в общем на свой страх и риск.
А вон та толпа криптографов предупреждает что таблицы текут через кэш. Так что ну его этот ваш twofish в современных реалиях.
> протокола это просто тупо много простого кода (но каждая строка это
> потенциальная ошибка), который к крипто не имеет отношения.Большинство ошибок фатальны обычно в использовании криптографии или прикручивании оной к протоколу.
> В 25519 FP конечно излишен.
И это при прочих равных шаг вперед. Если сравнить с RSA2048, можно ключ напрямую передавать, работает намного быстрее. Ну и нафига пользоваться RSA2048?
> отвернёшься забьют на проверку или проверят только первый или последний hex
Это уже на их совести. При таком подходе можно и просто отдать приватный ключ атакующему :)
> с похожими с первого взгляда отпечатками).
Возможно, но именно поэтому я проверяю еще и как минимум середину. И если так посмотреть - даже специализированный долбеж на подгон хэша типа майнинга коинов подгоняет не такой уж и большой кусок.
> Отвернёшься: проверяет последний hex и долбит ok.
Тем не менее, при правильном подходе у mitm есть только 1 шанс подсуетиться - в самом начале, и только если юзеры невнимательны. Это сделает жизнь mitm не слишком пресной. Если это прошляпить - ключ может быть запомнен, а дальше потуги его подменять приведут только к воплям, программе в отличие от юзера не в облом проверять все с точностью до бита.
> Всё расписано: подтверждаю. Люди остаются людьми: напоминаю.
Следовать инструкции может практически любой кодер. А если кодер совсем пофигист - пусть лучше веселую ферму делает, это у него лучше получится. Если не уволят за пофигизм :).
> Просто человек даже CTR делает коряво.
Человек может не знать что такое CTR и понятия не иметь чем плохо то что сделал он. Но вот выполнить DJBшную инструкцию из мана - вполне в его силах.
> PRNG тоже не быстрый и энтропию из системы поглощает.
PRNG как раз может быть довольно быстрым. Собственно ряд поточных алгоритмов шифрования по сути и являются PRNG где ключом является инициализация PRNG, так то на разные ключи - разные последовательности.
> Хотя счётчика было бы достаточно.
Кстати говоря, в качестве nonce у DJB допустимо использовать и счетчик. Там даже пример есть, IIRC, как это сделать правильно и безграбельно. Очевидный минус - утекает некая информация о характере обмена информацией. В виде счетчика пакетов видимого всем.
> в массе своей и CTR реализовать.
У DJB в мане несколько простых требований вообще очень косвенно относящихся к криптографии.
> На бумаге учитывают. А в реализации люди забивают.
Ну если люди не могут выполнить даже пару простых требований - тогда им лучше идти веселую ферму кодить. Впрочем даже это при таких фиговых умениях не выйдет.
В общем у вас полная убеждённость что из-за сложности 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илась и всё. Хотя да: примитивы могут быть схожими.
>Ну если люди не могут выполнить даже пару простых требований - тогда им лучше идти
>веселую ферму кодить. Впрочем даже это при таких фиговых умениях не выйдет.Ага, с вашим подходом типа только Бернштейн в состоянии что-то кодить. Все — люди: и все люди допускают ошибки. А также продаются.
> В общем у вас полная убеждённость что из-за сложности TLS нет возможности
> его и ревьювить — не согласен с этим.Факты говорят за себя сами - CVE в ssl'ных либах стали привычным делом. А раньше всех просто лoмaло туда совать нос. Но вот прижало.
> У вас полная убеждённость что атаки которые на деле крайне сложно
Для компьютеров понятия о том что просто и сложно достаточно специфичные.
> применены и сразу же технологии можно закaпывaть.
Практика показала что в криптографии не бывает мелочей и "мелкая проблема" и "сложнореализуемая" атака зачастую заканчивается массовым п-цом.
> не делает ETM и что можно 4 байта plaintext-а у него
> тырить: вы закрываете глаза,Кто вам это сказал? Мне не нравится объем утечек о сессии в ssh и я считаю это жирным минусом. И не только за это но и за утечку размеров пакетов.
> на практике конечно же безусловно, по вашему, гораздо легче применить.
Вполне реалистично. Практические атаки показаны. Мне этого достаточно.
> RSA видители не имеет много криптоанализа,
Ну это уже утрирование. Я просто считаю что козырять криптоанализами RSA и что они сильно лучше, при том что 25519 существует около 9 лет как-то кривовато.
> Шамиры и прочие видители куда менее доверяемые люди чем Бернштейн
А это уже каждому по делам. Если бы криптографы из RSA вопили что Dual EC ненадежный - вопросов не было бы. А если они его вместо этого впаривать пошли - опппаньки!
> (хотя не Шамиры принимают политические решения
Мне пофиг кто их принимает. Если специалист к такому причастен - для меня его репутация будет подмочена.
> чётко прибиты гвоздями используемые режимы -- вы игнорируете.
В каком проценте применений это именно так? Нужду быть ракетным инженером для того чтобы не налетать на самые тривиальные грабли я считаю за жирный минус всяких TLS, IPSec и прочих переростков.
> но как-то вот не выходит у людей нисколько.
Это неправда. Выходит. А то что это не стандартизируют - вообще второй вопрос.
> тогда как другим достаточно допилить/донастроить TLS/IPsec и они вполне себе будут
В большинстве применений они будут создавать видимость защиты а не реально защищать пользователя. Их дефолтные свойства очень далеки от того что ожидают их пользователи и программеры. И я считаю это проблемой.
> легко может использовать side channel, ну ну.
В криптографии не бывает мелочей.
> И оказывается ваша ОС очень усложняет жизнь по доступу к памяти другого процесса,
Да. У меня не слишком гнилой кернель и там все относительно честно. И опенсорсно. Это вам не дос и не 95-я винда. И MMU железные нынче в моде.
> все атаки как бы заключаются в этом на практике, на деле.
На практике Васе может быть влом и миллион ключей ssh для моего хоста проверять. А придет Петя и окажется что он более сообразительный и менее ленивый. И запустит вобще ботнетик какой-нибудь автоматический. А оно мне надо?
> В теории AES side channel можно использовать,
Были вполне практические демонстрации. Так что это не только в теории но и на практике.
> Шнайер видимо лысый потому-что ужаснулся использованию S-box-ов и ринулся
> переделывать это в Threefish.От S-box ушло большинство криптогрфов. И да, это мое право наблюдать за тем что творится в отрасли и замечать очевидные вещи.
> возиться с атакой на S-box.
У атаки на кэш есть важное преимущества.
1. Техничски это не есть взлом и скорее всего не влечет легальных последствий само по себе.
2. При этом в системе не остается вообще никаких следов и аномалий.> AES оказывается можно сделат безопасным против cache side channel атак,
При сильном желании можно даже в ластах и противогазе на потолок залезть. Но зачем? У меня нет цели в жизни принципиально грызть самый колючий кактус из религиозных предрассудков.
> основанная на тьме криптоанализов, не то что у salsa20.
Так вот для меня результаты AES уже сомнительные - за счет s-box'ов. Я вам что, в MS-DOS чтоли чтобы обрубать использование машин 1-пользовательскими сценариями?
> По моему OpenSSL не так уж и плох,
А на мой вкус это макаронный монстр, авторы которого нули в криптографии.
> а CryptoCat это какие-то школьники которые в принципе лучше
> бы не брались за криптографию.То что они переплюнут heartbleed или ключи в дебиане с 20 битами энтропии - далеко не факт. Замечу что изменение нагибающее энтропию в дебиане подтвердили как безопасное разработчики опенссл.
> А то что SSHv2 не использует ETM, то говорит что они
> даже книжек не читали по крипто.Мне свойства протокола ssh не нравятся. Это несколько не то что надо мне. И сам ssh превращается в какое-то монстрило.
> Сложность протоколов это безусловно беда. Но я уже показал выше что даже
> тyпо передавать VPN трафик это уже нужен протокол, в котором будут
> точно такие же баги и ошибки которые возникали вездеПротокол спецализированный под задачу может быть прост как топор и потому легок в аудите. А TLS/SSL извините настолько забагованные что я даже уже не помню полный список проблем безопасности этого крапа которые там исторически были. Экстраполируя тенденцию - show will go on. Не верите? Не забывайте заглядывать в CVE ;). Я знаю толк в вопросах багов.
> писал с нуля. Просто факт. И никто не занимается толком атакой
> на низкоуровневые примитивы, так как всё гораздо проще бывает.Да, в переусложненном протоколе столько возможных вариантов действий для атакующего и места для лажи что там все сильно проще.
> Никто не знает в относительных величинах как навредил SSH и как навредил heartbleed.
Оба сильно подгаживали лично мне. Экстренный рекеинг 20-битных ключей от дебианщиков и реинсталл/рекеинг после heartbleed - примерно одинаковы по геморности: полная перераскатка машин утративших доверие. И openssh'ники упыри что такое как openssl у себя дергали.
> Heartbleed не во всех библиотеках проявился,
Только в openssl. Которым однако ж пользуется легион софта. Так что сложно даже оценить что и где могло утечь. Онлайн банкинги ряда популярных банков так поломались. Всего блин ничего. Толпе народа пришлось резко менять пароли и ключи.
> как где-то крупно-крупно была беда из-за утечки данных по SSH, так
> как если речь о госах или банках — этого никто не скажет.Пользователи сами говорили им о heartbleed, что намекает насколько там крЮтые профи по безопасности работают :)
> получается, даже против морально всего такого устаревшего Blowfish.
Практический пример доставания ключа AES продемонстрирован. Кто не ретард - выводы сделают, а остальным хоть кол на голове теши.
> Не вижу с какой стати математики, пускай и основавшие компанию, мешаются с политикой,
С такой что мало ли что политика и их попустительство по части политики им надиктовали сделать в математике.
> где никто не говорил что они принимают решения.
Если некто подписывается под той или иной подляной - он в ответе за это. А у этих господ квалификация вообще позволяла детектировать бэкдор до его внедрения по идее. Но это не было сделано. Почему?
> Да и опять же все люди: у всех есть цена.
Это очень примитивное мышление.
> Бернштейн запросто уже давно куплен АНБ, почему нет?
Потому что не понятно какой в этом смысл. На его алгоритмы смотрит целая толпа криптографов. Да и он как-то не стесняется показыавть математику лежащую в основе и объясняет что и откуда взялось.
> они и сейчас стали продажными -- не означает что они всегда
> такими были. RSA очень хорошо изученный алгоритм.Это в каком-то роде валидно, но в какой момент они стали продажными - мне неизвестно, поэтому я их алгоритмы лишний раз использовать постремаюсь. Мало ли когда они опаскyдились и что еще я не знаю о их деятельности.
> Ага, прям идеал чтобы его подсадить и ни в чём не заподозрить.
Странный какой-то идеал - тусоваться в толпе криптографов и добиваться того чтобы они проаудитили алгоритмы. Зачем бы это АНБ? Чтобы криптографы бэкдоры нашли? Не логично.
> Чую что я подобное как-то говорил по поводу ревью уже ☺. Не работает это.
Работает. Скупить всех вообще и единовременно - малореально. Значит, если с алгоритмом что-то не так - из разных углов будут периодические вопли. На примере Dual EC видим что это работает. А бонусом видим что бэкдоры в EC криптографы искать умеют.
> решена задача ZK, аутентификации и конфиденциальности: то об анонимности рано ещё думать.
А у DJB как-то так все и сразу можно получить с его криптобоксом.
> Если она нужна, то никто не мешает сделать обычный DH,
DJB интересен тем что у него DH разнесен по времени и как таковой состоялся заранее. Это позволяет ряд интресных применений которые мне нравятся.
> SRP и TLS? Я слышал что SRP встроили в TLS недавно.
Ну да. Мало было в TLS барахла - еще чего-нибудь встроить. "Кадавр жpал".
> Разрабатывался он как-то вообще не соприкасаясь с TLS.
Да я вижу. Только при этом идентити юзера прямым текстом по каналу шлется и зачем-то асимметричность. Ну его такое нафиг, я не фанат таких подходов.
> Ах да, если коснулся TLS, то видимо всё: epic fail.
Именно так. Еще больше кода в tls либе? Ненене, Дэвид Блейн, ненене. Я такими либами пользоваться не буду. Если такой шмат кода вывешивать в сеть - его будут долбать. Это предсказуемо.
> В качестве identity можно легко использовать CHAP-based протокол,
Ну знаете, если делать chap - SRP при этом повторяющийся функционал, чтоли.
> Skey или что-то подобное. Это уж не хитрое дело и второстепенное.
Мне не нравится когда на меня спихивают протокольные проблемы.
> совершенно задачи в одну кучу. Не везде нужна анонимность.
Ну как бы если шифрование позволяет узнать кто и что - нафига оно такое надо? Чтобы заниматься декоративной имитацией безопасности?
> Можно, но у SRP есть удобные преимущества которые могут оказаться решающими. Как
> например то что он не использует как таковые протоколы шифрования.А в чем тут преимущество? Ну, математика. Ну, несколько другая.
> Именно это я и сделал в GoVPN в виде DH-EKE.
Я вижу. Но бы это делал на чистом криптобоксе. Нисколько не теряя в свойствах.
> Ну вот вы не видели и не знаете какого уровня там люди,
Какого уровня шпионаж развернул гугль - я прекрасно вижу. И если кто думает что я буду доверять этим privacy breaker'ам "по умолчанию" - это ошибочное мнение. Эти да, не DJB - и давно сдали пользователей как стеклотару. Потому что у корпорации добра бабло победило зло.
> а сразу судите. Одни сплошные стереотипы и epic fail-ы по каждому щелчку.
Не вижу оснований доверять по умолчанию конторе известной тем что это прежде всего борзые privacy intruder'ы, тырящие все данные до которых дотянутся. Вплоть до "резервного копирования" пароля точки доступа, если их ведроид не разминировать.
> Мда, дожили, чтобы делать так сложно обфускацию траффика.
То что в тор - "уж что выросло, то выросло".
> Ну ну. А GOST поломан до 2**178: epic fail, использовать нельзя!
Скорее просто нет никакого смысла. Тормозной алгоритм с фиговыми перспективами из-за утечек через кэш. И нет доверия тем кто его делал - они не говорят с какого потолка s-box взяты и каков критерий этого. Нафига я это буду использовать, спрашивается?
> Если не известно насколько лыжи хороши для снега, то ради того чтобы
> выжить, а не рисковать непроверенной технологией.Спасибо, я лучше лыжи возьму все-таки. А вы можете в ластах и противогазе выживать. Есть у меня такая привилегия - я могу прикинуть как работает тот или иной дизайн посмотрев на него. Не требуется мне вставать на грабли чтобы убедиться что они бьют в лоб.
> Ага, пока не найдут атаку снижающую brute force взлом на несколько порядков.
Ну вот за 9 лет пока научились вот настолько. И да, с таким же успехом можно и RSA взломать.
> А был бы 256bit, то запаса как у ГОСТа вон был бы!
...пока не сопрут ключ через кэш, решив что это сильно проще чем брут 2^256 и даже 2^128.
И это вообще нормально - сравнивать алгоритм публичной криптографии и симметричный? :)
> будет запросто.
Весьма зависит от того кто и что.
> А вот для гостайн не пойдёт.
Да, да, слышали мы этот булшит. И главное к нему никаких технических аргументов обычно не прилагается.
> что у Бернштейна наверное поэтому и не исследуют так много его
Вообще-то,
1) его исследуют.
2) по этому поводу есть криптоанализы.
3) Эллиптику и 25519 придумал как таковой не он и теорию и прочая делали иные люди.
> алгоритмы потому-что запаса в них никакого. Всё мол ради скорости.Ну да, RSA 4096 как бы может быть более стойким. Только его скорость работы зарубает большинство применеий. А так то и блокнотик можно. Но непрактично уж очень.
> компромисс между скоростью и безопасностью (от 15 лет кракеров спасёт —
Так у DJB алгоритм и быстрее и более стойкий - одновременно :). Вот и возникает вопрос - а зачем впаривают именно вон то?
> 99.99% атак.
Да щаз. По идее достаточно активно саботировать DNSSEC и клиенту ничего не останется как считать что это обычный (несекурный) DNS. Да и вообще, вся система DNS - один большой кусок проблем.
> Это не уберрешение,
Это очередная имитация защиты, вешающая лапшу на уши в плане того что это от чего-то защищает.
> Ключей таких размеров тьма. Например у Шнайера, у Столлмана с ходу вспоминаю.
Целых 2 человека. А на серверах они рискнут здоровьем их использовать? И, главное, насколько легко будет поставить сервер колом?
> в два раза длину ключа (был 128 бит, стал для brute
> force фактически 64).Насколько я помню, там ожидалось сильное увеличение эффективности взлома RSA до состояния когда это перестает быть математически сложной проблемой. И для эллиптики вроде как нечто такое ожидается. Поэтому те кто попредусмотрительнее - дизайнят алгоритмы, которым свойства квантовых компьютеров пофигу.
И да, это нормально - мешать в кучу брутфорс симметричных алгоритмов и взлом асимметричных, не являющийся брутфорсом?
> их сводится к проблеме поиска коэффициентов кривых.
Каких коэффициентов? Коэффициенты все известные.
> Не исключено что найдут реальный epic fail
За 9 лет в 25519 не нашли что-то.
> равносилен как бы будет 2**64,
Откуда такие сведения? Как я понимаю, для квантовых компьютеров из-за особенности их работы, проблема P=NP просто не будет математически сложной. Ну и RSA пиндык, как алгоритму. Да и эллиптике возможно тоже.
> тогда как у ECC не доказано что они безопасны в принципе.
Это же можно сказать и про RSA. В смысле, за 9 лет для 25519 вполне себе и теория появилась и криптоанализы были.
> Хм, вы считаете госструктуры полными дураками не разбирающимися в психологии?
Я считаю их powerful adversary. Имеющими мотивы и возможности для того чтобы гадить. И глядя на то что напихали в стандарты я имею заметить что в психологии у них все оки-доки. Вот такие как вы ведь носятся "зато стандарт!", "можно же подкостылить!", "вы можете разминировать TLS, если у вас квалификация ракетчика!". Вроде они таким как вы вполне успешно скормили стремный крап и вы даже готовы защищать оный с пеной у рта. Ну то-есть то что у сноудэна написано - прямо как по нотам все.
> что если активно что-то проталкивают, значит дело запросто не чисто.
Ну так DJB как таковой никогда ничего активно не проталкивал. В отличие от NIST. И да, почему-то интел делает команды AES, а не SALSA или 25519. Кто там что и куда с нахрапом проталкивает?
> его Бернштейн поливает, он круче всех,
Человека видимо элементарно достала текущая ситуация и он позволил себе высказаться что он думает по поводу впаривания фуфла. С учетом документов сноудэна выглядит правдоподобно.
> хотя госы уже давно со своими математиками
А с чего вы взяли что эти математики принципиально лучше (или хуже) академиков из того же CACE? И да, если в DualEC бэкдоры нашли - наверное и остальные криптографы что-то в своем ремесле смыслят, или где? :)
> ржут над его решениями и радуются что их везде впихивают.
Для начала я не вижу чтобы их "везде впихивали". Стандартизируют какой-то стремный и проблемный крап в основном. А потом еще и в процессоры с нахрапом впиливают и прочая.
> У вас есть сомнения -- у меня нет, не скажу откуда.
Ну еще бы. Тезис о том что можно скупить всю планету - не выдерживает никакой критики. Вон в DualEC почему-то довольно быстро бэкдоры нашли. Странно, почему же всю планету не скупили чтобы криптографы молчали в тряпочку? В результате и NIST и RSA (контора) потеряли доверие.
> на это у считанного кол-ва стран.
Так проблема - в специфичных материалах, которые на дороге не валяются. И в процессах требующих кучу оборудования.
> Математика… математиков заприметят гораздо раньше
> и возьмут под контроль чем он успеет ляпнуть что-то лишнее.Да вот что-то с DualEC это не очень получилось. Ваши тезисы не подтверждаются практикой.
> Много кого долбануло? Ну ну.
Очень много кого. И банки, и кучу серверов, и даже лично меня - предпочел сменить все ключи, т.к. дыра была давно, кто о ней знал - неизвестно, так что сложно установить - что могло утечь. Проще посчитать что утекло все. Атака легкая и сдампить память ремоты через нее фигня вопрос. Можно на хабре для начала посмотреть - как там юзеры строили банки и т.п..
Но да, я теперь кажется начинаю догадываться почему вы пытаетесь даунплеить масштабы проблем. Это или отутствие компетенции, или того хуже - осмысленное желание втравить нас в несекурные алгоритмы. Размахивание гостом и стандартами лишний раз наводит на такую мысль.
> Я у того же Шнайера не видел нигде "нежелание". Есть "если можно,
> то попробуем сделать без этого", а не нежелание.А я вижу что практически все новые алгоритмы - от таблиц отказались. Как раз из-за кэша.
> нечто чем-то хорошее, а чем-то совершенно не удовлетворительное.
Ну вот мне ssh нравится все меньше. Там больно уж много грабель порылось.
> Padding лично мне много где не то что не сдался:
А я вот помню что "безопасность бывает 2 уровней: high и нехай". И последнее что я буду делать так это экономить траффик в секурной сессии. Тем паче что я поэкспериментировал с IRC over Tor (сойдет как грубая оценка влияния padding на интерактивный протокол) и не заметил дикого потребления траффика. На малоактивных линках оверхед может быть процентов 40. На большом потоке оверхеда можно считать что нет.
> а не нужен из-за трафика, который стоит денег.
Если некто разорится на секурной сессии - я не понимаю как он остальным интернетом пользуется. Похоже на подтасовку фактов чтобы люди не стали пользоваться секурными протоколами.
> Плюс какие вы алгоритмы оставите?
> Опять купленного властями Бернштейна и всё?Я DJB доверяю больше чем дискредитировавшему себя NISTам и прочим гостам. К тому же, DJB доверяют и опеночники: они не только поюзали эти алгоритмы, но и сделали их максимально приоритетными в новых версиях ssh сервера. Как раз 25519, chacha (близкий родственник salsa) и poly1305.
> А если я для Рф хочу сделать железку, то для этого надо ГОСТ,
Меня не интересует Имитация Бурной Деятельности вместо безопасности, извините. Я не играю по заведомо невыигрышным правилам.
> который медленный, но в железке вполне себе безопасный будет.
Когда некто крайне нахраписто и нагло всучивает именно свой алгоритм (DJB до такой борзости как законодательные регуляции как пехом до Пекина) - это вызывает вопросы о мотивах такого впаривания.
А так - в железке алгоритм может быть и быстрым. Ну там s-box в скоростном SRAM, железные блоки и прочая. Там и проблема с кэшом может отсутствовать. Вот только я не могу проверить как это сделано. И потому доверять этой реализации не буду.
> Но у вас же его не будет?
Я занимаюсь впариванием и втиранием очков - так что не будет.
> на любителя. Таких подeлий сделано куча и уже давно.
Не, блин, буду впариваемый с нахрапом (законодательно аж) гост использовать, медленный и с кучей непоняток. Для меня приоритет - фактическая защита данных, а не "соответствие стандартам" которое суть ИБД.
> Да, сделали так. Потому-что вроде как лучше, а не потому-что прошлый вариант
> был в плане безопасности сильно хуже.Большинство криптографов проблему с кэшами и утечками распознало и признало. End of story.
> Дико оторвано от реалий это паранойа по поводу кэшей,
Дико оторвано от реалий - пользоваться гостами "потому что гестаповец с автоматом сказал что это безопасно" (ну или AES, "потому что внедрили в проц").
> стоит ОС из миллионов строк кода. Атаковать будут её/библиотеки,
Ремотно вывешены далеко не все либы. И вот тут мы видим heartbleed. Или вон ту дыру в polar ssl.
> Реалии это подставить ведро и менять его, если на всю крышу многоквартирного
> дома идёт тоненькая струйка, а не бросаться менять всю крышу полностью,Вот вы и живите в доме с дырявой крышей. А мне не нравится жить в холупах.
> что имейте возможную протечку, а не то что это равносильно отсутствию крыши.Мне не нравятся дырявые крыши.
> Не правда. Большинство связаны с тупо обычным программированием
А чем сложне протокол - тем больше кода. И тем больше там багов. За это я и не жалую TLS и прочие.
> Потому-что я меньше доверяю продавшемуся DJB у которого никакого запаса прочности.
А я меньше доверяю вам. С вашим втюхиванием гостов, SSLей и прочим крапом при минимуме технических аргументов и только рассказами про "время выдержки" при игнорирование проблем признанных криптографами.
> PRNG ОС отличается от того что в потоковом шифре. В ОС энтропия
> постоянно (должна) поступает,Ну да. Там обычно пул энтропии, при том сделанный так что отдельные неидеальности отдельных источников ничего не портят. В линухе этим даже более-менее можно пользоваться.
> и всё. Хотя да: примитивы могут быть схожими.
Где как.
> Ага, с вашим подходом типа только Бернштейн в состоянии что-то кодить.
Не настолько уж и неправда - криптографическую либу должны делать те кто разбирается в криптографии. Иначе получается такое как openssl.
> Все — люди: и все люди допускают ошибки. А также продаются.
Людей много, а наблюдаемые факты можно коррелировать. И если мне нахраписто всучивают AES и ГОСТ, а NIST попадается на пробэкдореном PRNG - определенные выводы по поводу того кому лучше доверять - напрашиваются.
> Составные части - для тех кто понимает что и зачем он делает.Могу поспорить что каждый будет понимать и знать для чего его составные части. И поэтому их будет юзать. А сказать ему что он всё-равно криво сделает и пусть юзает cryptobox: его это просто обидет. Ну мне так кажется.
> Любую криптографию можно профакапить некомпетентностью.
Ага, и поэтому мой выбор это криптографию которую обмуслёкал уже каждый кому не лень, где известны все возможные подвохи как математические, так и то что делают на практике. Старые добрые RSA и прочее.
> эти требования выполнены - при использовании этих апи все будет ОК.
> А обезьяна с гранатой - это всегда обезьяна с гранатой.А люди такие. Даже Шнайер вон забил советовать юзать CTR, пусть уж у обезъян будет граната поменьше в виде CBC.
> Blowfish морально устарел и никакого смысла в нем имхо нет.
Лично я не признаю понятия "морально устарел" в технике. Если оно работает -- незачем менять. Это как "обновление ради обновления" -- тупейшая вещь IMHO но которую делают постоянно. Кроме BF лучше выбрать конечно другое, но вот я ставлю себе OpenSSH, не доверяю я AES, не доверяю молодому DJB которого даже госы не слушают, не доверяю госам (а это CAST идёт нафиг), не хочу 112 бит 3DES, не хочу очень стрёмный RC4, и у меня остаётся только blowfish среди доступных алгоритмов. Да, было бы здорово twofish, но не буду же я садится и кодить только с собой совместимую его реализацию в OpenSSH. Twofish лучше, но BF is good enough. В компьютерном мире часто часто можно встретить что что-то явно лучше всех, но его не юзают потому-что оно и так is good enough. Например Plan9 -- убер клёвая ОС архитектурно, но даже авторы признают и понимают что UNIX всем хуже, но свои задачи выполняет достаточно хорощо. Делать что-то новое на BF наверное смысла нет, но зато он есть в IPsec реализациях каких-то, есть в OpenVPN. Плюс немалую роль играет политика: BF патентно и в остальном чист -- бери и юзай кто хочешь.
> Бернштейн имхо в этом правее: таким людям *нечего* делать в низкоуровневых деталях
> алгоритмов. Таким надо апи по типу криптобокса. Это он очень правильно
> заметил.Но cryptobox его точно не будет годен для видеопотоков шифрованных. Тут уж процессоры хотят поберечь, ибо слишком. А по вашему компании которые должны делать видеопроигрыватели будут нанимать программистов смыслящих в криптографии? Дорогова-то. Позиция Apple тут безупречна: и надёжно и релизовать проще некуда. Если не надо писать с нуля свой AES, то ощибок в их реализации сложно допустить (я не представляю как), зато производительность будет вполне себе юзабельная. DJB не может ничего такого предложить. cryptobox не подойдёт из-за ресуров, а низкоуровневые вещи его сложнее чем CBC с IV.
> А обычные апликушники должны дергать криптобокс, а вовсе не.
Вот это мне и не нравится.
> Вот вы ими и пользуйтесь. А мне как-то неохота греть мозг вопросом
> "а что еще может работать на том же процессоре".Вот не верю что вы так сильно уверены просто в ОС которая хорошо обезопасит вашу RAM. Вот я и буду запускать :-)
> Базовый кирпичик шифрования в сети.
Медленный он. Да и если люди которые даже не хотят знать что такое CTR/CBC/whatever берутся за крипто (не говоря о том что они бы могли бы знать, но просто криво реализуют), то гарантированно ключи на двух сторонах сгенерируют коряво. Это всё-равно мартышки с гранатами и дай им гранату без чеки, ровную и гладку -- всё-равно найдут способы пострашнее как её использовать. У cryptobox остаётся всё-равно генерация ключей, а это PRNG, а это исключает целые платформы типа Apple где PRNG созданы АНБ. Не поможет этот DJB ни в чём. Лучше прочитать и узнать про алгоритмы, попытаться реализовать SSHv1, лохануться, реализовать SSHv2, тоже лохануться, но потом заиметь и уже юзабельный алгоритм/протокол и годами отревьювеные перелопаченые Тео Де Раадтом (допустим что он смотрел вовсю) реализацию.
> Тогда шифр Цезаря FTW.
С достаточной силой. В этом форуме уже кто-то говорил про DES, но почему-то не замечает что кроме надёжности и проверенностью временем никто не отменял и силу минимальную достаточную.
> И даже те кто оригинал blowfish делал
> - признали ошибки, "наследник" threefish - без s-box.Threefish не предполагался к использованию вне Skein никогда. Поэтому не надо его сравнивать с тем что предполагалось. Даже если открыть доку по Skein то он предлагает использовать именно Skein как кирпичик для шифрования (как PRNG который XOR-ится), а не Threefish. Но да, он научился на ошибках. Но я снова уверен что вы просто прицепились к кэшу и всё, хотя в RAM у вас все данные лежат и векторов атаки на них КУДА больше. А противостоять загрязнению кэша можно, но в ущерб скорости. Если взять BF, AES, Twofish, whatever и допилить x86-specific код для того чтобы кэш как-то вычищался и это будет раз в пять медленнее: меня это устроило бы, это всё-равно приемлимее моего доверия к DJB.
> Я уточнил. Blowfish криптоанализировали. И нашли проблемы. Да что там, даже я
> их вижу - пачка s-box это отрыв от современных реалий и
> пофигизм на проблемы эксплуатационщиков.Вы просто преувеличиваете проблемы с S-box-ами. Это как когда RSA ключи утекали через писк конденсаторов. Можно заменить кондеи, добавить что-то, либо чуть добавить кода который будет чуть медленнее, но фиксит проблему. Шнайер вот не раз повторял что допустим шифр сильно поломан: 2/3 раундов, так что мешает просто увеличить количество раундов в три раза? Будет в три раза медленее, но зато если дальше не ломается что в чём проблема? Аналогично например сделан наш ГОСТ: просто тупо берётся мног ранудов, sbox-ов и прочего и атаки есть, но на практике не применимы. А вы сразу: в утиль, устарело, так не делают, итд. Если сила ключей например или там SHA1 ломается до 2**68 вместо 2**80, то можно взять и увеличить выхлоп и юзать медленный SHA2, но у которого выхлоп конечно не имеет 2**128, но его будет достаточно. И я такой же позиции. Если работает, то не трожь, Чего-то не хватает относительно простого: добавь. Загрязняется кэш оптимальным по скорости алгоритмом: сделай не оптимальным, но чтобы кэш не загрязнял, очищал. Это возможно сделать, никто не запрещает. И я выберу то что искромсано десятилетиями проверок и оно меня всё-равно устравивает (запась безопасности достаточен) чем нечто в принципе совершенно новое. Когда-то это новое возможно перейдёт в разряд проверенных временем и искромсаных -- я обновлюсь. Кто-то радуется что он это сделал 10 лет назад -- я рад за него. Но мои нервы и безопасность превыше всего. Любое оружие проходит долгие испытания, полевые испытания и только потом его принимают (ну когда кач-во и надёжность действительно важно). Я думаю банки очень беспокоятся о безопасности своих каналов передач: до сих пор 3DES вовсю. 3DES то как появился: когда стало понятно что компьютеры слишком круты и 56 бит мало. Ну берём и добавляем последовательно ещё три блока (EDE): хватит 112 бит, хватит, ok.
> А может ваше? Я существо рациональное. Мне нормальные аргументы подавай и внятную
> логическую цепочку. А этого я не вижу. В частности ваши сведения
> про AES и MD5 имхо неверны. И грабли в blowfish видят
> все. Даже его автор. Который (совместно с еще рядом людей) сделал
> работу над ошибками. Threefish называется.Почитайте комментарии в статье Skein блога Шнайера и убедитесь что он нигде не делал Threefish как блочный шифр который предполагается использовать вне Skein. И почитайте опять же его же комментарии на его же schneier.com чтобы убедиться что он советует применять (когда стоит выбор) Twofish, но не говорит что BF поломан так что не юзабелен. Мои доводы основаны на том что я прочитал лично у автора.
> И грабли с утечкой через кэш -
> штука не новая. Но NIST их почему-то проигнорировал.Да потому-что её проще предотвратить, так же как и добавить просто два DES к DES чтобы сделать 3DES. Кэш это возможный вектор атаки, а не то что алгоритм не юзабелен. И AES не только в софте и не только на процах с кэшами используется: полно и аппаратных у которых этих проблем нет.
> Похоже на слепое следование ничем не обоснованной догме, если не подтасовку фактов.
А у вас я вижу слепое: нашли вектор атаки и сразу в топку. Так вы каждую пяти-десяти-летку будете бросаться из алгоритма в алгоритм как только в них будут находить дополнительные возможности атаки. А такие как я -- просто будем их фиксить, пусть и в ущерб производительности небольшой.
> MD5 или даже Dual EC тоже внедряется, а openssl вообще везде. И?
Они внедряются потому-что госструктуры диктуют это. Так же как в РФ запрещено использовать для крипто ничего кроме ГОСТа. Он медленный что хоть повесься, но надёжный. И там люди подходят к надёжности вот так же как и я: вместо того чтобы сомнительно тратить кучу денег на криптографов, если можно купить железо помощнее и увеличить кол-во ранудов, sbox-ов, длин ключей -- то проще сделать так.
> ...и принял участие в создании threefish. Который работа над ошибками. В частности
> - никаких s-box! И чего бы это вдруг? Ах, он тоже
> догадался что утекать состояние через кэш - хреновая идеяПочитайте его whitepaper про Skein где в начале даются небольшие пояснения что и почему они делали. Кэш это один из возможных векторов атаки, на всякий пожарный, а не потому-что must-have попытались избавиться от sbox-ов -- получилось. Вы делаете из мухи слона. Надо задуматься что такой вектор атаки есть, но не стоит делать из этого катастрофу. А если вы запускаете там где одни сплошные облака, Xen на OpenVZ под KVM -- то вообще какая речь может в принципе идти о безопасности, а вы так паритесь про кэши. Из мухи слона.
> Там у них как раз вон дока с описанием слабых ключей blowfish.
> А Шнайер пошел переделывать алгоритм, чтобы не утекал данные через кэш.Снова повторюсь, чтобы вы прочитали что написал Шнайер: он не переделывал алгоритм блочного шифра. Точнее переделывал, но это было давно и называлось Twofish. А он делал хэш-функцию в которой решил применить в качестве ЕЁ кирпичика Threefish, не предполагавшегося к использованию вне него. В самом же whitepaper написано что для шифрования он предлагает использовать Skein и никак иначе.
> упереться рогом - можно использовать и устаревший алгоритм и греть себе
> мозг отсевом слабых ключей и вопросами что еще запущено на том
> же CPU. Дело хозяйское. А мне так не нравится.Ну я уже вон тыкнул что вы плохо читаете что для чего сделано, а я то всё же конкретно в контексте этой темы имел в виду что blowfish можно рассматривать к использованию в SSH. Так то я в PGP ключах и для полнодискового шифрования применяю Twofish, потому-что читаю и слежу за рекомендациями. Но BF не фатален. Тьма шифров имеют атаки и взломы быстрее brute force, но кому какая разница если сила 256 бит ключа сводится например к 202-м -- этого тоже хватит, а вы явно будете выкидывать его на помойку. Это очень не рационально.
> RSA всучили его клиентам. Ну вы как бы пользуйтесь софтом от
> RSA, по стандартам NIST - идеальный шторм! :).Снова повторюсь, что софт от RSA, который вроде бы в массе своей закрытый я даже подумать не мог чтобы использовать. Я про алгоритм говорил RSA.
> Вообще-то из за тормозливости надежность часто приносят в жертву. В том числе
> в DNSSEC. Который судя по всему еще одна бесполезная декорация по
> типу SSL будет.DNSSEC сразу же не юзабелен в полной мере из-за того что надо доверять высшим каким-то ключам. Но если это защитит от 15-летних кракеров, то действительно скорость там важна. Иногда жертвуют безопасностью ради скорости: согласен, RSA 4k реально очень медленный. Но надо смотреть на контекст применения. Если речь про единицы/десятки его использований в секунду -- это одно, если миллионы -- это другое. А вы сразу же хотите найти универсальное решение. Повторюсь: у 25519 запаса уже нет (инженеры негодуют где нет двухкратного запаса прочности, а 256 ключ (на самом деле 251 как опять же пишет DJB) равносилен 128 бит симметричному).
> Никакая реализация не меняет общие свойства алгоритма.
Меняет и ещё как. Изначально никто не ожидал что можно будет получать приватные RSA ключи анализируя поведение процессоров, ведь чисто математически этого нигде нет. В корне меняются свойства алгоритма.
> А к чему еще оно может сводиться? Ну кроме случаев явного бэкдоринга.
Я не криптограф, но криптографы не доказали что только к этому, в отличии от ElGamal, RSA и DH.
> У Шнайера и Берштейна есть жирный плюс: они не были замечены в
> западлостроительной активности. В отличие от RSA и NIST, например.Не были замечены это не значит что не участвовали. А Ади Шамир работал в RSA :-). Теперь он никто после этого? Не, не справедливо. Не пойман, не вор типа :-)?
> Ну да, NIST успел стандартизировать а RSA - втюхнуть клиентам. Такие вот
> стандартизаторы и криптоаналитики.RSA алгоритм вполне юзабелен. Его всё меньше юзают из-за скорости, но проблем у него при корректной реализации и длине ключей нет.
> ИМХО, тезис о том что RSA безопаснее чем нечто еще - вилами
> по воде писан.Эээ, это вы тоже вилами написали. Я смотрю на криптоанализы.
> Вообще worldwide. Так можно послать ОДИН ПАКЕТ. Без хэндшейков и прочего. Сетевое
> шифрование должно было быть каким-то таким с самого начала.Бред полнейший что так должно быть. Хотя бы с простого начать: nonce какой будет? Рандом из PRNG? То есть добавлять его к каждому пакету? Я против того чтобы загромождать трафик. Nonce бы сделать счётчиком, который тоже можно дописывать, но он маленький. Что делать когда пакеты теряются? Как предотвращать replay пакетов? Вот именно тут уже и появляется понятие протокола. А то что хотите вы: трата ресурсов и трафика. Так быть НЕ должно.
> Смотря что от него надо. Cryptobox обеспечивает защиту и неподделываемость пакета. Если
> ремота может его расшифровать - это пакет который сформировал отправитель. С
> другой стороны, поскольку это по факту DH, из половинки приватного и
> публичного ключа, но разные половинки с разных сторон линка - получатель
> знает shared секрет и может произвольно подделывать содержимое. И не может
> доказать что ему это прислали а не он сам это сгенерил.Что то у меня всё больше закрадывается сомнений в вашей компетенции. Без обид, но возможно я просто не так понял. Если я смогу расшифровать: а как я пойму что я смог расшифровать? Шифр даже потоковый это вход шифротекста (рандом) и какой-то выхлоп plaintext-а. Plaintext-ом может быть и рандом тоже. Нет возможности проверить успешность дешифрования. Для этого и нужна аутентификация пакетов. Если вы подразумевали успешность выполнения функции типа cryptobox_decrypt, внутри которой она сама проверит poly1305, то тогда да, нарекайний нет и сомнений в начале абзаца. Только cryptobox не защищает от replay атаки. Просто так уже VPN не сделаешь. Нужен протокол. И… добро пожаловать корявостям, ошибкам и всему аду известному в SSH, IPsec, TLS, whatever :-)
> В чем круть? В том что зная 32 байта можно пульнуть сообщение
> которые расшифрует только обладатель парного им привкея и у него будут
> гарантии что это сформировал обладатель вон того пубкея. Все это дает
> ряд интересных возможностей о которых вы, вероятно, никогда не задумывались. Например,
> обмен ЕДИНИЧНЫМИ ПАКЕТАМИ. DH без хэндшейка? Почему бы и нет?Я не могу представить use-case. Честно. Честно-честно. Почему бы и нет, всё верно. Но не вижу применений на практике этого. Так то я и openssl enc (или как там командочка для шифрования) могу применить и сделать даже через командную строку hmac на пакет и отправить это. Реально это займёт пару минут. Только вот не припомню чтобы оно мне надо было. А, не, надо, но это называется PGP у меня. ECC, если так нужна скорость, в нём появилась. Вернеру Коху я доверю реализацию. Не вижу я применений cryptobox вот просто так. Опять же только ради скорости chacha/poly? Нет, я останусь на PGP.
> вещей - надо защиту от реплея. Если надо. Ну там timestamp
> или sequence number. Ну и PFS прикрутить. Несложно сделать путем перекидывания
> сообщениями с новыми ключами в обе стороны линка. А аутентичность сторон
> гарантирована на уровне устройства сryptobox.Оу оу оу! Сделать? Прикрутить? Прокидывать? Да это же и есть протокол! Вы думали что протоколы это всегда нечто монструозное с ASN.1? Вовсе нет. OpenVPN протокол (не считая обмена ключами) тоже просто донельзя. SSHv2 в целом тоже прост. А как вы будете прокидывать? Вот тут то и родится протокол в котором и будут делать ошибки, DoS-ы, вам придумывать защиту от replay атак не только пакетов простых, но и служебных в которых что-то будет прокидываться, в вашей (не конкретно вашей, а в общем) реализации запросто будут ошибки проверок, буферов, и всему этому прочему. Я именно про это и говорил: cryptobox кирпичик, но чего-то такого что и будет ломаться, как это происходит с 99.99% всего крипто софта. Ломается не AES или DH напрямую, а реализации. То что вы напишете/прикрутите/обменяете это уже не DJB написал и поэтому доверие сразу в нейтральную позицию как минимум.
> Т.е. почти нахаляву можно отбабахивать P2P-style протоколы где peer однозначно идентифицирован
> 32 байтами. Да еще по сути без handshake.Дык давно все так и делают. Львиная часть протоколов для всяких сетей анонимизации это фактически по сложности тот же самый cryptobox. Как бы... для вас эти все творения DJB как-будто бы новость. Посмотрите на всё что касается темы secure, anonymous, бла бла бла и чтобы было новое: оно очень часто всё также и устроено. Ноды идентифицируются даже не по fingerprint-ами, а прямо по публичным ключам (GNUnet кстати так и делает), передача сообщений очень простая и примитивная. Всё упирается уже в протокол, rehandshake, replay, и прочее.
>[оверквотинг удален]
> сторон линка можно было бы просто добавлять долговременый публичный ключ противоположной
> стороны как "доверяемый" (в конфиг, etc). Он и ключ шифрования (как
> минимум для начала сессии) и замена fingerprint. Для повышенной анонимности передавать
> публичные ключи сторон опционально: можно их неявно подразумевать на основе например
> прописаных в конфиге, etс (можно и более интересные варианты придумать). Ну
> и PFS разумеется - сделать пару временных ключей с каждой стороны
> и перекинуть в начале сессии в первых сообщениях новые публичные ключи.
> Судя по всему получается похоже по смыслу на то что у
> вас, только с другого бока и можно готовый cryptobox юзануть. Такой
> вариант чем-то плох?PSK используется только для двусторонней аутентификации DH сообщений. Если я уберу эту аутентификацию, то действительно конечно работать ничего не будет, так как если ключ кривой противоположный, то shared secret будет разный и все сообщения будут невалидны. Но, я это могу понять только косвенно после передачи шифрованных пакетов что они в массе своей не валидны. "Он и ключ шифрования": он это публичный ключ curve25519, а ключ шифрования... как в случае потокового шифра лучше бы его делать другим. Полагаться на PRNG для nonce что он не повторится от сессии к сессии -- стрёмно, лучше положиться на PRNG ровно один раз во время DH и при этом энтропии надо будет 32 байт. Никакой речи о статическом ключе шифрования не может быть, поэтому только DH который обеспечит PFS. Если опять же публичный ключ 25519 будет статическим (как вы и предлагаете) то результаты DH будут всегда одними и теми же и надо ещё придумывать как сгенерировать ключ и передать. Чтобы не придумывать как это сделать я юзаю 25519 всегда с чистого листа: DJB за меня всё придумал уже как сделать ключ. Плюс если я передам публичный ключ пускай даже по DH, то это лишние пакеты связи и от меня утекают данные о том кто я. В случае с EKE от меня не утекают данные о том какой же ключ у меня прописан. То есть это zero-knowledge. У меня абсолютно ничего нового чтобы я придумал сам: DH-EKE известен давно, очень давно и хорошо проанализирован.
Более того, если предлагается например сделать DH, по нему передать свой публичный ключ (типа аутентифицироваться), а потом сравнить и начать передавать данные, то кроме того что публичный ключ утекает (утекают данные, плохо), есть вероятность что его можно и узнать и так как-нибудь, но не знать приватного. Тогда мы отошлён "доверяемый" публичный ключ и нам начнут передавать шифрованные данные. То есть трафик начинает сливаться лицу который ещё не аутентифицирован по-настоящему. Вся надежда что шифрование сильное, но запросто возможен просто сам факт возникновения/частоты/размера трафика -- эти данные начнут утекать. В варианте DH-EKE абсолютно никто до момента как полностью удостоверится что PSK на той стороне настоящий не начинает передавать трафик и нигде не сливается даже хэш какой-либо ключей.
В итоге получается хороший пример когда если бы VPN был реализован чисто cryptobox-ом, то он бы стал отправлять трафик уже. Его не дешифруют, но его данные о размерах и частоте пакетов будут утекать, хотя бы какое-то время. Или даже ещё страшнее: никто не заставляет делать heartbeat и трафик просто будет отсылаться, а сервер даже не знать что сливает тому что не может дешифровать. Так что аутентификация обязательна. Вопрос как её провернуть. cryptobox, NaCl дадут разве что ed25519 который самостоятельно надо заюзать, а просто так сам по себе ed25519 это не zero-knowledge протокол. Плюс это ещё один примитив криптографический и гораздо более медленный чем симметричный шифр (EKE именно их использует). DH-EKE не единственная ZK mutual authenticated key exchange система само собой. SRP такой является например, но там не PSK, а парольные фразы.
> А какой 25519 стандарт? Его кто-то успел стандартизировать?
Не, это я не дописал "не".
Это сообщение получилось безанадежно большим.
Если ответ на него хочется увидеть:#include http://rghost.net/60476058
Ну в общем особо отвечать я уже устал. К консенсусу мы не придём -- разное мировоззрение.Замечу что OpenVPN не основан на TLS. Он его может (но не обязан) использовать для обмена ключами/аутентификации и на это всё. Остальной протокол -- его родной и независимый от TLS.
Шифровать видео, иметь DRM это не средство исключения того что видео нельзя будет достать. Это средство повышения порога входа для этого. Если деньги затраченные на DRM будут значительно меньше денег затраченных на преодоление порога входа дешифрования видео -- DRM выполнил свою роль успешно. Вы не понимаете суть для чего DRM нужен, воспринимая только маркетинговые слоганы что мол это типа чтобы не дать пиратам вообще возможность копирования.
В Linux качественный пул энтропии? Честно говоря, вы меня насмешили. Видители TLS то ещё дерьмо, а /dev/random в Linux годный? Особо дальше комментировать не буду уж эту тему.
Касательно закрытых (проприетарных) систем -- это всё очевидно что там даже не будет PRNG.
Чтобы сгенерировать KDF(password, salt) вам salt надо взять рандомную. Без рандома качественного никуда.
>Это не у меня. У меня открытая система, которая подчиняется мне. А в проприетарных системах рассуждизмы про шифрование - windows xp with firewall.jpg (cпросить у гугля).
А я хоть раз говорил вообще про совместимость понятий безопасности и закрытых систем? Если у вас открытая система где всё от и до подчинаяется вам, то это идёт врозь вашей боязни AES. А если где-то на другом конце у вас неподконтрольная вам система: то какая разница какой алгоритм и вообще что вы будете делать, раз априори никакой безопасности не будет. Сам же себе противоречите. Или у вас где-то есть закрытое ПО -- тогда вообще пофиг что использовать ибо априори пагубно, или у вас всё подконтрольное и открытое -- тогда не ясно что вы паритель о AES и прочем. В последнем случае парится можно разве что о производительности.
Касательно ГОСТ: в отличии от DES/AES и прочих, в нём разрешено применять собственные S-box-ы, а не заранее рассчитанные в которых могут быть лазейки.
>Криптографы ушли от этого в новых схемах.
>Результирующие дизайны также будут основаны на этом core, оно не использует таблиц. То-есть, про отказ криптографов от таблиц я нигде не наврал.Похоже вы не следите за новостями чтобы делать такие заявления. И как всегда преувеличиваете масштабы. Отказ одной команды в одном whitepaper это не отказ криптографов.
>Это говорит мне человек, заботящийся о проприетарных системах, где ядро заведомо работает на чужих дяденек? Хм.
А это уже явная клевета и враньё. Замечу что я член FSF, FSFE и EFF -- так что вы зря называете меня человеком который "заботится" о проприетарных системах и небось ещё у вас даже мысль могла промелькнуть что я их где-то использую или что-то под них пишу? Хорошо что не написали об этом.
Это формальные придирки. У меня не было цели пиарить threefish. Была цель проиллюстрировать эволюцию мышления криптографов под воздействием обнаруженных проблем.
Вы вроде тот человек который сказал что не бывает мелочей в криптографии? А я отчётливо вижу что вы сравниваете один из кирпичиков используемых в хэш-функции с симметричным блочным шифров.>По этому поводу RSA 4096 используют лишь чуть чаще блокнотов.
Опять же ваши догадки на пустом месте. Я почему-то RSA 4k вижу регулярно в контекстах PGP.
Про nonce/replay в контексте cryptobox: я намекал что cryptobox мало чего решает и что даже вокруг nonce можно много и долго думать как лучше. Можно синхронизировать часы и не писать nonce, можно юзать PRNG, можно делать счётчик, итд, итд. Много чего можно сделать и везде есть свои плюсы и минусы. Вы не боитесь увеличения трафика? На 24 байта -- ok. А ещё и padding хотите? Очень здорово когда вам не предъявляют требований по трафику. А когда это превратится в большие деньги, то вы начнёте сравнивать стоимость трудозатрат на получение какой-либо полезной информации выуженной из анализа статистического поведения трафика и стоимости трафика. После какой-то планки они поменяются местами и вы откажетесь от padding. Везде разные требования, условия -- именно поэтому не делают 200 разных реализаций SSH: в одной будет padding, в другой не будет padding, в одной нужно синхронизировать время, в другой не нужно. Именно поэтому люди вынуждены делать один SSH с 200 разными опциями, так как это дешевле в плане разработки, поддержки и даже аудита.
При этом вот у вас защита от replay может быть даже и никакая. Хотя у меня это строжайший must-have, так как дубляж ровно одного UDP пакета который заставляет где-то срабатывать триггер может стоит очень дорого. Запоминать последнее значение счётчика и отбрасывать всё остальное: хорошее решение, но из-за которого может дропаться много пакетов из-за того что в разном порядке пришли. Где-то лучше так, а где-то производительность стоит дороже и допустимо оставить небольшое окно для атаки. Да, оно будет -- но на практике не применимое. В GoVPN я кстати сделал это как настраиваемую опцию: чтобы кому как надо, тот так и сделал. Именно поэтому появляется много опций и не существует убер-решения.
Согласен что трата ресурсов может быть и разумной. А может и не быть. 4% overhead если будет составлять стоимость 4% от переданного трафика за который могут платить большие деньги — хороший повод задуматься. Ну и смотря какой трафик конечно же. Если это частые, но мелкие пакеты -- overhead существенный. Можно буферизировать, но delay может быть недопустим. Итд. Может быть, а может не быть. Лично для себя я сразу вижу что чистый cryptobox слишком медленный будет даже для моих домашних нужд.
>Это говорит человек, только что призывавший увеличивать количество раундов в старом крапе в 3 раза? Двойные стандарты такие двойные.
И опять бесстыжая клевета. Я призывал увеличивать кол-во раундов в том что является на данный момент надёжным и проверенным и где процессорное время будет дёшево. В старый "крэп" это превратилось уже в будущем, но до сих пор этот старый "крэп" удовлетворяет те же банки, потому-что реализации в железе были дешёвы и быстры. Это наиболее дешёвое и надёжное средство было.
На заметку: в PGP никто не обязует делать подпись в обязательном порядке. Deniable encryption с ним не сделать, но оно и не всем надо. Кому надо -- другой инструмент. А кому-то это только вовред.
>DJB в криптобоксе берет на себя массу сложных проблем
Он решает самые простые задачи в которых уже давно никто не делает ошибок. Он ничем не помогает значительно. PFS, replay -- вот и готов очередной SSHv2 или почти TLS.
>Я думал что вы пальцуете. Рассказывать мне про протоколы - затея неблагодарная.
>OpenVPN протокол - основан на уберсложном TLSНеблагородное говорите? Ну вы же снова показываете незнание простого OpenVPN в котором спокойно можно жить без TLS. Нет, вы не знаете про протоколы и не знакомы с реальностью чтобы предполагать и удивляться почему так много "legacy", "crap" и отсутствие единственного убер-решения.
>Не вижу никаких особо фундаментальных проблем на этом уровне. А у гнунета все упирается в общую невнятность и местами странные решения.
Я не удивлён уже.
>Все пакеты с неправильных (неизвестных) ключей и просто рандомный мусор будут невалидны. Just as planned. Это чем-то плохо?
Я уже говорил: если это VPN, то факт посылки пакета (пусть даже который не будет расшифрован) -- это уже утечка данных. Вы регулярно везде не видите у себя под носом то о чём так любите говорить. То вам padding нужен, а то не боитесь что сливается информация о наличии пакетов (но которая да -- не будет дешифрована). Ещё в 80-х годах криптографы и начали много думать о zero knowledge и именно mutual authentication чтобы не сливать даже эти данные. В крипто нет мелочей -- ваши же слова. Вы витаете в мире TLS, IPsec и SSH в которых очень очень многие нововведения (с 80-х годов) не внедряются, зато бесятся по поводу симмтеричных шифров но не переживают по поводу ZK.
>Если PRNG повторяется за обозримое время - это дрянь а не PRNG и ловится самыми базовыми тестами криптографии.
Откройте хотя бы "Прикладную криптографию" Шнайера и убедитесь что есть куча алгоритмов которые криптографы могут предсказать, но ни один статистический тест нет. Вы совершенно не знаете теорию если думаете что тесты ловят качество PRNG. Подчеркну: совершенно, раз умудрились такое сказать.
>Наиболее очевидный вариант - прочесть 32 байта из /dev/urandom. На линухе я посмею засчитать это за нормальный приватный ключ.
Кстати снова рассмеялся. Вы явно не читали статей по поводу того как атакуют именно Linux-овый PRNG. Уже не раз говорил и повторю: вы паритесь о каких-то S-box-ах, но при этом доверяете /dev/urandom Linux-а, который куда проще отравить чем возится с атаками на кэш. Не верите? А я собственными руками его отравлял из user-space так что его выхлопы в другом процессе стали в какой-то мере предсказуемы (требовалось 2**32 переборов чтобы подобрать ключ). Это был Debian 7.0 amd64 из коробки. Кстати решилось довольно просто применением Fortuna в которой /dev/urandom был одним из источников. Но Fortuna реально никак не смог побороть. Linux /urandom -- шутка из серии Dual EC.
Кстати тот же самый DJB делал в прошлом году презентацию о том что люди часто парятся о кирпичиках который никто-никто-никто ломать не будет в здравом уме и будет делать куда более простые вещи (как тоже отравление пула энтропии).
>DJB делает свою либу для *никсов и в открытых системах на более-менее честный рандом можно надеяться.
Надейтесь, а я приму меры (для PGP это например entropy gathering daemon) чтобы не надеятся а знать что отравить энтропию будет крайне сложно. Linux кстати был замечен что как-раз читает аппаратные DRBG с Intel-платформ прям напрямую, потом быстро поправили, но какие-нибудь Тео Де Раадты первые кто послал с этим народ. Linux вообще по мне (чисто по мне, моё IMHO) -- настолько унылая, некачественная помойка кода, в которой сделать что-то безопасно куда сложнее чем отревьювить TLS реализацию какую-нибудь. Поэтому Linux не использую -- не доверяю и считаю полнейшим crap-ом. Есть там хорошие разработчики, но Линус уж чего только не принимает в основное дерево.
>В Linux я пишу валидный и безопасный прототип за пару минут
Мда… а у меня видимо маразм какой-то и я даже под своей FreeBSD всё-равно использую свой entropy gathering daemon?
В общем советую почитать "Прикладную криптографию" Шнайера. Хотя бы про mutual ZK authentication узнаете. Вы слишком много упомянули такого что полностью заставляет усомниться в вашей компетентности относительно того где и как будут применятся какие вектора атак. Переживаете из-за S-box-ов, когда под носом у вас urandom который можно, реально можно, отравить. В следующем релизе FreeBSD кстати будет применятся Fortuna -- что тут уже конечно очень круто повысит безопасность из коробки. И вы регулярно всё максимизируете отправляя что-то в crap (дешёвые на тот момент DES-чипы аппаратные были реально офигенным решением для 3DES -- очень дёшево и очень безопасно (местами до сих пор)), не задумываясь о стоимости атак и стоимости затрат, и padding трафика для вас это must-have, а DRM типа вообще бесполезен. Не говоря уже о клевете.
> Ну в общем особо отвечать я уже устал.Да и я, поэтому если и буду сюда заходить то в фоне и не быстро.
> К консенсусу мы не придём -- разное мировоззрение.
Возможно. Но мое мировоззрение - основано на анализе имеющихся фактов и простых соображениях - что шифрование должно быть простым в применении, при том - достаточно надежным и безграбельным. И оправдывать ожидания пользователей а не подкладывать свинью всем кто не ракетный инженер.
> обязан) использовать для обмена ключами/аутентификации и на это всё. Остальной протокол
> -- его родной и независимый от TLS.С чего мало радости, поскольку в типовых случаях он как раз всем этим пользуется, ну и зависит от огроменной сложной либы (с кучей багов). И вообще, полноценно работать может только так. Без PKI вокруг TLS он, как я понимаю, вообще 1 на 1 только с 1 участником может коммуницировать. А чтоб более чем с 1 узлом линк держать - извольте TLS во все поля, PKI развернуть и по всем связанным с этими затеями граблями попрыгать.
> cредство повышения порога входа для этого.
Выкиньте из головы маркетинговый булшит. Сдернуть видео надо лишь 1 раз - квалифицированному перцу, недостатка в которых нет. А остальные качнут на торентах или где там еще. С порогом вхождения около ноля.
> Если деньги затраченные на DRM будут значительно меньше денег
> затраченных на преодоление порога входа дешифрования видеоКакие затраты? Релизеры снимут DRM'о чтобы померяться длиной с коллегами-конкурентами или just because they can, юзеры вообще нахаляву скачают. А те кто это фуфло клепал - как минимум тратили деньги на зарплаты дармоедам, занимающихся имитацией бурной деятельности. Оплатят этот балаган, разумеется, лохи честно покупающие DRMленый контент. Которых DRM и будет иметь. За их же счет.
> -- DRM выполнил свою роль успешно.
Все что он может успешно делать - обломать легитимного юзера лишний раз да зря тражирить системные ресурсы.
> Вы не понимаете суть для чего DRM нужен,
Я понимаю чего хотят м...ки которые его применяют и понимаю что они сами же и виноваты в результирующем расцвете пиратства. Неправильно это - гадить на голову пользователям за их же деньги. А потом эти фашисты еще и думают что путем пи..лей пиратам дескать что-то поменяется. DRMщики - кучка подлых фашистов, не более.
> мол это типа чтобы не дать пиратам вообще возможность копирования.
Не вижу никаких проблем от DRM у пиратов. Проблемы от DRM бывают только у лохов, которые честно заплатили за контент, чтобы их потом в благодарность - фэйсом об тэйбл.
> В Linux качественный пул энтропии?
Сделан более-менее разумно и люди которые его делают - более-менее разбираются в вопросе. В частности в два счета зарубив инициативы напрямую подать выход хардварного генератора апликухам, в отличие от OpenSSLщиков. Компетентность специалистов - она вот в таких вот мелочах проявляется.
> Честно говоря, вы меня насмешили. Видители TLS то ещё дерьмо, а /dev/random в Linux годный?
Не /dev/random а /dev/urandom, для начала.
> Особо дальше комментировать не буду уж эту тему.
Ну как бы ваше право.
> Касательно закрытых (проприетарных) систем -- это всё очевидно что там даже не будет PRNG.
Там может быть все что угодно.
> Чтобы сгенерировать KDF(password, salt) вам salt надо взять рандомную. Без рандома качественного никуда.
Salt как таковой там нужен лишь чтобы сорвать предвычисленные радужные таблицы. В этом месте имеет смысл очень медленный KDF, желательно memory hard. Ну типа scrypt с приличными параметрами. Юзерь пару секунд подождет, а вот атакующие скоростью типа 1 вариант в 2 секунды на тех же мощностях - будут очень недовольны. И даже радужные таблицы они задолбаются генерировать.
> А я хоть раз говорил вообще про совместимость понятий безопасности и закрытых систем?
Тогда я не понимаю какой смысл был меня лечить что в проприетарных системах вон то может работать плохо?
> Если у вас открытая система где всё от и до подчинаяется вам,
> то это идёт врозь вашей боязни AES.Вы что, совсем глупый, или застряли на уровне использования компьютеров как в DOS? На какой-то моей системе, где ядро подчиняется мне, я однако ж могу например дать логин юзеру (непривилегированному), рулящему вон тем сервисом для его нужд. Вот только мне как-то не в кассу чтобы при этом была возможность тихой сапой умыкнуть ключи.
> разница какой алгоритм и вообще что вы будете делать, раз априори
> никакой безопасности не будет.Опять же - уровень неподконтрольности бывает разный. И степень интрузивности атакующих. Пристраивание на тот же проц позволяет очень чистую, "косвенную" атаку, когда не остается никаких следов в атакуемой системе и нет возможности это внятно детектировать. При этом я даже не узнаю что у меня вообще сперли ключи - никаких аномалий нигде не будет. Это очень плохой класс атак на мой вкус.
> или у вас всё подконтрольное и открытое -- тогда не ясно что вы паритель о AES и прочем.
Даже если у меня все открытое - это не значит что я не могу например немного поделиться ресурсами. Но немного поделиться ресурсами - не синоним "сделать проходной двор". Где каждый будет брать под ковриком вообще все ключи, вместо ключа от своего номера.
> Касательно ГОСТ: в отличии от DES/AES и прочих, в нём разрешено применять
> собственные S-box-ы, а не заранее рассчитанные в которых могут быть лазейки.Есть только 1 загвоздка: ничего не говорится о том как это влияет на криптостойкость и есть ли "плохие" или "хорошие" комбинации. Не говоря о том что схема со "своими" боксами не подвергалась криптоанализу вообще. Как там насчет количества беляшей? Ну или почему в госте такое донкихотство считается допустимым? Он чем-то такой особенный? Вы готовы дать математическое доказательство что любая комбинация S-box'ов будет одинаково стойкая? Или чего?
> Похоже вы не следите за новостями чтобы делать такие заявления.
Вы в вашем праве посрамить меня, приведя пруфлинки на известных криптографов которые заявят что кэши, мол, не проблема. Только чур в NIST не посылать, эти уже показали что они из себя представляют с их стандартизацией Dual EC.
> И как всегда преувеличиваете масштабы.
Только потому что в криптографии не бывает мелочей.
> Отказ одной команды в одном whitepaper это не отказ криптографов.
Это не одной команды и не в одном whitepaper. Это в целом тенденция такая. Большинство криптографов не тyпые и пробему с кэшом признали. И соответственно, таблицы не используют.
> А это уже явная клевета и враньё. Замечу что я член FSF, FSFE и EFF -- так что вы зря
> называете меня человеком который "заботится" о проприетарных системахТогда я не понимаю какой был смысл меня лечить о заботе о пользователях в этих системах. Я не вижу как им можно сильно помочь, при том что их может иметь все системное окружение.
> Вы вроде тот человек который сказал что не бывает мелочей в криптографии?Именно. Поэтому если вы можете прикопаться к мелочам - это хороший признак. Если по делу.
> А я отчётливо вижу что вы сравниваете один из кирпичиков используемых
> в хэш-функции с симметричным блочным шифров.Потому что по факту это тоже алгоритм шифрования. Хотя частично соглашусь - сравнивать напрямую несколько коряво. Но идея была показать эволюцию хода мысли криптографов, а не что-либо еще. Заметьте: алгоритмы шифрования на основе Skein будут основаны на этом core и там тоже не будет таблиц. DJB - тоже пришел к подобным выводам. А если посмотреть - то и ряд других криптографов тоже. Достаточно посмотреть на большинство новых алгоритмов.
> Опять же ваши догадки на пустом месте. Я почему-то RSA 4k вижу регулярно в контекстах PGP.
Регулярно - понятие растяжимое. Какой процент например SSL-enabled хостов в интернете рискнет здоровьем 4K RSA юзать? Ну или там SSH? Им пользуются полтора параноика в почте, где время шифрования пофиг. Ну да, для шифрования полутра сообщений в день, особо параноидальными личностями - сойдет. Только это маргинальные юзкейсы, живущие рядом с блокнотами. А если ssh могут дергать ремотные системы - он мигом становится колом, упираясь в проц. Догадайтесь с 3 раз где.
> Про nonce/replay в контексте cryptobox: я намекал что cryptobox мало чего решает лучше.
Он решает ровно столько сколько заявлено - список гарантий честно и доходчиво описан. Nonce изначально не есть защита от реплея. Хоть и может потенциально быть использован в этом качестве.
В целом я считаю это сочетание достаточно удачным по совокупности параметрам. Он не самый стойкий, но - good enough. Он не покрывает все мыслимые сценарии. Но в результате tweetnacl - лишь 18 кило сишного кода, которые реально прочитать за вечер. В отличие от openssl. Настолько компактные и шустрые, что какие-то перцы запустили это даже на AtMega (удачи туда впихнуть либу TLS). Или всякие там датчики и мелкие (полу)промышленные фиговины с микроконтроллерами в принципе недостойны нормального шифрования? (удачи там RSA 4096 посчитать). Апи - не предел мечтаний, но лучше того что у других, с внятными гарантиями и понятным описанием. Не надо никаких особых скиллов в ракетной инженерии, в отличие от.
> Можно синхронизировать часы и не писать nonce,
Синхронизировать часы с достаточной разрешающей способностью и точностью - сложная задача. Если на уровне зарубания до 1 пакета надо.
> когда вам не предъявляют требований по трафику.
У Tor вон народ содержит дофига серверов и им нормально вроде.
> А когда это превратится в большие деньги,
Большие деньги подразумевают bulk траффик и оверхед на уровне менее 4% скорее всего.
> После какой-то планки они поменяются местами и вы откажетесь от padding.
Я - не откажусь, это не про мои юзкейсы.
> опциями, так как это дешевле в плане разработки, поддержки и даже аудита.
Только потом там оказывается куча разных багов, через которые вообще всем и дофига раз, а какой-нибудь ssh вообше защищает сессию довольно номинально и позволяет нефиговую реконструкцию. Такая вот секурити получается. Наворочено много, а результат - не в пользу пользователя.
> дорого. Запоминать последнее значение счётчика и отбрасывать всё остальное: хорошее решение,
> но из-за которого может дропаться много пакетов из-за того что в разном порядке пришли.О, а вы все-таки не такой деревянный как я подумал и заметили недостаток на который я намекал.
> Именно поэтому появляется много опций и не существует убер-решения.
Именно поэтому мне не нравятся убер-монстры типа TLS - получается 100500 опций на все случаи жизни. Настроить их правильно в результате не может почти никто, а либы получаются сложными, с кучей секурити проблем. И апи невменяемое, коим почти ни 1 апликушник пользоваться не умеет. Сколько программ проверяют не сменился ли фингерпринт сертификата ремоты? Я так 1 знаю - pidgin. А остальные - ну вы поняли. Половина вообще фингерпринт не показывают, так что я даже зная что искать - в пролете. Безопасные соединения, б...
> быть. 4% overhead если будет составлять стоимость 4% от переданного трафика
> за который могут платить большие деньги — хороший повод задуматься.Если сравнить с стоимостью парка серверов для обсчета 4096-битных RSA для всех https сайтов - не так уж и плохо получится :P.
> Ну и смотря какой трафик конечно же. Если это частые, но мелкие пакеты -- overhead
> существенный. Можно буферизировать, но delay может быть недопустим.Есть виды траффика которые откровенно проблемные. То что вы говорите - почти про VoIP. И что характерно, за счет таких рассуждений появились техники реконструкции VoIP сессий на основе размера пакетов. VBR кодеки в паре с конечным множеством звуков/фраз и характерной конструкцией предложений приводят к тому что атакующий даже не зная алгоритма шифрования но зная свойства речи может с хоршей достоверностью реконструировать содержимое основе параметров пакетов, используя размеры и времена. И единственное лечение которое я вижу - немного буфферизовать и паддить. Иначе будет вот так вот, и никакое шифрование не спасет. Ну и CBR кодек и никакого silence detection. Попытка сэкономить трафф ведет к расшифорвке спича. Такой вот tradeoff.
> сразу вижу что чистый cryptobox слишком медленный будет даже для моих домашних нужд.А что насчет beforenm/afternm? Уж не знаю входят ли они в ваше понятие "чистого" криптобокса.
>>Это говорит человек, только что призывавший увеличивать количество раундов в старом крапе в 3 раза? Двойные стандарты такие двойные.
> И опять бесстыжая клевета.Почему клевета? Для меня это выглядит так: древнему хламу мы скидку на медленную работу сделаем, неудобные моменты - поскипаем, а зато какому-нибудь DJB припомним по полной. ИМХО - предвзятость и необъективность.
> Я призывал увеличивать кол-во раундов в том что является на данный момент надёжным и проверенным
> и где процессорное время будет дёшево.Если нечто надежное и проверенное - по логике вещей, там уже было достаточно раундов. Иначе какое ж оно надежное? Кроме того, наобум фигарить новые раунды не будучи криптографом - сомнительная идея. Как местный Pavlinux метко заметил, если два раза прогнать RC4, можно получить свой исходный плейнтекст. Насколько меняются свойства от добавочных раундов - а кто из криптографов это анализировал?! Где криптоанализы? Ах, нету?! Ну тогда бла-бла про повышению стойкости и тем более проверенность временем - ни о чем. На это просто не было криптоанализов и все выводы - на песке.
> В старый "крэп" это превратилось уже в будущем, но до сих пор этот старый "крэп" удовлетворяет
> те же банки, потому-что реализации в железе были дешёвы и быстры.Что там банки удовлетворяет - вообще не аргумент. Их удовлетворяет магнитная полоса без шифрования и 4-значный пинкод.
> На заметку: в PGP никто не обязует делать подпись в обязательном порядке.
> Deniable encryption с ним не сделать, но оно и не всем надо.ИМХО достаточно существенный недостаток в целом. Ведь задача шифрования в том чтобы атакующий получил минимум информации. Ну и вообще PGP как-то так явно заточен на применения типа шифрования почты. Ну еще подписывание файлов.
> Кому надо -- другой инструмент. А кому-то это только вовред.
Тем не менее, я считаю что шифрование должно быть неотличимо от рандомных данных и не должно позволять постороннему наблюдателю что-то обнаружить или доказать. Cryptobox в этом плане довольно близок к идеалу.
> Он решает самые простые задачи в которых уже давно никто не делает ошибок.Кто этот "никто" и где он не делает ошибок? А то у вас то "CTR не могут реализовать", то "не делают ошибок". Вы уж определитесь? А то у вас истина вертится как флюгер на ветру.
> Он ничем не помогает значительно. PFS, replay -- вот и
> готов очередной SSHv2 или почти TLS.Только кода будет сильно меньше. Ну и багов в нем. А TLS вообще PFS как бы умеет, но как бы и не по дефолту. Вот это я понимаю: "форменное западло в пользу NSA" (им то конечно удобно: отжал ключи и порядок).
> спокойно можно жить без TLS.
Только при этом большинство фич отваливается и поэтому режимом никто сроду не пользуется. А так все хорошо, прекрасная маркиза.
> Нет, вы не знаете про протоколы и не знакомы с реальностью чтобы предполагать и удивляться почему так
> много "legacy", "crap" и отсутствие единственного убер-решения.Я в курсе про этот режим. И в курсе что на практике им никто не пользуется. Потому что без TLS и подъема PKI openvpn превращается в жалкий обрyбок, на уровне вашей приблуды наверное. Хочется более 1 конекта на экземпляр сервиса - уже подавай CA, сертификаты и прочее, со всеми вытекающими. При том всем этим почему-то еще и гордятся, считая фичой.
> Я уже говорил: если это VPN, то факт посылки пакета (пусть даже
> который не будет расшифрован) -- это уже утечка данных.Не обязательно. Пакеты можно иногда и фэйковые слать. Даже не обязательно чтобы получатель мог их расшифровать. Для пущих лулзов - пусть NSA пыхтит с их расшифровкой. "Ух ты, а что, так можно было?!" :). Тут конечно баланс между оверхедом и приваси. Но в моем понимании это для юзера должно настраиваться тривиально. Ну там буквально 1 параметр: "overhead vs privacy" (в гуе - прямо слайдер, например).
> сливается информация о наличии пакетов (но которая да -- не будет дешифрована).
Информация о наличии пакетов - не синоним траффика. Для начала будет не понятно служебные ли это пакеты или траффик (светить в plaintext части это разумеется не надо). А при повышенных требованиях можно и фэйковые пакеты кидать и буферизовать/сглаживать траффик.
> в мире TLS, IPsec и SSH в которых очень очень многие
> нововведения (с 80-х годов) не внедряются, зато бесятся по поводу симмтеричных
> шифров но не переживают по поводу ZK.Ну их все в 1 ряд ставить как-то не совсем правильно, пожалуй. В openssh люди поадекватнее. Но и у них грабли по историческим причинам накопились. И некоторые их решения компромиссны в местах где я бы такие компромиссы видеть не хотел. В частности - утечки о активности админа в сессии. И вместо того чтобы лечить вот это - они там какие-то качалки, блин, встраивают. Этот ваш Тео - он точно параноик? Куда он смотрит на этот крындец?
> Откройте хотя бы "Прикладную криптографию" Шнайера и убедитесь что есть куча алгоритмов
> которые криптографы могут предсказать, но ни один статистический тест нет.Предсказание nonce в случае DJB никому ничего особо ценного не дает.
> Вы совершенно не знаете теорию если думаете что тесты ловят качество PRNG.
Вы тормозите, если думаете что в случае nonce у DJB есть каие-то требования к качеству.
> Подчеркну: совершенно, раз умудрились такое сказать.
А что вам не нравится то? В случае nonce есть единственное требование - чтобы вывод не повторился за обозримое время. Это и проверить тестами не сильно сложно и будет быстро запалено криптографами для сколь-нибудь применяемых примитивов, даже какого-нибудь виндового криптоапи.
> паритесь о каких-то S-box-ах, но при этом доверяете /dev/urandom Linux-а, который
> куда проще отравить чем возится с атаками на кэш. Не верите?Да как сказать. Я припоминаю что в свежих версиях ядра Linux это дело чинили и если энтропии недостаточно, чтец может быть даже поставлен на паузу вплоть до момента когда энтропии наберется больше. Но да, вы правы в том что наглые чтецы могут понизить качество энтропии и это в целом некая проблема.
> из источников. Но Fortuna реально никак не смог побороть. Linux /urandom
> -- шутка из серии Dual EC.Скорее, проблема в чрезмерно оптимистичном допущении - что энтропию злонамеренно никто не истощает. Ну примерно как у вас с допущением что на тот же проц никто не пристроит процессы.
> в здравом уме и будет делать куда более простые вещи (как
> тоже отравление пула энтропии).Валидный пойнт. Но в озвученном мной варианте убер-сильный рандом надо в основном в "мастер" ключах (которые можно сгенерить в более-менее подконтрольном окружении). И активного чтеца из /dev/urandom проще заметить чем шпиона сбрасывающего кэш. Как посмотреть кто какие файловые операции делает - я еще понимаю. А как посмотреть кто процессору сбросил кэш и насколько нагло он это делает?
> Надейтесь, а я приму меры (для PGP это например entropy gathering daemon)
> чтобы не надеятся а знать что отравить энтропию будет крайне сложно.В целом валидный пойнт. И насколько я знаю, на виртуалках и некоторых вариантах эмбедовки с энтропией все не очень хорошо даже без наглых чтецов, потому что юзер никаких действий не производит и источников случайностей как таковых - минимум. Сколько там энтропии реально окажется доступно - очень отдельный вопрос. Поэтому, если даже наглых чтецов нет - с качкой энтропии борзеть и самому не надо. Если из urandom'а напрямую качать энтропию в каждый пакет - так пожалуй на высоком PPS сам себя без энтропии оставишь.
> Linux кстати был замечен что как-раз читает аппаратные DRBG с Intel-платформ
> прям напрямую, потом быстро поправили,Насколько я помню, Теодор Тсо зарубил подобные инициативы еще на подлете. Хоть он и не криптограф, но перспективность таких подходов понятна и ему. Он там еще едко шутил про флаги с названиями типа YES_I_TRUST_INTEL_AND_NSA.
Если вы в этом преуспели и вам не обломно - прогоните ваши эксперименты с угадыванием вывода /dev/urandom для свежих ядер типа 3.18? Ну или методику в студию - сам прогоню.
> но какие-нибудь Тео Де Раадты первые кто послал с этим народ. Linux вообще по мне (чисто по
> мне, моё IMHO) -- настолько унылая, некачественная помойка кода,Ну а у Тео, например, его НеПомойка получилась такой, что этим мало кто хочет пользоваться, хоть оно трижды качественное. Понятие о качестве штука интегральная. И если система половину моего железа не цепляет - какое там качество? Старый паровоз на запасных путях - в крушение конечно врядли попадет, да и поломок новых не будет самих по себе. Ну вот правда и транспортным средством его назвать сложно. И сравнивать надежность с магистральным электровозом как-то криво.
> в которой сделать что-то безопасно куда сложнее чем отревьювить TLS реализацию какую-нибудь.
Да вот я смотрю, OpenSSL который там год, а его все ревьюят и ревьюят. CVE все прут и прут. И думаю что и дальше это продолжится в том же духе. Но ок, я соглашусь с вами в том что в плане секурити линукс не предел мечтаний. Но и получше многих иных вариантов. А вон Тео в курсе IOMMU например? Или его DMA-based атаки не пугают? А то секурити - штука многогранная. Современная периферия - куча сервисных сопроцессоров, потенциально способных к DMA. Ну так, если уж паранойю прокачивать на совесть. Как там, Тео по этому поводу не икается в опенбзде?
> Поэтому Linux не использую -- не доверяю и считаю полнейшим crap-ом.
Это наименьшее зло которое может полноценно подхватить мои задачи. Проприетарные системы - не вариант вообще. Бзды - недоразвитые задохлики. Остальные вообще от горшка два вершка.
> Есть там хорошие разработчики, но Линус уж чего только не принимает в основное дерево.
Вообще - да, есть такое дело. Но фрибсдшникам про это возмущаться странно - они делают то же самое. В том числе передирая из линя.
> Мда… а у меня видимо маразм какой-то и я даже под своей
> FreeBSD всё-равно использую свой entropy gathering daemon?Хм, вообще это валидный пойнт. Но если уж мы про фрибзду - а у вас что там с IOMMU? И почему даже нубская убунта может сетевым сервисам затянуть всякие там флаги стэк-протекторов и рандомизации адресного пространства на многие годы раньше чем эти ваши фрибсдшники? У которых для начала даже практика подписывания обновлений (именно подписями, а не просто хэшами, которые атакующие могут поменять) - только начинает применяться. И вот эти люди говорят что в линксе - бардак? И уж конечно сдернуть целый ZFS у саней под кривой лицензией - не пихание в систему чего попало. А от себя - я еще и GPL violation нашел. В фрибзде. Приветы вашим копипастерам.
> В общем советую почитать "Прикладную криптографию" Шнайера. Хотя бы про mutual ZK
> authentication узнаете.Да я читал, но правда достаточно давно. И чего мне узнавать? Я и так в курсе.
> в вашей компетентности относительно того где и как будут применятся какие вектора атак.
Я бы предъявил себе излишний оптимизм с тем что не будет наглых чтецов из пула энтропии.
> Переживаете из-за S-box-ов, когда под носом у вас urandom
> который можно, реально можно, отравить.Валидный пойнт.
> В следующем релизе FreeBSD кстати будет применятся Fortuna --
Отлично. Только это лишь 1 из аспектов. И да, вы знаете, у этого вашего Персиваля в scrypt нашли невкусный недостаток: ваши крутые профи тоже не в курсе кэшей. Так что если scrypt использовать для проверки паролей - тайминг атаки опять же. По этому поводу появились всякие catena, sponge и еще некоторые. Которые стараются быть memory hard но при этом чтобы обращения к памяти не зависели от пароля.
> (дешёвые на тот момент DES-чипы аппаратные были реально офигенным решением для
> 3DES -- очень дёшево и очень безопасно (местами до сих пор)),Предпочту быстрые софтварные алгоритмы. Ну его нафиг - доверять каким-то чипам, которые проверить невозможно. Впихнут туда какой-нибудь флэш-памяти и сохранят все ваши ключи, например. А что помешает то?
Извиняюсь за несколько сообщений: opennet не дал просунуть такой большой комментарий :-)
> Извиняюсь за несколько сообщений: opennet не дал просунуть такой большой комментарий :-)Я тоже заметил эту проблему :)
Всякие PuTTY и FileZilla, и прочие SFTP-клиенты поддерживают только, в смысле максимум, "ssh-rsa (4096 bit) / diffie-hellman-group-exchange-sha256", по этому приходится на сервере ещё поддерживать и их вместе с "ssh-ed25519 / curve25519-sha256".
А статья вполне адекватная, не смотря на то, что уровень моей паранои, отвергает всё что ниже 256 bit.
> отвергает всё что ниже 256 bit.Крутой критерий. Используй XOR с 256-битной константой по кольцу.
> уровень моей паранои, отвергает всё что ниже 256 bit.256bit - это не паранойя, это уровень средней, домашней криптографии.
Причем, 256 даже АНБ рекомендует для браузеров.
Банкиры - не юзают (не должны), всё, что меньше 512 бит!
Посему, лёгкая паранойя начинается с 1024-бит.
Но в Штатах пресекаются любые попытки публикации криптографии с такими ключами.
256 бит чего?
Симметричного шифра? - больше пока вроде и не делали.
Для ECDSA хватает стандартных параметров в 512/521 бит.
> Симметричного шифра? - больше пока вроде и не делали.Ну в тот же arcfour можно втолкать до 256 байтов инициализатора. То-бишь, до 2048 битов ключа. Симметничного. Другое дело что 256 битов симметричного ключа - выше крыши, а реальная стойкость arcfour - совсем иной вопрос.