Ну вот тут, хз. Я лично боюсь что исполнители накосячат или как-то не так применят неоднозначный механизм.
Перед этим голосованием я был в составе экспертной группы по голосованию в ДИТ и там было сделано всё хорошо (под это выделили и людские ресурсы и машинные и вообще удивительно, потому что на тестовом голосовании были проблемы). И после голосования также создалось впечатление что всё должно быть хорошо — и тут всплывает эта поделка, которая делалась другим ведомством в последний вечер :-D
Поэтому и не хочется видеть решения, которые допускают недетерминированное поведение. Это Россия, тут если исполнителю уже на этапе проектирования дали возможность налажать — он налажает
В 22:17 по МСК уже приложение было скомпилировано, в 22:38 был дописан файл ReadMe.txt. Доступных серверных мощностей под ДЭГ чуть более чем дохера. Там одних виртуалок было около 150 штук.
Проблема была в том, что эту поделку, оказывается делал даже не ДИТ Москвы, а совсем другое ведомство
В таком случае тем же перебором можно было бы всё восстановить :-)
Нет, тут на мой взгляд оптимальное решение — клиент-серверное.
Учитывая что «внутри» инфраструктуру обеспечивает РосТелеком, а «снаружи» можно прикрутить резервный метод с ограниченным RPS.
Это как раз к вопросу почему при таких задачах нужны люди с опытом по криптографии/ИБ
Правильно решить эту задачу может человек, который знаком не только с тем как работает хэш-функция, но и с методами атак на них.
Вы же постепенно шаг за шагом задумываетесь о тех вещах, которые разработчик с соответствующим опытом уже знает :-)
Так, там есть и защита на сетевом уровне DDoS, а RPS с одного IP нужно ограничить. Учитывая что паспортов всего миллион — хеши можно держать в памяти в словаре. Сможете сами оценить сколько запросов в секунду выдержит такая архитектура? Более того она еще и горизонтально масштабируемая :-)
Вы похоже не понимаете, что как происходит разработка ПО. Программисту всегда ставится бизнес-задача. Я напомню вам, что у нас на всех участках не то что есть Интернет, там даже обеспечено видео-наблюдение на инфраструктуре РосТелекома. Поэтому существующая инфраструктура УЖЕ работает с интернетом. Поэтому проблем не будет.
Но даже если предположить что вы правы и Интернет пропал везде, включая сотовые телефоны(!), то давайте подсчитаем по времени хеширования. Если просто добавить миллион итераций sha256, то проблему бы не заметили:
10 миллиардов комбинаций можно прогонять 4 часа (1 кратное выполнение хеша), а можно 400 лет. К тому времени данные бы потеряли актуальность. Цена реализации — дополнительный цикл for.
Hashcat — это вообще удар ниже пояса, особенно если у вас под рукой настольный компьютер с NVidia. К сожалению я был на даче и под рукой у меня был только ноутбук с встроенной графикой на которой OpenCL для hashcat работает не стабильно.
Т.е. завести поддомен на сайте госсулуги и разместить там общедоступный произвольный файл для скачивания можно, а развернуть там код, который загрузит в память csv-файл и будет отвечать true,false,null в зависимости от нахождения хэша и значения булевой переменной ну никак нельзя?
Вы знаете сколько времени потребуется C# разработчику чтобы написать такой серверный-бэкенд?
Там будет:
1. контроллер
2. фасад в котором будет один Dictionary<string,bool>, не нашел -> null, нашел -> вернул значение
3. Код загрузки csv
Это любой ASP.NET разработчик вам на собеседовании на листочке бумаги должен написать за гораздо меньшее время чем за 3 часа.
Что касается бюрократии — в государственных структурах когда «жопа горит» любые бюрократические проволочки решаются очень быстро. Просто в известность ставится вышестоящее начальство, которое решает проблемы бюрократии одним звонком.
Пока разработчик пишет код, манагер должен звонить. Если они оба компетентны — никто даже не узнает про то какой был пц. Так работают госструктуры.
Разработчика тут никто и не винит. Речь как раз была в том, что виновато руководство, которое не привлекло ни архитектора ни безопасника. Если хотя бы один был привлечен — задача была бы решена без такого позора.
Посмотрите внимательно у вас всё равно количество входных данных осталось то же — 10^10. Просто усложнилась хеш-функция, которая стала составной. В этом как раз суть проблемы — соль неприменима в этом режиме использования.
Так это и есть нестандартное применение хеша. Но этого недостаточно. Нужно чтобы хеширование шло в миллион раз медленней, чем просто вычисление одного sha256 хеша
Так в статье же написано:
Https checkvoter.gosuslugi.ru degvoter.zip
Соответственно добавляете / и это становится реальным адресом. Затем идёте на сайт web.archive.org и через него получаете этот архив
А как вы в таком случае по базе будете искать?
Это если вам нужно хешировать пароли, то, действительно, правильное решение это хеширование конкатенации соль+пароль. Но в данном случае нам нужно искать по полученному набору, поэтому разная соль для каждого паспорта не подходит. В данном случае нужно нестандартное применение алгоритма хеширования (не имеющее в данный момент таблиц подбора) + математическое замедление вычисления хеша.
Перед этим голосованием я был в составе экспертной группы по голосованию в ДИТ и там было сделано всё хорошо (под это выделили и людские ресурсы и машинные и вообще удивительно, потому что на тестовом голосовании были проблемы). И после голосования также создалось впечатление что всё должно быть хорошо — и тут всплывает эта поделка, которая делалась другим ведомством в последний вечер :-D
Поэтому и не хочется видеть решения, которые допускают недетерминированное поведение. Это Россия, тут если исполнителю уже на этапе проектирования дали возможность налажать — он налажает
Проблема была в том, что эту поделку, оказывается делал даже не ДИТ Москвы, а совсем другое ведомство
Нет, тут на мой взгляд оптимальное решение — клиент-серверное.
Учитывая что «внутри» инфраструктуру обеспечивает РосТелеком, а «снаружи» можно прикрутить резервный метод с ограниченным RPS.
Правильно решить эту задачу может человек, который знаком не только с тем как работает хэш-функция, но и с методами атак на них.
Вы же постепенно шаг за шагом задумываетесь о тех вещах, которые разработчик с соответствующим опытом уже знает :-)
Но даже если предположить что вы правы и Интернет пропал везде, включая сотовые телефоны(!), то давайте подсчитаем по времени хеширования. Если просто добавить миллион итераций sha256, то проблему бы не заметили:
10 миллиардов комбинаций можно прогонять 4 часа (1 кратное выполнение хеша), а можно 400 лет. К тому времени данные бы потеряли актуальность. Цена реализации — дополнительный цикл for.
Вы знаете сколько времени потребуется C# разработчику чтобы написать такой серверный-бэкенд?
Там будет:
1. контроллер
2. фасад в котором будет один Dictionary<string,bool>, не нашел -> null, нашел -> вернул значение
3. Код загрузки csv
Это любой ASP.NET разработчик вам на собеседовании на листочке бумаги должен написать за гораздо меньшее время чем за 3 часа.
Что касается бюрократии — в государственных структурах когда «жопа горит» любые бюрократические проволочки решаются очень быстро. Просто в известность ставится вышестоящее начальство, которое решает проблемы бюрократии одним звонком.
Пока разработчик пишет код, манагер должен звонить. Если они оба компетентны — никто даже не узнает про то какой был пц. Так работают госструктуры.
Https checkvoter.gosuslugi.ru degvoter.zip
Соответственно добавляете / и это становится реальным адресом. Затем идёте на сайт web.archive.org и через него получаете этот архив
Это если вам нужно хешировать пароли, то, действительно, правильное решение это хеширование конкатенации соль+пароль. Но в данном случае нам нужно искать по полученному набору, поэтому разная соль для каждого паспорта не подходит. В данном случае нужно нестандартное применение алгоритма хеширования (не имеющее в данный момент таблиц подбора) + математическое замедление вычисления хеша.