Pull to refresh
20
-1
Сергей Панасенко @SergeyPanasenko

Исследователь в области криптографии и ИБ

Send message

Вы правы, но всё это не отменяет того факта, что очень часто блокчейн сравнивается с БД.
Я на эту тему привел цитату в статье.
А вот здесь: https://habr.com/ru/companies/aktiv-company/articles/760730/ обсуждались схемы выбора технологии хранения данных, где в подавляющем большинстве случаев выбор делался между этими же технологиями.
Получается, что все привыкли думать, что блокчейн - это альтернатива СУБД, просто другая по структуре, набору возможностей и свойствам.

Развернутый ответ обычно интереснее и информативнее.

А если наоборот? У вас классическая СУБД с записью данных, подтверждаемых (прямо или косвенно) третьей доверенной стороной. Доверенная сторона по какой-либо причине перестает существовать. Мне кажется, будет еще хуже :-)

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

"Forward security" используют не реже, чем "Forward secrecy". Не возьмусь судить, какой из терминов вернее, но используются они взаимозаменяемо и одинаково часто.

Насчет "Упреждающей секретности" - согласен, звучит хорошо и внятно.

Тоже хороший вариант, но опять же встает проблема управления ключами (в предыдущих комментариях обсуждалась).

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

Я согласен, что это не просто. Распределение симметричных ключей - это всегда отдельная проблема.

А как насчет альтернативного варианта - корпоративная PKI?

Я бы добавил еще тщательную проверку самого обновления перед его применением.

Вот два реальных примера:

  • для загрузки технологических параметров в оборудование, работающее в изолированных сегментах (например, металлургия, подпадает под приказы № 31 и 239);

  • для загрузки обновлений ПО в изолированные сегменты (там же).

Правда, придется как-то контролировать, что флешка не исчезла, а в изолированном контуре, например:

  • с помощью RFID-меток;

  • с помощью АРМ на входе в изолированный контур, где оператор будет ставить галочку, что флешка здесь, и снимать ее при завершении работы в контуре.

Ну тогда я бы предложил preshared-ключи + симметричное шифрование. Ключи генерить и заливать на АРМ Администратора при регистрации флешек перед раздачей пользователям. Этого будет достаточно для предотвращения MITM.

Да, подмена флешки - самая проблемная часть идеи.

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

Иначе действительно без досмотра не обойтись, а хотелось бы избежать.

Краткий опрос коллег показал, что мы пока таких не знаем. Если кто-то знает — поделитесь, пожалуйста, ссылочкой.
Очень похоже, что именно так.
Всего 12 раундов плюс дополнительное наложение ключа.
Увы, подробности разработки ГОСТ Р 34.11-2012 мне неизвестны. Вполне возможно, что и случайна — AES-подобные преобразования есть во множестве хэш-функций.
Думаю, что серьезные исследования проводились. Затронули ли они rebound-атаку — сложно сказать.
Да и расширение атаки до 9,5 раунда было уже после выхода стандарта.
Меня вот больше беспокоят мультиколлизии — это похоже на структурную проблему.

Information

Rating
Does not participate
Location
Зеленоград, Москва и Московская обл., Россия
Works in
Registered
Activity