Если мы обернем 256-битный ключ AES ключом AES, тогда размер обернутого ключа может быть больше 32 байтов?

У меня есть фрагмент кода, в котором я оборачиваю свой симметричный ключ (AES) ключом AES:

  1. swkKey: это ключ AES, используемый для упаковки.
  2. ключ: ключ, который нужно обернуть.

Код:

SecretKey swkKeySpec = new SecretKeySpec(swkKey, 0, swkKey.length, "AES");
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding", "BC");
final int ivLength = 12;
final IvParameterSpec iv = createIV(ivLength);///Creates a new array.
cipher.init(Cipher.WRAP_MODE, swkKeySpec, iv);
SecretKey sKeySpec = new SecretKeySpec(key, 0, key.length, "AES");
byte[] wrappedAppKey = cipher.wrap(sKeySpec);`

Какой будет длина wrappedAppKey, если ключ равен 256 бит, а swkkey - 256 бит. Может ли завернутый ключ быть больше 32 байтов? Обратите внимание, в этом случае я получаю следующие журналы:

key length: 32(key to be wrapped)
swkKey length: 32(key used to wrap)
wrappedAppKey size: 48(final wrapped key output).

java encryption aes cryptography symmetric-key
person Vikas Rai    schedule 11.03.2019    source источник
comment
Добро пожаловать в StackOverflow! Кажется, у вашего вопроса есть собственный ответ (48 байтов; хотя это меня немного смущает, я ожидал, что это реализует RFC 3394, который должен иметь вывод 40 байтов; длина ключа + 1 полублок). Когда вы говорите, что более 32 бит, вы имели в виду более 32 байтов? У вас вопрос, почему завернутый ключ длиннее оригинального? Как несвязанное замечание, то, что вы называете swkKey, обычно называется KEK (ключ шифрования ключа) в любой документации, которую вы читаете.   -  person Rob Napier    schedule 11.03.2019
comment
или просто заворачивая ключ конечно.   -  person Maarten Bodewes    schedule 11.03.2019

Ответы (1)


arrow_upward
7
arrow_downward

Обернутый ключ с использованием стандартного режима работы - это просто шифрование закодированных данных ключа. Поскольку закодированные данные ключа AES идентичны необработанным данным, данные 256-битного ключа составляют просто 32 байта.

Основное различие для этих неспециализированных режимов, таких как GCM / CBC / ECB, заключается в том, как обрабатываются ключевые байты: они напрямую используются в экземпляре SecretKey вместо того, чтобы возвращаться как байты. Это очень важно, особенно если операция выполняется аппаратно (смарт-карта, HSM, TPM), а не программно; байты обернутых ключей могут затем храниться / защищаться в специализированном устройстве.

GCM использует режим CTR внизу, который является потоковым режимом работы. Потоковый режим работы не требует заполнения открытого текста, поэтому зашифрованный текст также будет иметь размер 32 байта. Java также включает в расчет тег аутентификации (t). По умолчанию GCM использует максимальный размер тега аутентификации, который составляет 16 байтов, поэтому он добавляется к зашифрованному тексту самого ключа, оставляя вам 48 байтов. Размер тега можно настроить с помощью более специализированного класса GCMParameterSpec, а не ivParameterSpec; обратите внимание, что меньшие размеры тегов могут представлять уязвимости для режима GCM.

Однако помните, что также требуется возможность повторно сгенерировать IV / nonce для шифрования в режиме GCM. Так что вам нужно сохранить и это, если его нельзя восстановить из контекста. Также обратите внимание, что режим GCM ужасно ломается, если одноразовый номер когда-либо повторно используется для того же ключа упаковки. В большинстве случаев использование полностью случайного одноразового номера и поэтому сохранение его с зашифрованным текстом имеет большое значение. Для GCM настоятельно рекомендуется использовать 12-байтовый одноразовый номер, расширяя зашифрованный текст до 60 байтов.

В качестве альтернативы можно использовать режим SIV или режим GCM-SIV. В этих режимах тег аутентификации используется как «синтетический» IV. Это делает шифрование детерминированным (идентичный открытый текст приводит к одному и тому же зашифрованному тексту). Поскольку предполагается, что ключ сам по себе является случайным, они очень полезны для таких режимов, поскольку не требуют использования ГСЧ или хранения IV. К сожалению, криптографические библиотеки общего назначения часто не содержат реализации этих режимов.

person Maarten Bodewes    schedule 11.03.2019