Subject: [ietf-tls] I-D ACTION:draft-krovetz-umac-01.txt

From: [email-masked]
Date: Wed, 25 Oct 2000 06:16:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: UMAC: Message Authentication Code using Universal 
                          Hashing
	Author(s)	: T. Krovetz et al.
	Filename	: draft-krovetz-umac-01.txt
	Pages		: 39
	Date		: 24-Oct-00
	
This specification describes how to generate an authentication tag
(also called a 'MAC') using the UMAC message authentication code.
UMAC is designed to be very fast to compute, in software, on
contemporary processors.  Measured speeds are as low as 1.0 cycles
per byte.  The heart of UMAC is a universal hash function, UHASH,
which relies on addition and multiplication of 16-bit, 32-bit, or
64-bit numbers, operations well-supported by contemporary machines.
To generate the authentication tag on a given message, UHASH is
applied to the message and key to produce a short, fixed-length, hash
value, and this hash value is then XOR-ed with a key-derived
pseudorandom pad.  UMAC enjoys a rigorous security analysis and its
only 'cryptographic' use is a block cipher, AES, to generate the
pseudorandom pads and internal key material.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krovetz-umac-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-krovetz-umac-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-krovetz-umac-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Lewis McCarthy <[email-masked]>
Date: Thu, 26 Oct 2000 00:18:31 -0700

Hi,

> (also called a 'MAC') using the UMAC message authentication code.
[...]
> To generate the authentication tag on a given message, UHASH is
[...]

I have a question about the terminology used in this draft.
Throughout the document the term "authentication tag" seems to be
preferred to "message authentication code" (or simply "MAC"). 
Since the term "MAC" is very well established in the literature
and community, I wonder why you would prefer to use the other 
phrase. 

