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