"Boradcasting" MAC'd data

From: Michael Brown (see_at_signature.below)
Date: 04/18/05 

Date: Tue, 19 Apr 2005 01:19:14 +1000

I've got a somewhat interesting problem that I'd like a bit of advice on. I
have some data, usually in the order of a few KB, that needs to be sent out
to a large number of clients over UDP. The data is not secret, so no
encryption is required. What is required is authentication and replay
prevention; noone should be able to impersonate the server (MITM excluded),
and noone should be able to resend the packet they received (or
eavesdropped) and fool another client.

On approach is obviously to use public key crypto and have the server sign
the packets. However, I suspect the CPU usage of all these signings would be
excessive.

My current idea is to have the client and server "connect" through DH key
exchange. The server stores IP address, port, and the key. When a broadcast
needs to be done, the server sends each client a packet. However, each
packet is specifically for the client: it contains the IP address, port, and
a sequence number. This packet is then protected using a MAC (keyed with the
value obtained from the DH key exchange). I think this covers all the bases
... assuming the MAC cannot be forged, then the only clients that will not
drop the packet are those with the same secret key (ie: the same instance of
the client), and these will only accept it if the sequence number is right.

Now, I'd still like to reduce the CPU impact further :) One thing that (IMO)
seems wasteful is that the same data is being MACed over and over again.
What would be ideal is if the bulk of the data, the stuff that is being
broadcast, is only processed once. None of the standard MACs seem to be able
to do this, as they all do keying prior to processing. However, what about
padding the broadcast data to 512 bits, shoving these blocks through MD5,
then doing a final MD5 block consisting only of the IP and port for each of
the connections (replace MD5 and 512 bits with your hash function of choice
and it's block size). The two obvious options from this are to include the
key in the final block, or to encrypt the resulting hash with the key. I
remember both of these approaches being discussed on sci.crypt in the past,
but can't seem to find the threads any more. Are either of these secure
enough for short-term use (client sessions will not, in general, last for
more than a week or two; most are probably going to be in the order of a
day)? If not, or even if so, are there better alternatives with something of
a track record behind them? 

-- 
Michael Brown
Add michael@ to emboss.co.nz ---+--- My inbox is always open

Relevant Pages

  • [REVS] Backdoor Spotcom Analysis
    ... Spotcom is a backdoor client application that allows a hacker to control ... The server IP address is hard-coded in ... msrsvp.exe accepts a couple of command line arguments. ... the packet payload. ...
    (Securiteam)
  • Re: Socket weirdness
    ... client) before you will notice a shutdown receive at server. ... Then eventually a packet comes from the peer, and that will contain data, so the server responds RST: ... way back across the network. ...
    (microsoft.public.dotnet.framework)
  • Re: Strange problem drive me mad.
    ... not by the TCP layer. ... > Thanks for reply, actually, the problem is that client (may caused by ... > always flush data before I decode the each packet when buffer is full. ...
    (microsoft.public.win32.programmer.networks)
  • Re: SACK (and PF) wierdness
    ... the point where pf drops the packet because it sees a violation of the ... This is an active FTP data connection, from FTP server 192.168.1.10:20 ... to FTP client 192.168.1.200:64828, where payload is only flowing from ... This is a violation of the client's window by the server, ...
    (freebsd-net)
  • OT: Problem with IIS6 and RDS
    ... Network settings for these machines are identical (except IP ... Without using RDS both machines have similar responce time for remote client ... We used Windows Network Monitor for capture all traffic between server and ... after that occur HTTP server reply (some packets according max packet size ...
    (microsoft.public.vc.atl)