(I took a quick look on the web and at the Crypto `00 proceedings
in search of evidence for "authentication tag" coming into 
vogue. An Alta Vista search on "message authentication code" 
alone produced the maximum 1000 hits. A corresponding search for
"authentication tag" yielded just 46 hits. In the Message 
Authentication session of the last Crypto, the abstracts of 
all three papers use "MAC" and none use "authentication tag".)

-Lewis
-- 
http://home.att.net/~lewis.mccarthy
[email-masked]    1-408-499-5708    UTC-07
"An article in The Times Magazine last Sunday about

Ivana Trump and her spending habits misstated the
number of bras she buys. It is two dozen black, two
dozen beige and two dozen white, not two thousand
of each." --NY Times `Corrections` 22 Oct 2000

---

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 26 Oct 2000 17:53:34 +0200 (IST)

As recently announced, the draft draft-krovetz-umac-01.txt is available 
from the Internet-Drafts directory.
This document contains a full specification of the "UMAC" 
Message Authentication Code (i.e a function that provides data 
integrity verification for entities that share a key).
This is the result of a three-year project involving several researchers.  
A paper describing the mathematical foundations of the algorithm 
was published more than a year ago in CRYPTO '99 [1].

UMAC was designed to provide strong authenticity guarantees while 
being flexible, provably secure, and **as fast as possible** on modern 
(and emerging) processors.  Experiments show that UMAC achieves 
software speeds that are many times the speed of HMAC-SHA1.  
A quite unique feature of UMAC is that it lets you easily trade performance
and security: from weak authentication against Denial of Service at 
GigaByte/second to the strongest authentication for the real paranoids 
at 100's of MegaBytes/second.

For the most speed-demanding applications, as they emerge, I believe 
that UMAC provides a solution that is superior to current algorithms 
based on cryptographic hash functions (e.g. HMAC) or block ciphers 
(e.g. CBC-MAC).

See the the UMAC homepage,  http://www.cs.ucdavis.edu/~rogaway/umac,  
for additional information, including some performance details. 

Hugo

PS: A word about UMAC's security. 
    UMAC's security analysis is based on two factors:
      1) The 20-year old methodology (due to Carter and Wegman) for 
         building MAC functions on the basis of universal hashing.
      2) The availability of a strong cipher (e.g. AES).
    The result of this analysis is that the only way that the proven 
    security bounds for UMAC could fail is by breaking the underlying
    cipher (say Rijndael).  As long as this cipher is unbroken so is UMAC.  
    In this sense, UMAC does not need to be subject to cryptanalytical
    scrutiny before it can be used; you just need to believe that the
    underlying block cipher is secure.
    (See more information in [1] and in the draft's Security Considerations)

[1]  J. Black, S. Halevi, H. Krawczyk, T. Krovetz, and P. Rogaway. 
"UMAC: Fast and secure message authentication".   Advances in 
Cryptology - CRYPTO '99.  Lecture Notes in Computer Science, 
vol. 1666, Springer-Verlag, 1999, pp. 216-233.

---

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 26 Oct 2000 18:29:38 +0200 (IST)

> and community, I wonder why you would prefer to use the other 

In the cryptographic context the word MAC is used to denote
data authentication functions based on shared keys.
Sometimes MAC is also used to denote the output of the function.
However, this is confusing. Therefore it is quite common to find
in the crypto literature the term "authentication tag"
to denote the output of the function, i,e the actual authentication bits
that you append to a message for transmission.
(In other words, an authentication tag is to a MAC as a ciphertext to
encryption.)

Hugo

> You are currently subscribed to ietf-tls as: [email-masked]

---

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 26 Oct 2000 14:33:04 -0400 (EDT)

The Handbook of Applied Cryptography refers to "MAC algorithms" as the
functions, and MAC as the resulting output:

  "Keyed hash functions whose specific purpose is message authentication
   are called message authentication code (MAC) algorithms."
  
and

  "Algorithm CBC-MAC
   INPUT: data x; ...
   OUTPUT: n-bit MAC on x"

It is also common usage for the term "code" to refer to a data value;
I ordered a computer by phone this past weekend, and was given both a
"customer code" and an "order code".  Using message authentication code
for data doesn't seem especially confusing.

-----

While we're on the topic of vocabulary, I'd like to hear opinions on
the meaning of PFS.  I'm inclined to believe David Hopwood that
"perfect" implies forward secrecy against a computationally-unbound
opponent.  Is the IETF idiom of using PFS to mean nothing other than FS
at odds with its generally-accepted cryptographic meaning?

Dave

> From: Hugo Krawczyk <[email-masked]>
> 

---

---

From: David Jablon <[email-masked]>
Date: Thu, 26 Oct 2000 16:38:41 -0400

David,

The term PFS came first (introduced by Diffie vanOorschot & Weiner in 1992 
perhaps?),
got changed to FS in certain circles (like P1363) to avoid the implied 
meaning that
you mention, and which almost nobody intended it to mean.

For what it's worth, I think the P should be dropped entirely, and the term PFS
deprecated, rather than trying to transmute it to mean something other than FS.

-- David

---

---

From: David Hopwood <[email-masked]>
Date: Fri, 27 Oct 2000 21:00:56 +0100

-----BEGIN PGP SIGNED MESSAGE-----

David Jablon wrote:
> perhaps?), ...

I believe it was first used in

  Cristoph G. Günther,
  "An identity-based key-exchange protocol,"
  Advances in Cryptology - EUROCRYPT '89 Proceedings,
  Lecture Notes in Comp. Sci. Vol. 434 (J-J. Quisquater, J. Vandewille ed.),
  Springer-Verlag, 1989.

It's also worth pointing out that forward secrecy is usually associated
with security against passive known-key attacks (i.e. if an attacker knows
the long-term authentication key of one of the parties, he still cannot
do a passive eavesdropping attack on the protocol, only an active attack).
Technically they are two distinct properties, though.

> For what it's worth, I think the P should be dropped entirely, and the
> term PFS deprecated, rather than trying to transmute it to mean something
> other than FS.

I agree.

For MACs, "authentication tag" and "MAC output" are synonyms, and there's
not much to choose between them.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---