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