Re: Question regarding using AES in CTR mode to encrypt UDP

On 1 May 2006 12:49:13 -0700, tomstdenis@xxxxxxxxx wrote:

Itay wrote:
In his libtomnet, he is using AES-128 in CTR mode.
I am interested in encrypting/decrypting packet buffers which I then
sendto/recvfrom using UDP,
but in CTR mode I have a problem synchronising the counter of the CTR
mode (or the IV) -
in UDP packets might get lost, so the synchronization between counters
on both peers is lost as well, for example :

I'd use GCM or CCM mode to get authentication as well. [LTN uses
HMAC-SHA1 for that].

OK, I will check those out in your LTC manual, thanks :-)

As for handling out of order, the simplest method is

1. Reject old packets with a soft error
2. Accept packets from the future

Another way is to have a sliding window of upto 32 packets . As you
get newer packets you slide older ones off. E.g. if you get 2 then 1
that's ok but if you get 33 then 1 that will be too old and return a
soft error.

This solves the problem of knowing which sequence number to
accept\reject
when doing the authentication (anti replay), but how does it solve the
synchronization of the CTR counters (assuming I still want to use CTR,
and I need the exact same counters in order to reverse the encryption
on peer B and get the same plaintext that peer A had before he did the
encryption) ?

Could someone please help me in resolving this issue(one idea I had,
was to send the counter/IV with the encrypted
message, but that increases the packets, and I would like to avoid
it).

You have to make sure you're in sync when you start. After that you
should be ok.

Can you explain in a little more detail, thanks :-)

So, how can I use CTR mode to encrypt UDP traffic (or if I cannot use
it, what mode (CBC, CFB or other )is best
recommended for working with such a protocol as UDP (unreliable) ?

Why would CBC mode be better?

I didn't say it was better, my main question is :
can I use CTR when encrypting UDP ?

Tom
.

Relevant Pages

  • [UNIX] Security Flaws Found in Tinc
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... This section describes how Tinc secures forwarded packets. ... The aim of encryption is to make the data unreadable for anybody who does ... It does not prevent an attacker from modifying the data. ...
    (Securiteam)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)
  • Re: Using a home T-1 line to evade company filtering
    ... >> computers than the boss. ... >> without shutting off Web access for everyone in the station. ... >> also smart enough to know how to encrypt those packets, ... they could try to hack the packets by guessing the encryption. ...
    (comp.security.firewalls)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)
  • Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49
    ... because the thing you race with is not the "return to user space" ... And those incoming packets might have been incoming before the rules were ... of various counters -- there are a number of Linux networking users who ... 32-bit UP machines and 64-bit machines are not ...
    (Linux-Kernel)