[sldev] Cryptographic signing of UDP packets

[Meadhbh Hamrick (Infinity)]

no. this is not how it would be done. take IPSec and SSL for instance.

a single public key operation (two if you're also talking a encryption  
with authentication) is used to setup a symmetric session key. the  
symmetric key is then used for "bulk" encryption. encrypting with a  
symmetric cipher like AES is orders of magnitude less computationally  
intensive than an asymmetric cipher like RSA, Rabin-Williams or even  
ECC. strong PRNGs (Pseudo Random Number Generators) can themselves be  
CPU intensive as many times they are designed to be efficient for  
generating large numbers of bytes (10k-65k) and PRNG setup can be  
relatively computationally intensive. many modern CPUs include  
hardware support for bulk encryption/decryption, lowering the cost of  
bulk encryption even more.

part of the problem with selecting a sequence number and seeding a  
PRNG with it is that it is relatively easy to guess the sequence  
number. there have in fact been a series of attacks based on this,  
including the recent DNS problems. and even if we could, there would  
still be the problem that applying a key stream to a packet. PRNGs are  
generally not intended to be used this way and are not designed to  
resist attacks based on key-stream recovery.

again... a number of these issues were investigated (painfully) during  
the late 80's and 90's. the results are (D)TLS and IPSec. even better,  
there are existing 'vetted' implementations of each of these protocols.

On Dec 17, 2008, at 8:03 AM, Carlo Wood wrote:

> 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>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting  
> privileges