Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
RFC 5649
| Document | Type |
RFC - Informational
(September 2009; No errata)
Was draft-housley-aes-key-wrap-with-pad (individual in sec area)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5649 (Informational) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Tim Polk | ||
| Send notices to | (None) | ||
Network Working Group R. Housley
Request for Comments: 5649 Vigil Security
Category: Informational M. Dworkin
NIST
August 2009
Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
Abstract
This document specifies a padding convention for use with the AES Key
Wrap algorithm specified in RFC 3394. This convention eliminates the
requirement that the length of the key to be wrapped be a multiple of
64 bits, allowing a key of any practical length to be wrapped.
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright and License Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Housley & Dworkin Informational [Page 1]
RFC 5649 AES Key Wrap with Padding Algorithm August 2009
1. Introduction
Management of cryptographic keys often leads to situations where one
symmetric key is used to encrypt and integrity-protect another key,
which can be either a symmetric key or an asymmetric key. The
operation is often called key wrapping.
This document specifies an extension of the Advanced Encryption
Standard (AES) Key Wrap algorithm [AES-KW1, AES-KW2]. Without this
extension, the input to the AES Key Wrap algorithm, called the key
data, must be a sequence of two or more 64-bit blocks.
The AES Key Wrap with Padding algorithm can be used to wrap a key of
any practical size with an AES key. The AES key-encryption key (KEK)
must be 128, 192, or 256 bits. The input key data may be as short as
one octet, which will result in an output of two 64-bit blocks (or 16
octets). Although the AES Key Wrap algorithm does not place a
maximum bound on the size of the key data that can be wrapped, this
extension does so. The use of a 32-bit fixed field to carry the
octet length of the key data bounds the size of the input at 2^32
octets. Most systems will have other factors that limit the
practical size of key data to much less than 2^32 octets.
A message length indicator (MLI) is defined as part of an
"Alternative Initial Value" in keeping with the statement in Section
2.2.3.2 of [AES-KW1], which says:
Also, if the key data is not just an AES key, it may not always be
a multiple of 64 bits. Alternative definitions of the initial
value can be used to address such problems.
2. Notation and Definitions
The following notation is used in the algorithm descriptions:
MSB(j, W) Return the most significant j bits of W
LSB(j, W) Return the least significant j bits of W
ENC(K, B) AES Encrypt the 128-bit block B using key K
DEC(K, B) AES Decrypt the 128-bit block B using key K
V1 | V2 Concatenate V1 and V2
K The key-encryption key
m The number of octets in the key data
n The number of 64-bit blocks in the padded key data
Q[i] The ith plaintext octet in the key data
P[i] The ith 64-bit plaintext block in the padded key data
C[i] The ith 64-bit ciphertext data block
A The 64-bit integrity check register
Housley & Dworkin Informational [Page 2]
RFC 5649 AES Key Wrap with Padding Algorithm August 2009
3. Alternative Initial Value
The Alternative Initial Value (AIV) required by this specification is
a 32-bit constant concatenated to a 32-bit MLI. The constant is (in
hexadecimal) A65959A6 and occupies the high-order half of the AIV.
Note that this differs from the high order 32 bits of the default IV
in Section 2.2.3.1 of [AES-KW1], so there is no ambiguity between the
two. The 32-bit MLI, which occupies the low-order half of the AIV,
Show full document text