Создание HMAC для шифрования PHP

Короткий ответ: Да

Длительный ответ:

HMAC - это код аутентификации сообщения на основе Hash. Вы должны HMAC что-либо, что вы хотите аутентифицировать, или, другими словами, все, что вы хотите защитить от модификации.

Хотя стандарт RFC является более сложным, может иметь смысл думать о HMAC как о соленом хеше.

например hmac (message, key) = hash (сообщение + клавиша)

1. Вы можете только воссоздать тот же HMAC с одинаковым сообщением и ключом.
2. Вы не можете воссоздать один и тот же hmac, если ключ идентичен, но сообщение отличается.
3. Вы не можете воссоздать один и тот же hmac, если сообщение идентично, но ключ отличается.

Злоумышленник (у которого нет ключа HMAC) не может изменять часть сообщения HMAC без аннулирования существующего HMAC. Это действительно зависит от вашего формата данных и использования этих данных, чтобы определить, что должно быть включено в сообщение HMAC и ключ HMAC. Но, предполагая, что вы используете HMAC для аутентификации дешифрования, вы всегда должны включать в сообщение HMAC все, от чего зависит расшифровка. Симметричный ключ обычно используется как ключ HMAC.

В вашей цитате, плакат говорит IV, и алгоритм также должен быть хэширован. Рассмотрим формат файла/базы данных, состоящий из

ALGORITHM + IV + CIPHERTEXT + HMAC

Если вы только HMAC зашифрованный текст, злоумышленник сможет модифицировать алгоритм или IV (развращать файл), не влияя на действительность HMAC. Это плохо, потому что вы можете получить поврежденный зашифрованный файл с допустимым HMAC. Расшифровка будет продолжаться как обычно, потому что ваше программное обеспечение будет думать, что все в порядке. Результатом является полностью искаженное дешифрование, но дело в том, что ваше программное обеспечение нарушено, потому что оно вернуло неправильный вывод при расшифровке и не выдавало никаких ошибок. Это можно классифицировать как "риск безопасности", если ваше приложение пытается что-то сделать с этими ошибочными данными, поскольку оно предполагает, что оно правильно. Это не риск для безопасности в том смысле, что он делает базовое шифрование слабее или легче взломать. HMAC и симметричное шифрование - это две совершенно разные технологии, которые делают разные вещи. Точка использования HMAC заключается в том, что вы можете предположить, что уровень дешифрования возвращает данные, которые на 100% правильны.

В приведенном выше примере ALGORITHM представляет собой динамическую часть данных, которую я использовал для объяснения "гибкости алгоритма" в цитате OP. Он определяет, какой алгоритм шифрования использовался. Дело в том, что оно динамическое, поэтому его нужно читать откуда-то, а не жестко. Этот факт делает его зависимым от расшифровки, поэтому он должен быть включен в сообщение HMAC. Однако, если вы всегда используете какой-либо статический алгоритм, тогда его необходимо принять (с помощью жесткого кодирования) вашего кода дешифрования, и нет необходимости хранить эти данные в любом случае. Нет необходимости включать статические данные в сообщение HMAC, поскольку оно не влияет на расшифровку.

Примером формата файла, который использует статический алгоритм, является формат файла AES-256 Crypt с открытым исходным кодом. Алгоритм согласован, поэтому он всегда принимается. Фактически он использует 2 HMAC для скорости. 1 для аутентификации IV и ключей, а второй для аутентификации зашифрованной части данных.