вот, допустим, я хочу передать клиенту (которому я не доверяю) некоторый кусочек данных, с которым он ко мне потом вернется. И допустим, пока клиент там чем-то занят, я не хочу хранить эти данные у себя. Но когда он вернется, я хочу быть уверенным, что это именно те данные, которые я ему вручил.
Понятно, что я могу сгенерировать себе приватный/публичный ключ, и использовать стандартную схему цифровой подписи. Это надежно, проверенно, но очень вычислительно затратно.
В качестве альтернативы, я могу сгенерировать себе большое случайное число, держать его в секрете, и использовать для подписи HMAC (или CMAC) с этим числом в качестве ключа. Ну и обеспечить, естественно, периодическую ротацию этого ключа и всякое такое. Выглядит это ничуть не менее секурно, но вычислительные затраты снижаются очень существенно.
Наверняка такую схему не я первый придумал. Внимание, вопрос, каково ее стандартное название (лучше на английском)?
Здравствуйте, Pzz, Вы писали:
Pzz> Наверняка такую схему не я первый придумал. Внимание, вопрос, каково ее стандартное название (лучше на английском)?
Дык MAC же.
Здравствуйте, ·, Вы писали:
Pzz>> Наверняка такую схему не я первый придумал. Внимание, вопрос, каково ее стандартное название (лучше на английском)? ·>Дык MAC же.
MAC — это в конце. А я имею ввиду всю схему в целом.
Здравствуйте, Pzz, Вы писали:
Pzz> Pzz>> Наверняка такую схему не я первый придумал. Внимание, вопрос, каково ее стандартное название (лучше на английском)? Pzz> ·>Дык MAC же. Pzz> MAC — это в конце. А я имею ввиду всю схему в целом.
Message Authentication? Или я вопрос не понимаю.
Здравствуйте, ·, Вы писали:
Pzz>> MAC — это в конце. А я имею ввиду всю схему в целом. ·>Message Authentication? Или я вопрос не понимаю.
Вопрос не понимаешь.
Это не просто message authentication, это использование message authentication некоторым определенным образом для определенных целей. Наверняка есть какие-то нюансы, о которых я не знаю. Криптография, это такая наука, в которой не все равно, с какой ноздри начинать сопли высмаркивать, с левой или с правой.
Об них хотелось бы почитать, но я никак не могу сообразить, как такое называется.
Здравствуйте, Pzz, Вы писали:
Pzz>вот, допустим, я хочу передать клиенту (которому я не доверяю) некоторый кусочек данных, с которым он ко мне потом вернется. И допустим, пока клиент там чем-то занят, я не хочу хранить эти данные у себя. Но когда он вернется, я хочу быть уверенным, что это именно те данные, которые я ему вручил.
Pzz>Понятно, что я могу сгенерировать себе приватный/публичный ключ, и использовать стандартную схему цифровой подписи. Это надежно, проверенно, но очень вычислительно затратно.
Pzz>В качестве альтернативы, я могу сгенерировать себе большое случайное число, держать его в секрете, и использовать для подписи HMAC (или CMAC) с этим числом в качестве ключа. Ну и обеспечить, естественно, периодическую ротацию этого ключа и всякое такое. Выглядит это ничуть не менее секурно, но вычислительные затраты снижаются очень существенно.
А важно ли тебе доказать, что это тот же клиент? Может, это другой, получивший это число?
Pzz>Наверняка такую схему не я первый придумал. Внимание, вопрос, каково ее стандартное название (лучше на английском)?
Знаешь, что это мне напоминает? TCP SYN cookies. Почитай про них, может, где базу метода опишут.
Здравствуйте, netch80, Вы писали:
Pzz>>В качестве альтернативы, я могу сгенерировать себе большое случайное число, держать его в секрете, и использовать для подписи HMAC (или CMAC) с этим числом в качестве ключа. Ну и обеспечить, естественно, периодическую ротацию этого ключа и всякое такое. Выглядит это ничуть не менее секурно, но вычислительные затраты снижаются очень существенно.
N>А важно ли тебе доказать, что это тот же клиент? Может, это другой, получивший это число?
Нет, не важно.
Pzz>>Наверняка такую схему не я первый придумал. Внимание, вопрос, каково ее стандартное название (лучше на английском)?
N>Знаешь, что это мне напоминает? TCP SYN cookies. Почитай про них, может, где базу метода опишут.
