Методов куча, все зависит от фантазии производителя ) Как пример я привел гироскоп, но это может быть и какая нибудь айдишка, передаваемая винту от матери. а если она не совпадает (винт воткнули в другой комп), то аривидерчи.
Ну не во всех же случаях, эта фича настраиваемая.
Иногда действительно надо чтобы всё стёрлось, когда свет вырубится(какой нить сервак с секретным софтом, который при желании развернуть пару минут при следующем включении).
А иногда надо чтобы всему пришел звиздец когда винт вытащили (тут уже в ход идут всякие полагаю датчики или еще что нибудь, вплоть до гироскопа)
>На основании сборки во время подписи вычисляется криптографический открытый ключ
Может что то поменялось с прошлой неделе, но каким местом криптографический ключ то да еще на основании сборки, да еще и во время подписи вычисляется? Может все таки _перед_ подписью генерится ключевая пара? А то, что вы называете «на основании» имеется в виду как хэш от сборки, подписанный закрытым ключом?
И до кучи еще б про Haujobb, MFX, Kewlers… Эти ребята в свое время перевернули моё мировоззрение с ног на голову ) А под технохаус демки MFX мы до сих пор иногда колбасимся )
Ага, например использовать ECDH для доставки «оффлайновых» сообщений, а MQV для варианта, когда собеседник на том конце сокета.
Кстати, там что то про атаки на него было, я не очень разобрал. Оно в первоначальной реализации было вроде как с дырой, и потом его аж 2 раза апдейтили. Первый раз до HMQV, а потом до FHMQV. Не зря «ECMQV has been dropped from the National Security Agency's Suite B set of cryptographic standards.»
Если и у меня и у собеседника УЖЕ есть открытые ключи друг друга о которых мы достоверно знаем, что они пренадлежат нам, то мы безо всяких эфемерных ключей с помощью ECDH можем посчитать общий секрет по всем известной формуле и использовать его сколь угодно долго. Не обязательно же каждый раз разный секрет юзать, для этого соль придумали.
Я вот к чему. Если рассмотреть немгновенную систему обмена информацией, в которой «адресом» является хэш от открытого ключа, вычисляемый «на лету», то мы не сможем с помощью MQV отправить сообщение адресату, открытый ключ которого у нас есть. Так как нам надо еще от него сессионный открытый ключ получить (и свой передать). А с обычным ECDH мы считаем в одну строчку общий секрет, шифруем им мессагу и отправляем будучи уверенными что оно расшифруется без проблем.
Для этой штуки надо каждый раз еще генерировать т.н. эфемерные дополнительные ключи, с помощью которых, произведя вычисления с основными ключами, и получается общий секрет. Как то не очень хорошо получается. В обычной ситуации мне достаточно знать открытый ключ собеседника, а тут еще и дополнительный обмен эфемерными ключами надо устраивать…
Иногда действительно надо чтобы всё стёрлось, когда свет вырубится(какой нить сервак с секретным софтом, который при желании развернуть пару минут при следующем включении).
А иногда надо чтобы всему пришел звиздец когда винт вытащили (тут уже в ход идут всякие полагаю датчики или еще что нибудь, вплоть до гироскопа)
Может что то поменялось с прошлой неделе, но каким местом криптографический ключ то да еще на основании сборки, да еще и во время подписи вычисляется? Может все таки _перед_ подписью генерится ключевая пара? А то, что вы называете «на основании» имеется в виду как хэш от сборки, подписанный закрытым ключом?
Для апача: www.opennet.ru/base/sec/ssl_cert.txt.html
Кстати, там что то про атаки на него было, я не очень разобрал. Оно в первоначальной реализации было вроде как с дырой, и потом его аж 2 раза апдейтили. Первый раз до HMQV, а потом до FHMQV. Не зря «ECMQV has been dropped from the National Security Agency's Suite B set of cryptographic standards.»
Я вот к чему. Если рассмотреть немгновенную систему обмена информацией, в которой «адресом» является хэш от открытого ключа, вычисляемый «на лету», то мы не сможем с помощью MQV отправить сообщение адресату, открытый ключ которого у нас есть. Так как нам надо еще от него сессионный открытый ключ получить (и свой передать). А с обычным ECDH мы считаем в одну строчку общий секрет, шифруем им мессагу и отправляем будучи уверенными что оно расшифруется без проблем.