picking a hash function to be encrypted

So...

Suppose I want a function to provide integrity and
authentication, and
that is to be combined with a stream cipher (as is the
plaintext).  I
believe that authentication is free once I have integrity
given the
fact that the hash value is superencrypted using the stream
cipher,
whose key is shared by only the sender and recipient.  I
believe what
I'm looking for is a strongly universal hash.  I don't
need much;
everything I've seen is simultaneously too much and too
little, often
calling upon a block cipher, which seems redundant.

What I was thinking of doing was using Poly1305, and using
the stream
cipher instead of AES.  I think in this case that I can
leave the MAC
exposed, since it's a MAC and not a hash.  Is there an
analogous, hash
function that does not use encryption internally?

Backing up a bit, are there simpler hash functions (or
families of
functions) that could scale and, given the stream cipher, do
the job?
For example, the wikipedia entry for UMAC* shows a very
simple hash
family, which is trivial to scale to give a desired security
level
|D|.  So I have a couple of questions about it; first, is it
appropriate to use in this circumstance?  Second, how would
I
authenticate variable-length messages; do I merely break
them up into
sequential pieces and authenticate each piece seperately, or
is there
a way to authenticate the whole thing without using some
other hash
function?

[*] http://en.wikipedia
.org/wiki/UMAC

I'd really like to read the fine literature, but most of
the papers
I've found appear to predate the web.  Any URLs would be
much
appreciated.

And for reading this whole email, you get a present:
http://
dsns.csie.nctu.edu.tw/research/crypto/
-- 
"Curiousity killed the cat, but for a while I was a
suspect" -- Steven Wright
Security Guru for Hire http://www.li
ghtconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098
0C55 1484

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On Sun, May 14, 2006 at 03:04:41AM -0500, Travis H. wrote:

> Suppose I want a function to provide integrity and
authentication, and
> that is to be combined with a stream cipher (as is the
plaintext).  I
> believe that authentication is free once I have
integrity given the
> fact that the hash value is superencrypted using the
stream cipher,
> whose key is shared by only the sender and recipient. 
I believe what
> I'm looking for is a strongly universal hash.  I
don't need much;
> everything I've seen is simultaneously too much and
too little, often
> calling upon a block cipher, which seems redundant.
> 
> What I was thinking of doing was using Poly1305, and
using the stream
> cipher instead of AES.  I think in this case that I can
leave the MAC
> exposed, since it's a MAC and not a hash.  Is there an
analogous, hash
> function that does not use encryption internally?
> 

Security is fragile. Deviating from well understood
primitives may be
good research, but is not good engineering. Especially
fragile are:

- Non-mainstream ciphers (often broken once someone good
bothers to try)
- Stream ciphers (additive)
- RC4 (poor key schedule)
- RSA (multiplicative)

The first is to be avoided entirely, the second and third
should be
used only under duress, when block ciphers are a very poor
fit for the
application. RSA needs to be used only in very specific ways
(PKCS 2.1,
for example) that avoid the common pitfalls.

TLS (available via OpenSSL) provides integrity and
authentication, any
reason to re-invent the wheel? It took multiple iterations
of design
improvements to get TLS right, even though it was designed
by experts.

-- 

 /"\ ASCII RIBBON                  NOTICE: If
received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and
notify
  X AGAINST       IT Security,     sender. Sender does not
waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or
privilege,
                                   and use is prohibited.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On 5/14/06, Victor Duchovni <Victor.Duchovnimorganstanley.com> wrote:
> Security is fragile. Deviating from well understood
primitives may be
> good research, but is not good engineering. Especially
fragile are:

Point taken.  This is not for a production system, it's a
research thing.

> TLS (available via OpenSSL) provides integrity and
authentication, any
> reason to re-invent the wheel? It took multiple
iterations of design
> improvements to get TLS right, even though it was
designed by experts.

IIUC, protocol design _should_ be easy, you just perform
some
finite-state analysis and verify that, assuming your
primitives are
ideal, no protocol-level operations break it.  The 7th
Usenix Security
Symposium has a paper where the authors built up SSL 3.0 to
find out
what attack each datum was meant to prevent.  They used
mur-phi, which
has been used for VLSI verification (i.e. large numbers of
states).
AT&T published some code to do it too (called SPIN). 
It's effective
if the set of attacks you're protecting against is finite
and
enumerable (for protocol design, I think it should be;
reflection,
replay, reorder, suppress, inject, etc.).  I wouldn't
consider
fielding a protocol design without sanity-checking it using
such a
tool.  Was there an attack against TLS which got past FSA,
or did the
experts not know about FSA?
-- 
"Curiousity killed the cat, but for a while I was a
suspect" -- Steven Wright
Security Guru for Hire http://www.li
ghtconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098
0C55 1484

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

On Sun, May 14, 2006 at 07:56:17PM -0500, Travis H. wrote:

> On 5/14/06, Victor Duchovni <Victor.Duchovnimorganstanley.com> wrote:
> >Security is fragile. Deviating from well understood
primitives may be
> >good research, but is not good engineering.
Especially fragile are:
> 
> Point taken.  This is not for a production system,
it's a research thing.
> 
> >TLS (available via OpenSSL) provides integrity and
authentication, any
> >reason to re-invent the wheel? It took multiple
iterations of design
> >improvements to get TLS right, even though it was
designed by experts.
> 
> IIUC, protocol design _should_ be easy

Once upon a time, everyone agreed that cipher design was
hard.  Later
people discovered that protocol design is hard too.  More
recently
people are discovering that given solid ciphers and
protocols, secure
implementations are still hard... I could be wrong, but it
does not
seem that the trend is towards "increasingly
easy" security, in the
sense that anyone who learns a programming language
reasonably well can
develop security toolkits. :-(

-- 

 /"\ ASCII RIBBON                  NOTICE: If
received in error,
 \ / CAMPAIGN     Victor Duchovni  please destroy and
notify
  X AGAINST       IT Security,     sender. Sender does not
waive
 / \ HTML MAIL    Morgan Stanley   confidentiality or
privilege,
                                   and use is prohibited.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

* Travis H.:

> IIUC, protocol design _should_ be easy, you just
perform some
> finite-state analysis and verify that, assuming your
primitives are
> ideal, no protocol-level operations break it.

Is this still true if you don't know your actual
requirements?

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com