[sldev] Cryptographic signing of UDP packets

[Carlo Wood]

On Tue, Dec 16, 2008 at 03:51:38PM +0000, Robin Cornelius wrote:
> On Tue, Dec 16, 2008 at 3:33 PM, Tateru Nino <tateru.nino at gmail.com> wrote:
> > The current protocol would mean that you couldn't rely on any cipher
> > block-chaining, mind. The packets can arrive out of order, and it is not
> > critical if some are missed, as currently specified - but the overhead
> > for a simple symmetrical cipher with a periodic key-exchange would be
> > quite low.
> 
> Yes of cause, each packet would have to be encrypted and decrypt-able
> with out any other packet dependencies due to the uncertain nature of
> UDP delivery.

But that would lead to low security. Strong encryption needs too much
cpu, therefore the normal way to do this is using a single key which
exchanged at the start of a session through a secure channel using
public key encryption (very cpu intensive). However, if each packet
has to be seperately decryptable, then the redundacy will be enormous
and it would be very easy (cost little cpu) to obtain the key from
from a number of packets (which assumes an attacker can intercept
them), even so much that it isn't worthwhile to change the key every
once in a while.

What would be needed is an unencrypted sequence number of enough
bits (say, 64) so that it can be used to seed a strong random
number generator (together with a larger key determined at the
start of the session).

I don't know how large the current 'sequence number' field is,
I assume 16 bit; then that would mean we'd need to add 64-16 = 48 bit
to each packet. However, whatever the size currently is apparently
we expect it to be enough to determine the order, and therefore
the extra 48 bits are not needed and can be moved to the the
salt.

Thus:

[16 bit sequence number][encrypted payload, without sequence number]

Such a packet would have the same size as now.

An other approach would be to assume that packets cannot
be intercepted, only inserted.

-- 
Carlo Wood <carlo at alinoe.com>