David McGrew and Scott Fluhrer, of Cisco Systems, played a
significant role in improving UMAC by encouraging us to pay more attention to the performance of short messages. Thanks go to Jim Schaad and to those who made helpful suggestions to the CFRG mailing list for improving this document during RFC consideration. Black, Krovetz, and Rogaway have received support for this work under NSF awards 0208842, 0240000, and 9624560, and a gift from Cisco Systems.
Appendix. Test Vectors
Following are some sample UMAC outputs over a collection of input values, using AES with 16-byte keys. Let
K = "abcdefghijklmnop" // A 16-byte UMAC key N = "bcdefghi" // An 8-byte nonce The tags generated by UMAC using key K and nonce N are:
Message 32-bit Tag 64-bit Tag 96-bit Tag ---
<empty> 113145FB 6E155FAD26900BE1 32FEDB100C79AD58F07FF764 ’a’ * 3 3B91D102 44B5CB542F220104 185E4FE905CBA7BD85E4C2DC ’a’ * 2^10 599B350B 26BF2F5D60118BD9 7A54ABE04AF82D60FB298C3C ’a’ * 2^15 58DCF532 27F8EF643B0D118D 7B136BD911E4B734286EF2BE ’a’ * 2^20 DB6364D1 A4477E87E9F55853 F8ACFA3AC31CFEEA047F7B11 ’a’ * 2^25 5109A660 2E2DBC36860A0A5F 72C6388BACE3ACE6FBF062D9 ’abc’ * 1 ABF3A3A0 D4D7B9F6BD4FBFCF 883C3D4B97A61976FFCF2323 ’abc’ * 500 ABEB3C8B D4CF26DDEFD5C01A 8824A260C53C66A36C9260A6 The first column lists a small sample of messages that are strings of repeated ASCII ’a’ bytes or ’abc’ strings. The remaining columns give in hexadecimal the tags generated when UMAC is called with the corresponding message, nonce N and key K.
When using key K and producing a 64-bit tag, the following relevant keys are generated:
Iteration 1 Iteration 2 NH (Section 5.2.2)
K_1 ACD79B4F C6DFECA2 K_2 6EDA0D0E 964A710D K_3 1625B603 AD7EDE4D K_4 84F9FC93 A1D3935E K_5 C6DFECA2 62EC8672 ...
K_256 0BF0F56C 744C294F L2-HASH (Section 5.3.1)
k64 0094B8DD0137BEF8 01036F4D000E7E72 L3-HASH (Section 5.4.1)
k_5 056533C3A8 0504BF4D4E
k_6 07591E062E 0126E922FF k_7 0C2D30F89D 030C0399E2 k_8 046786437C 04C1CB8FED K2 2E79F461 A74C03AA
(Note that k_1 ... k_4 are not listed in this example because they are multiplied by zero in L3-HASH.)
When generating a 64-bit tag on input "’abc’ * 500", the following intermediate results are produced:
Iteration 1
L1-HASH E6096F94EDC45CAC1BEDCD0E7FDAA906 L2-HASH 0000000000000000A6C537D7986FA4AA L3-HASH 05F86309
Iteration 2
L1-HASH 2665EAD321CFAE79C82F3B90261641E5 L2-HASH 00000000000000001D79EAF247B394BF L3-HASH DF9AD858
Concatenating the two L3-HASH results produces a final UHASH result of 05F86309DF9AD858. The pad generated for nonce N is
D13745D4304F1842, which when xor’ed with the L3-HASH result yields a tag of D4CF26DDEFD5C01A.
References
Normative References
[1] FIPS-197, "Advanced Encryption Standard (AES)", National Institute of Standards and Technology, 2001.
Informative References
[2] D. Bernstein, "Stronger security bounds for permutations", unpublished manuscript, 2005. This work refines "Stronger security bounds for Wegman-Carter-Shoup authenticators", Advances in Cryptology - EUROCRYPT 2005, LNCS vol. 3494, pp.
164-180, Springer-Verlag, 2005.
[3] J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway, "UMAC: Fast and provably secure message authentication", Advances in Cryptology - CRYPTO ’99, LNCS vol. 1666, pp. 233, Springer-Verlag, 1999.
[4] L. Carter and M. Wegman, "Universal classes of hash functions", Journal of Computer and System Sciences, 18 (1979), pp. 154.
[5] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[6] T. Krovetz, "Software-optimized universal hashing and message authentication", UMI Dissertation Services, 2000.
[7] M. Wegman and L. Carter, "New hash functions and their use in authentication and set equality", Journal of Computer and System Sciences, 22 (1981), pp. 265-279.
Authors’ Addresses John Black
Department of Computer Science University of Colorado
Boulder, CO 80309 USA
EMail: jrblack@cs.colorado.edu
Shai Halevi
IBM T.J. Watson Research Center P.O. Box 704
Yorktown Heights, NY 10598 USA
EMail: shaih@alum.mit.edu
Alejandro Hevia
Department of Computer Science University of Chile
Santiago 837-0459 CHILE
EMail: ahevia@dcc.uchile.cl
Hugo Krawczyk IBM Research 19 Skyline Dr
Hawthorne, NY 10533 USA
EMail: hugo@ee.technion.ac.il
Ted Krovetz (Editor)
Department of Computer Science California State University Sacramento, CA 95819
USA
EMail: tdk@acm.org
Phillip Rogaway
Department of Computer Science University of California
Davis, CA 95616 USA
and
Department of Computer Science Faculty of Science
Chiang Mai University Chiang Mai 50200 THAILAND
EMail: rogaway@cs.ucdavis.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).