Вы правы, но всё это не отменяет того факта, что очень часто блокчейн сравнивается с БД. Я на эту тему привел цитату в статье. А вот здесь: https://habr.com/ru/companies/aktiv-company/articles/760730/ обсуждались схемы выбора технологии хранения данных, где в подавляющем большинстве случаев выбор делался между этими же технологиями. Получается, что все привыкли думать, что блокчейн - это альтернатива СУБД, просто другая по структуре, набору возможностей и свойствам.
А если наоборот? У вас классическая СУБД с записью данных, подтверждаемых (прямо или косвенно) третьей доверенной стороной. Доверенная сторона по какой-либо причине перестает существовать. Мне кажется, будет еще хуже :-)
Думаю, что в таком случае блокчейн всё равно можно будет использовать, но вряд ли он останется оптимальным решением. Подобная смена условий вряд ли будет полезна любой системе, а не только блокчейну.
"Forward security" используют не реже, чем "Forward secrecy". Не возьмусь судить, какой из терминов вернее, но используются они взаимозаменяемо и одинаково часто.
Насчет "Упреждающей секретности" - согласен, звучит хорошо и внятно.
Тоже хороший вариант, но опять же встает проблема управления ключами (в предыдущих комментариях обсуждалась).
Да и я хотел обратить внимание, что здесь не только флешки (и другие носители) можно так контролировать, а вообще любые перемещаемые внутри периметра предметы, которые могут представлять какую-либо ценность.
для загрузки технологических параметров в оборудование, работающее в изолированных сегментах (например, металлургия, подпадает под приказы № 31 и 239);
для загрузки обновлений ПО в изолированные сегменты (там же).
Правда, придется как-то контролировать, что флешка не исчезла, а в изолированном контуре, например:
с помощью RFID-меток;
с помощью АРМ на входе в изолированный контур, где оператор будет ставить галочку, что флешка здесь, и снимать ее при завершении работы в контуре.
Ну тогда я бы предложил preshared-ключи + симметричное шифрование. Ключи генерить и заливать на АРМ Администратора при регистрации флешек перед раздачей пользователям. Этого будет достаточно для предотвращения MITM.
Поэтому и предлагаю в более функциональной системе использовать специальные носители со взаимной аутентификацией с компьютером. И не подделаешь, и скопировать содержимое "на ходу" не получится.
Иначе действительно без досмотра не обойтись, а хотелось бы избежать.
Увы, подробности разработки ГОСТ Р 34.11-2012 мне неизвестны. Вполне возможно, что и случайна — AES-подобные преобразования есть во множестве хэш-функций.
Думаю, что серьезные исследования проводились. Затронули ли они rebound-атаку — сложно сказать.
Да и расширение атаки до 9,5 раунда было уже после выхода стандарта.
Меня вот больше беспокоят мультиколлизии — это похоже на структурную проблему.
Вы правы, но всё это не отменяет того факта, что очень часто блокчейн сравнивается с БД.
Я на эту тему привел цитату в статье.
А вот здесь: https://habr.com/ru/companies/aktiv-company/articles/760730/ обсуждались схемы выбора технологии хранения данных, где в подавляющем большинстве случаев выбор делался между этими же технологиями.
Получается, что все привыкли думать, что блокчейн - это альтернатива СУБД, просто другая по структуре, набору возможностей и свойствам.
Развернутый ответ обычно интереснее и информативнее.
А если наоборот? У вас классическая СУБД с записью данных, подтверждаемых (прямо или косвенно) третьей доверенной стороной. Доверенная сторона по какой-либо причине перестает существовать. Мне кажется, будет еще хуже :-)
Думаю, что в таком случае блокчейн всё равно можно будет использовать, но вряд ли он останется оптимальным решением. Подобная смена условий вряд ли будет полезна любой системе, а не только блокчейну.
"Forward security" используют не реже, чем "Forward secrecy". Не возьмусь судить, какой из терминов вернее, но используются они взаимозаменяемо и одинаково часто.
Насчет "Упреждающей секретности" - согласен, звучит хорошо и внятно.
Тоже хороший вариант, но опять же встает проблема управления ключами (в предыдущих комментариях обсуждалась).
Да и я хотел обратить внимание, что здесь не только флешки (и другие носители) можно так контролировать, а вообще любые перемещаемые внутри периметра предметы, которые могут представлять какую-либо ценность.
Я согласен, что это не просто. Распределение симметричных ключей - это всегда отдельная проблема.
А как насчет альтернативного варианта - корпоративная PKI?
А как переносить данные между изолированными контурами?
Да, это снова получается специальный носитель.
Я бы добавил еще тщательную проверку самого обновления перед его применением.
Вот два реальных примера:
для загрузки технологических параметров в оборудование, работающее в изолированных сегментах (например, металлургия, подпадает под приказы № 31 и 239);
для загрузки обновлений ПО в изолированные сегменты (там же).
Правда, придется как-то контролировать, что флешка не исчезла, а в изолированном контуре, например:
с помощью RFID-меток;
с помощью АРМ на входе в изолированный контур, где оператор будет ставить галочку, что флешка здесь, и снимать ее при завершении работы в контуре.
Ну тогда я бы предложил preshared-ключи + симметричное шифрование. Ключи генерить и заливать на АРМ Администратора при регистрации флешек перед раздачей пользователям. Этого будет достаточно для предотвращения MITM.
Да, подмена флешки - самая проблемная часть идеи.
Поэтому и предлагаю в более функциональной системе использовать специальные носители со взаимной аутентификацией с компьютером. И не подделаешь, и скопировать содержимое "на ходу" не получится.
Иначе действительно без досмотра не обойтись, а хотелось бы избежать.
Да и расширение атаки до 9,5 раунда было уже после выхода стандарта.
Меня вот больше беспокоят мультиколлизии — это похоже на структурную проблему.