Случайность и аутентификация на выходе коротких значений (48 бит)

Я хочу реализовать клиент, который генерирует случайные 48-битные значения и отправляет их в виде широковещательных сообщений. Мы также предполагаем, что есть легитимный получатель, получающий эти значения (таким образом, есть какая-то предварительная аутентификация, которая уже произошла, но здесь это не важно. Мы также можем предположить, что клиент/получатель использует общий ключ $К$). Поскольку это широковещательные сообщения, это также означает, что любой может перехватить эти значения. Я хотел бы, чтобы эти значения имели два свойства:

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

Я думал о простой схеме, которая делает следующее:

Клиент

1. $t$ = AES-CTR($К$, nonce||счетчик, random_plaintext)…

2. $r = t K$ (оставить последние 48 бит)

3. Транслировать $ т, р $

Я использую AES-CTR для создания временной случайной строки $t$ а затем XOR с ключом еще раз, чтобы сгенерировать мое случайное значение.Затем я сохраняю последние 48 бит и транслирую оба $t$ и $г$. Тогда получатель может просто:

Приемник

1. $r' = t K$ (оставить последние 48 бит)
2. Проверять $г' == г$

Если проверка прошла успешно, он аутентифицирует клиента, потому что только он знает тот же ключ. $К$. Кроме того, значение, являющееся выходом AES-CTR, должно быть довольно случайным, что означает, что кому-то очень сложно угадать следующее.

Соответствует ли эта схема моим требованиям? Представляет ли усечение последних 48 битов угрозу безопасности?

Соответствует ли эта схема моим требованиям? Представляет ли усечение последних 48 битов угрозу безопасности?

Схема нарушается пассивным противником, который получает одну пару $(т,р)$. Обратите внимание, что последние 48 бит ключа могут быть восстановлены как $K[:48] = t \oplus r$. Таким образом, злоумышленник теперь может отправлять произвольные $(т^*, г^*)$ значения, которые примет получатель. Напоминая, что верификатор делает следующее

$r' = t' \oplus K$ (оставить только последние 48 бит); проверять $ г = г '$

Мы видим, что знание остального ключа не нужно.

Кроме того, 48-битные значения обеспечивают низкую защиту от коллизий, но это может подойти для вашего приложения...

Повтор: более простая атака состоит в том, чтобы воспроизвести пару $(г, т)$. В описании не сказано, как приемник это проверяет.

Возможное решение: Из первоначального описания кажется, что приемник довольно ограничен в вычислительном отношении, и он может вычислять, например, только xor, а не AES-CTR. Что было бы странно со следующим

Итак, есть какая-то предварительная аутентификация, которая уже произошла, но здесь это не имеет значения.

В любом случае, возможное решение — использование двух псевдослучайных функций, если получатель может делать больше, чем исключающие операции. (Я сомневаюсь, что это безопасно...). Сначала разверните $К$ в $К_1, К_2, К_3$ соответствующей длины.

Отправитель делает следующее

1. $ г = $ AES-CTR$(K_1, счетчик)$ (оставить последние 48 бит)
2. Отправить $счетчик, г, \тау = HMAC(K_2, счетчик,г)$

Получатель делает следующее

1. При получении $ г, тау $, проверять $\тау$
2. Счетчик чеков увеличился
3. Повторное получение $г$.

Некоторые замечания:

• Вещание здесь даже не нужно, если отправитель и получатель используют одни и те же часы.
• У альтернативы есть несколько проблем, когда речь идет о надежности в случае перезагрузки, как указано в комментарии Пола.