Опубликован релиз OpenSSH 9.5, открытой реализации клиента и сервера для работы по протоколам SSH 2.0 и SFTP...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=59877
ну все по классике - перешли на ed25519, когда NIST уже стандартизировал всякие дилитиумы.
Слишком безопасно время не пришло.
Сертификатов с ED25519 до сих пор нету в Firefox. Или NIST или RSA.
Какое отношение Firefox имеет к TLS?
NSS, реализующий этот функционал, является интегрированной частью Firefox и разрабатывается одной и той же командой? Достаточно?
А openssh тут при чём?
Был тезис о том, что все перешли на ED25519. Тезис ошибочный, не все.
Не одной и той же, кстати. В Мозилле есть группа разработчиков работающих чисто над NSS и хотя они, естсетвенно, взаимодействуют с остальными это продукт в продукте.
Когда в Мозилле решили сделать ESNI например вот тогда его поддержку и начали реализовывать в NSS, не раньше и не весь функционал NSS используется в ФФ, т.к. кое кто еще пользует NSS и похоже "заносит".
> когда NIST уже стандартизировал всякие дилитиумыЕще нет, хотя процесс идёт: "NIST hopes to publish the standardization documents by 2024" (https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography...)
Лучший ссш стал на одну цифру ближе к бесконечности.
Единственный нормальный ссш.
А как же libssh?
Это тоже самое
Нет. Есть ещё libssh2.
Вот когда будет libssh9.5 тогда и поговорим
При чём тут dropbear?
Ну чем оно лучше чем Telnet?
Тёплое всегда лучше мягкого.Пора бы уже знать.
Ещё в 2к10 телнет считался моветоном даже в самых упоротых железках, а сейчас то и подавно позорно его где-то юзать.
для простого тестирования plaintext протоколов типа HTTP или SMTP - да, норм. Для удаленного шелла - нет, даже с kerberos'ом
Тем что SSH это целый мир со своими scp, sftp и т.д.
А Telnet за уйму времени даже файлы не научился передавать через себя хотя протоколов достаточно было (взять хот бы xmodem).
> Ну чем оно лучше чем Telnet?хорошо написал
Ребята до сих пор делают релизы для БСД
Уважаемо!
Они в первую очередь для OpenBSD делают, а не для Linux.
Это им так только кажется.
23-го октября намечается релиз OpenBSD-7.4.. ждём-с..
Если завтра OpenSSH перестанет запускать на Linux, послезавтра у Тео кончатся деньги на его игрушечную ОС, а на третий день разработку OpenSSH к себе заберёт любой крупный разработчик ядра, да хоть тот же RH или MS, а про Тео все забудут.
Возможность автоматом апать все эти обновлённые ключи, выкашивая заменённые ими старые в authorized_keys при подключении к хосту так и не завезли штатно(
Зачем? У локалхостных васянов в ssh_config написано «StrictHostKeyChecking accept-new». У нелокалхостных эта проблема давно решена штатными средствами OpenSSH.
Centos 6 не умеет ed25519, a Rocky 9 не умеет rsa. Поэтому только ecdsa.
Кому нужны эти застывшие редхатовские поделия?
Тому, кто работает не в стартапах и не только со своим ноутбуком.
Есть старые системы, живущие значительно дольше 5 лет. Там не то, что 6, там и 5й Redhat может работать.
А рядышком, на каком-нибудь насосе или турбине — Windows Server 2000 или 2003. С MySQL 5.0.85. И нет, апгрейдить их нельзя под угрозой потери обслуживания этой турбины, заменить которую стоит больше, чем две новых школы.
Надо было ставить Arch Linux! Вот я поставил на свой домашний комп и у меня все работает и одноклассникам все рассказал на перемене. А у вас там софт не свежий.
Турбины... windows... турбины... можен ну их такие турбины?
Может и ну. Аргументируешь как-то свою точку зрения?
какой нахрен центос на турбиинах со стоимостью школы?а где SLA?
и 6 это уже мамонт, который производитель турбины заменить должен был сам
небось китайсев набрали на сдачу от стадиона
генеришь ключи которые нужно и в конфиге для нужного соединения прописываешь который использовать...
к немощной системе подключаешься по немощному ключу
Я уже так и делаю, естественно. Просто один дефолтный нерабочий ключ (rsa) поменяли на другой дефолтный нерабочий (ed25519).
> Я уже так и делаю, естественно. Просто один дефолтный нерабочий ключ (rsa)
> поменяли на другой дефолтный нерабочий (ed25519).чет ниче не понятно. на одну машину идешь по rsa ключу, на другую по ed25519. все воркает.
в authorized_keys такое многообразие из типов ключей встречается что вахъ.
> Ed25519Чому такие ключи по ssh так долго проверяются? Это для безопасности или там лютые вычисления?
RSA проверяется в разы медленнее. Попробуй завести RSA 4096 на каком-нибудь роутере и почувствуй разницу.
а лучше сгенерировать, я както попробовал, через сутки забил не дождавшись, на атоме какомто часа на 3 затянулось.
Проблемы с энтропией?
Так я не про роутеры. На достаточно жирный сервер с кучей ядер по RSA дефолтному заходит вообще без задержки, по эллиптическим кривым - тупит секунд 5-10.
Причина наверняка в чём-то другом. На 20-летнем пне даже такого не наблюдал.
Чувак, это у тебя резолвер на сервере дурит, отруби резолв в sshd_config
С ключами тупить нечему
> При этом цифровые подписи Ed25519 обладают более высоким уровнем безопасности, чем ECDSA и DSAПро RSA специально умолчали?
RSA 3072 оно на пару одинаково, а вот уже с 4096 "более" будет на стороне RSA
Энтропия ключа зависит от длины не линейно. 4096 ещё куда ни шло, а больше уже не особенно помогает.
Больший ключ чему не помогает? Что за энтропия ключа?
Там же число нужно факторизовывать на два сомножителя. Увеличиваем разрядность числа - сложность факторизации растет, по идее никакой там планки, после которой это останавливается - нет.
Слушай, сказано тебе что rsa плохо, значит плохо и точка.
Пожалуйста, подскажите, есть ли проекты, которые реализуют почти тоже самое, что находится внутри Nitrokey PRO 3, Rutoken ECP3 и т.п. но с более сильными шифрами, с максимально длинными ключами, которые вообще в принципе хотя бы совместимы с протоколом PKCS11?Нет необходимости защищать ключи одноплатника от физического доступа, когда они, например, находятся в его оперативке, потому что во включенном состоянии одноплатник бывает только при защищенном периметре помещения. А в выключенном состоянии более сильные ключи могут быть зашифрованы более слабыми ключами обычных популярных USB токенов типа Nitrokey.
Workstation обращается за криптооперацией для SSH по -> PKCS11 -> к одноплатнику с минимальной осью, например, Unikernel, а тот в свою очередь при первом или каждом обращении уже обращается например -> к FIDO2 токену, для вскрытия локального длинного ключа.
Есть что-то подобное готовое? Может быть для OpenBSD или лайтового Linux, в идеален наверно Unikernel?
Workstation, наверно, общался бы с таким одноплатником по USB или Ethernet в качестве физического канала, поверх которого бы работал PKCS11?
Наверно, что-то похожее на SoftHSM?
https://www.opendnssec.org/features/
https://github.com/opendnssec/SoftHSMv2
https://openports.pl/path/security/softhsm2
Есть что-то готовое open-source в виде Unikernel для популярных AMRv7 ?
Есть такое, называется HSM, без Soft. Ничего из того, что ты можешь скрафтить на коленке даже близко не сравнится по безопасности и производительности с вендорскими решениями. А если тебе пофиг на безопасность, то зачем тогда морочиться с одноплатником? Шифрованный USB будет ничем не хуже.
Я не настоящий сварщик, я только процитировал Роберта Хансена из проекта gnupg (слышал о таком?).A 2048-bit key is hypothesized to possess about 112 bits of entropy; a
3072-bit key, about 128; a 16k-bit, about 256. You very rapidly reach a
point of dramatically diminishing returns. A 32k key gives you
essentially nothing in terms of resistance to cryptanalysis, while
making it impossible for the rest of the OpenPGP ecosystem to work with
you because your public certificate is so unreasonably large.Энтропия ключа -- это размерность пространства, которое нужно перебрать, чтобы восстановить его, или его коллизию. Ну или как-то так.
Сложность факторизации - да, растет не линейно с ростом разрядности rsa, грубо: ключ увеличили в два раза, а сложность выросла только в полтора, там есть формула. Но это не значит, что этот закон начиная с какой-то разрядности ломается. Цитата про которую вы говорите видимо подразумевает, что если у них симметричное шифрование 256 бит aes, то нет смысла rsa для обмена этим ключем делать более сложным, чем брутфорс этого aes. Логично ведь, будут не факторизовать rsa, а брутфорсить aes - надежность равна надежности самого слабого звена. Это все про ограничение протокола/библиотеки, не самих крипоподходов. А я воспринял исходный посыл как наезд криптографию а не про ограничения либы.
4096 про которые вы пишите - будет 128 бит AES эквивалентно. Но это не значит что нет смысла повышать. Делаете 15000 и будет эквивалентно 256. И так далее. Простотлиба видимо 256 не поддерживает. На самом деле можно и 512 сделать, но это уже не настоящий AES будет требовать, а трехкратное применение 256 битного с тремя разными ключами, опять же это про матиматеку, то что там в либе и протоколе пока не предусмотрено - другой вопрос
Так это перебрать, и это аналитическая оценка.
А тут речь шла про то чтобы ключ ломать квантовым компом, где алгоритм предполагает наличие кубитов больше размерности ключа.
Не вижу, честно-говоря, где здесь про квантовый компьютер речь.
Да, они для элиптики и rsa представляют критическую угрозу, но еще не скоро плявятся в практическом смысле. Будем надеяться, что изобретут устойчивую постквантовую криптографию.
Году в 2003 на студенческой конференции кто-то мне задал вопрос мол, а как квантовые компьютеры? Ну и я ляпнул, спите спокойно, мол 25 лет точно ничего не будет в плане взломов. Так что еще лет 5 и буду спокоен, что не обманул человека))
Опять сектант DJB со своим любимым Ed25519.> Ed25519 обладают более высоким уровнем безопасности, чем ECDSA
Не обладают.
У ECDSA можно хоть 4к кривые взять и добавить в параметры, а 25519 - хардкод.
В стандартных параметрах есть кривые на 512 и 521 бит, что намного более стойко чем 25519.
Верно лишь отчасти. Кривая - это формула. К NIST есть вопросы именно в этой части. А размер ключа - это размер ключа. А вообще есть сайт safecurves и там всё уже разобрано давно. У ED же 448 есть ещё. Стандартизован, но почти нигде нет.
Кривая это параметры.
Формула там фиксированная.
К кривым NIST есть вопросы, но этих кривых вагон и маленькая тележка: нист, браинпул, оригинальные от банкиров (часть которых нист взял), французкая национальная, ГОСТ россеянский, и хз кто ещё их наделал.Но самое интересное что по тихоньку всё кроме p-256 от ниста начали выпиливать из софта и стандартов.
А на стандартах и софте сидят те же люди которые 25519 везде пропихивали.
У нас стояло secp521r1 на ECDH и много лет это работало, а в начале этого года хромой перестал это понимать. Теперь там обычное: "secp521r1:secp384r1:prime256v1".
Я все же останусь на своём определении, что является кривой.Кто и где "выпиливает" все NIST кроме p-255? Может просто наоборот, не реализовали? В SSH разве были 384 и 521?
Во всей литературе эти кривые называются либо кривыми либо параметрами.
Никакой формулы там не содержится, и все кривые считаются +- одинаково, с мизерными изменениями.Написал же: хромиум выкинул у себя, видимо кто то хочет сократит расходы на взлом и ломать всегда только p-256 :)
Ну, если о всех судить только по хрому, то картина выйдет действительно однобокая. Тогда других кривых действительно нет. А в GnuPG запилили кучу за последние 5 лет. OpenSSH, OpenVPN, Wireguard, dropbear - лишь немногие, кто добавил новые ECC алгоритмы за последние лет 5-7. И это, скорее всего, куда больше отражает общий тренд.
Общий тренд среди 1% пользователей инета?)
Речь то про то, что вся массовая крипта - её скатывают как раз к p-256 или 25519, и прибивают это на гвозди - и хром и ваергард как раз тому примеры.
> Общий тренд среди 1% пользователей инета?)
> Речь то про то, что вся массовая крипта - её скатывают как
> раз к p-256 или 25519, и прибивают это на гвозди -
> и хром и ваергард как раз тому примеры.Вы о чём? Сертификаты в RSA, очень редко в NIST. Хромой дефолтится до AES, даже если есть выбор между ED25519 и AES. FF тоже делает аналогично. У обоих даже багрепорты были, где предлагалось для мобильных платформ поднять приотитет ED25519, т.к. он быстрее AES при программной реализации шифрования.
Где тут формула?)}, {
/*.name =*/ "secp112r2",
/*.name_size =*/9,
/*.OID =*/ "1.3.132.0.7",
/*.OID_size =*/ 11,
/*.num_size =*/ 28,
/*.t =*/ 56,
/*.m =*/ 112,
/*.Fx =*/ {0},
/*.p =*/ "db7c2abf62e35e668076bead208b",
/*.SEED =*/ "002757a1114d696e6768756151755316c05e0bd4",
/*.SEED_size =*/40,
/*.a =*/ "6127c24c05f38a0aaaf65c0ef02c",
/*.b =*/ "51def1815db5ed74fcc34c85d709",
/*.Gx =*/ "4ba30ab5e892b4e1649dd0928643",
/*.Gy =*/ "adcd46f5882e3747def36e956e97",
/*.n =*/ "36df0aafd8b8d7597ca10520d04b",
/*.h =*/ 4,
/*.algo =*/ EC_CURVE_ALGO_ECDSA,
/*.flags =*/ 0,
}, {
/*.name =*/ "secp128r1",
/*.name_size =*/9,
/*.OID =*/ "1.3.132.0.28",
/*.OID_size =*/ 12,
/*.num_size =*/ 32,
/*.t =*/ 64,
/*.m =*/ 128,
/*.Fx =*/ {128, 97, 0},
/*.p =*/ "fffffffdffffffffffffffffffffffff",
/*.SEED =*/ "000e0d4d696e6768756151750cc03a4473d03679",
/*.SEED_size =*/40,
/*.a =*/ "fffffffdfffffffffffffffffffffffc",
/*.b =*/ "e87579c11079f43dd824993c2cee5ed3",
/*.Gx =*/ "161ff7528b899b2d0c28607ca52c5b86",
/*.Gy =*/ "cf5ac8395bafeb13c02da292dded7a83",
/*.n =*/ "fffffffe0000000075a30d1b9038a115",
/*.h =*/ 1,
/*.algo =*/ EC_CURVE_ALGO_ECDSA,
/*.flags =*/ EC_CURVE_FLAG_A_M3,
Мне интересно, ты действительно полагаешь, что в Edwards curve нет формулы, а только коэффициенты? А они откуда взялись?