HMAC после решения для шифрования в Java

Функция HMAC уже должна быть активирована. Поэтому обычно HMAC отображается как HMAC(K, M), где K — ключ, а M — сообщение. Таким образом, кандидат 2 не имеет смысла в этом отношении; это будет означать, что ключ K включается в расчет 3 раза (поскольку ключ используется два раза в самом HMAC).

По той же причине не имеет смысла использование куки с данными, которые невозможно угадать. Частью ввода HMAC является ключ K, который уже является неугадываемыми данными. Таким образом, вы не получите никакой безопасности и усложните свой протокол.

Теперь AES следует использовать в режиме CBC или CTR. Режим шифрования ECB небезопасен. Это означает, что вам требуется случайный IV (CBC) или уникальный IV (CTR). Этот IV должен быть частью HMAC, в противном случае злоумышленник все еще может изменить открытый текст, который вы получите после расшифровки.

Варианты 2 и 3 фактически одинаковы, если предположить, что статические данные действительно невозможно угадать (и одинаковая длина и т. д.). Если вы серьезно обеспокоены тем, что кто-то изменит файл cookie, тогда вариант 2 лучше, поскольку (при условии, что секретный ключ не используется совместно) он позволит вам определить, были ли внесены изменения в файл cookie, и не позволит кому-либо изменить файл cookie, а затем перезапустить хэш для подделки Mac. На практике, если ключ AES недоступен, а данные в файле cookie имеют какое-то семантическое значение, вы, вероятно, сможете обнаружить изменения в зашифрованном файле cookie, поскольку он будет расшифрован во что-то бессмысленное. Однако с точки зрения безопасности вариант 2 обеспечит наилучшие гарантии того, что данные не были изменены.

Все это говорит о том, что я делаю ряд предположений о вашей настройке, которые могут быть или не быть правдой.

Изменить Очевидно, я неправильно понял вопрос относительно ключевых данных и недостаточно четко изложил свои предположения. @owlstead's - лучший ответ.