Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
RFC 5649
Document  Type 
RFC  Informational
(September 2009; No errata)
Was drafthousleyaeskeywrapwithpad (individual in sec area)



Last updated  20151014  
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/licenseinfo) 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 integrityprotect 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 [AESKW1, AESKW2]. Without this extension, the input to the AES Key Wrap algorithm, called the key data, must be a sequence of two or more 64bit 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 keyencryption 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 64bit 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 32bit 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 [AESKW1], 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 128bit block B using key K DEC(K, B) AES Decrypt the 128bit block B using key K V1  V2 Concatenate V1 and V2 K The keyencryption key m The number of octets in the key data n The number of 64bit blocks in the padded key data Q[i] The ith plaintext octet in the key data P[i] The ith 64bit plaintext block in the padded key data C[i] The ith 64bit ciphertext data block A The 64bit 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 32bit constant concatenated to a 32bit MLI. The constant is (in hexadecimal) A65959A6 and occupies the highorder 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 [AESKW1], so there is no ambiguity between the two. The 32bit MLI, which occupies the loworder 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