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

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

2 голосов
/ 11 марта 2019

У меня есть фрагмент кода, где я оборачиваю свой симметричный ключ (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).

1 Ответ

5 голосов
/ 11 марта 2019

Завернутый ключ с использованием стандартного режима работы - это просто шифрование закодированных данных ключа.Поскольку закодированные данные ключа 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.К сожалению, библиотеки шифрования общего назначения часто не содержат реализации этих режимов.

...