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)
|
|
---|---|---|---|
Authors | Morris Dworkin , Russ Housley | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
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, is an unsigned binary integer equal to the octet length of the plaintext key data, in network order -- that is, with the most significant octet first. When the MLI is not a multiple of 8, the key data is padded on the right with the least number of octetsShow full document text