Автор: sanyo 
Вы серьезно терпите внезапные нежелательные отключения своего компа во время работы? Это же мазохизм самый настоящий. Даже самый дешевый PowerCom_650 20 летней давности умел включаться самостоятельно, если не ошибаюсь. Любой серверный тем более, в них это настраивается (программируется) специальной утилитой заранее.
Речь не про рабочий компьютер (на работе ноутбук, батерея спасает от выкрутасов энергосбытовой компании).
однако у меня постоянно включен домашний "почти сервер", по VPN авто-подключается к рабочей сети, туда синхронизируются исходники. Смысл в том, что на облачном диске как обычно накапливается большое количество мелких и нестабильных версий исходников, версионный контроль git мне вообще не нужен. Перед открытием файлов синхронизирую вручную. Когда выключен компьютер куда синхронизирую, приходится пользоваться старомодной флешкой. Когда выключен компьютер с последней версией приходится или отложить эту работу или идти включать. Я не спорю, что модели 20-летней давности это умели. Или скорее не умели наоборот. Сейчас же дофига умные бесперебойники еще и проверяют есть ли на них нагрузка и если нагрузка не определилась, так и не включаются, в лучшем случае включаю батарею на подзарядку. По факту в половине случаев они не включаются. Знаете терминалы электронной приемной Президента? Так вот, с ними такая же ерунда. Думаю, если бы была возможность настроить, ее бы использовали вместо того, чтоб после отключения звонить нам и просить вскрыть печати на терминале и нажать заветную "ВКЛ".
Подключать бесперебойник к компьютеру по USB (для настройки утилитами или для мониторинга напряжения) обоюдоострая схема: в таком случае при отключении электричества ОС также получает информацию от бесперебойника и пытается выключиться. Если отключение на 10 секунд, то при включении электричества компьютер еще выключается, сигнал включения от бесперебойника ОС при выключении отклоняет, продолжает выключаться и... остается в выключенном состоянии до следующего выключения электричества. Если отключение длиннее, то компьютер успел выключиться, но пусть в биосе в параметре автовключения стоит "использовать последнее состояние" (настоящая "чума", а не параметр). Так как ОС выключилась "добровольно", то последнее состояние с точки зрения биоса будет "ВЫКЛ" и автостарта компьютера при включении энергии не происходит.
Автор: sanyo На Авито такие UPS (без батарей или с полудохлыми) можно взять почти даром.
Проблема даже не в батареях, а в том что у б/у очень часто убитые управляющие микросхемы. На работе у нас есть довольно много старых бесперебойников, но свежие батареи их не спасают. Конденсаторы и керамика со временем выходит из строя, найти трещину на элементе размером 0,3 мм без микроскопа нереально. А уж с Авито... непонятно, допустим, на скачок какой продолжительности и амплитуды они фактически среагируют. Как-то не хочется рисковать компьютерным железом, подключая бесперебойники с Авито.
Автор: sanyo Можно найти UPS с возможностью подключения внешних батарей, чем расширить период работы без электросети до часа и более.
Про это и спору нет. Тут уж как обычно в малых городах - магазины привозят всякий хлам, что-то приличное надо выписывать издалека.
Автор: sanyo Автор: two_oceans за 10 лет на обычные компьютеры приходят все более отстойные варианты линеек процессоров. Есть определенная необходимая вычислительная мощность для решения повседневных задач и нет потребности ее нарастить.
Где же тогда злоумышленнникам взять железо для ботнетов по подбору хешей ? :)
Здравый вопрос. Ну а если серьезно, активных процессоров по последним подсчетам может быть даже больше чем населения, особенно если учесть смартфоны, в которых часто процессоры мощнее чем настольных компьютерах. Если загрузка процессора изменится с 1% до 30% многие даже этого не поймут, так что резерв для ботнета есть.
Автор: sanyo А сколько нужно для подбора современного хэша максимальной длины, да еще созданного с большим количеством итераций, скажем не за микросекунду, а за несколько секунд (т.е. не за 100 итераций, а например миллиардом или миллионом итераций)?
Цитата:Исследователи говорят, что алгоритм ... защищён от взлома с помощью квантовых компьютеров, поскольку для перебора вариантов потребуются миллиарды лет. ...
Вы меня конечно извините, но количество итераций это проблема только для подбора конкретного значения хэша. При тотальном подборе вариантов важна только длина (количество возможных значений) хэша. Суть в чем: любая хэш функция это функция "сжатия", длина входных данных обычно не ограничена алгоритмом, то есть безопасно считать, что входных значений бесконечное количество. Длина же конкретного значения хэша фиксирована и количество вариантов конечно. Это означает, что если вы подаете входной поток байт (не ограничиваясь текстовыми символами) длинее чем длина хэша, то практически наверняка существует поток данных меньшей длины с тем же хэшем (коллизия). Просто из-за количества. Идем дальше. Есть теоремы дискретной математики, что любую логическую функцию (представленную, допустим, в табличной форме), можно представить в совершенной конъюктивной форме, в совершенной дизъюнктивной форме, в виде полинома Жегалкина и т.д. Если я правильно понимаю, это означает, что если хэш функция содержит только логические функции и сдвиги на фиксированное количество бит (а сдвиг на фиксированный шаг это по сути перенумерация аргументов), не используются наборы разных констант, не используется дополнительный ключ, то возможно подобрать каждому биту результирующего хэша соответствующую форму (для определенной длины текста, для определенного количества итераций). Как Вы понимаете 256 операций xor будут вычисляться гораздо быстрее чем неизвестное количество итераций. Сложность только в том, что нужно сначала нужно эту форму подобрать. Если задавать только табличную форму, то это равносильно вычислению всех хэшей от данных некой длины. Этот тот самый случай "черного ящика" и выигрыша относительно полного перебора практически нет. Если же известен алгоритм, то тут уже возможны варианты подбора формы аналитическими способами.
По крайней мере, пусть есть данные некой длины 1, мы знаем, что взяв длину 2 данных длиннее длины 1 (и длиннее длины хэша) мы в теории практически наверняка найдем такой же хэш от данных длины 1, от каких-то данных этой длины 2 (скорее всего вариант будет не один). Если мы построим форму для длины 2 и проведем или подбор или реверсивный анализ.
Автор: sanyo Кстати есть ли у вас хороший обзор по практической стойкости хешей к подбору коллизий? С примерами попыток взлома, как противодейстовать и т.п.?
У меня под рукой нет, универсального обзора наверно тоже нет, но вообще обзоры стойкости конкретного алгоритма и сравнения с несколькими еще есть, у некоторых алгоритмов коллизии начинаются уже при данных длиной половину длины хэша.
По поводу гост (какого точно не помню, полагаю гост-94) слышал, что по данным зарубежных исследователей можно сломать 1/4 длины, то есть снизить 256 бит до 192 бит, что существенно упрощает последующий полный перебор и это было одной из причин непризнания гост. Понятно, что 192 бита тоже перебирать можно долго, но все же алгоритм заменили. Про стойкость гост-2012 не слышал, но так как даже для 256 битного сначала вычисляется 512 бит, потом берется половина, он должен быть выглядеть неплохо.
Автор: sanyo Вроде бы на стойкость влияет количество итераций при генерации хэша, что там с итерациями в ГОСТ-овых хэшах, которые мы получаем от CLI КриптоПро?
Полагаю, они строго по ГОСТ, количество итераций указано в стандарте. Собственно, даже схема шифрования ключей в контейнере имеет стандарт. Даже момент, что без пароля хэш вычисляется 2 раза, с паролем 2000 раз прописан.
Автор: sanyo Автор: two_oceans С процессорами определились, но многие задачи по подбору хэша удобнее решать на видеокартах. Тут тоже не все так гладко: майнеры заливают в них специальную прошивку, которая нарушает их работу для вывода видео, но оптимизирует расчет хэшей. Другими словами, "как есть" видео карты не оптимизованы на расчет хэшей.
Все таки наверно не каждый хэш алгоритм можно ломать (подбирать) на видеокартах?
Если строго следовать алгоритму, то конечно не каждый. В плане инструкций процессора думаю нет особо проблемы (особенно если учесть возможность представления в формах как описано выше), разница есть в том распараллеивается алгоритм (есть ли в нем независимые части, например, 30 раундов колдуем над одной ячейкой) или нет (каждый раунд требует результатов 30 соседних ячеек, что требует согласования нескольких конвейеров и ведет к простою). Если нет, то можно выполнять проверку одного варианта данных на 1 конвейере, дополнительные конвейеры можно загрузить проверкой соседнего варианта данных. Ну то есть условно на 5 конвейерах вместо 1 варианта за 1 секунду, получим 5 вариантов за 5 секунд. Впрочем, оптимизация всего этого на GPU совершенно отдельная тема, с которой я не настолько близко знаком, чтобы обсуждать. На Хабре еще попадалась статья про программируемые логические матрицы, там очень много факторов будут они быстрее или наоборот намного медленнее чем GPU или CPU.
