[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed changes to the DES-CBC, HMAC and Replay Prevetion Security Transform.
>
>So that both sides will know what is in use?
>
I don't care what the other side is using.. So why negotiate?
>
>Denial of service attacks.
>
Explain this. What denial of service attacks exist which depend on the
size of the replay window..?
>
>You have to save information on every packet you've already seen for
>which the bottom of the window hasn't been passed. This leaves you
>open to having attackers force you to consume memory and CPU if you
>have a large window.
>
You store a bit in a mask versus a longword value. The replay counter is
above your window, slide the window. Replay counter is below, drop the
packet. If it is in your window, set bit if not set, else drop if set.
If you have a window of 1, test to see if the counter is saved++, if so,
increment saved, else drop.
In BOTH cases, you must decrypt the packet and sign it before you can
really validate the replay window. Both require the same CPU and memory to
decrypt/sign the packet. A window requires an extra longword to save the
count of the bottom of the window and 30 more lines of code.
The only possible attack I can see is if your keys are had and an attacker
can impersonate you in everyway, the attacker has 1 chance in 2^32 to get
through your replay test for a window size of 1, versus 32 chances in 2^32
for a 32 bit window. In any case, if an attacker has your keys, they can
rip your packets open and see what sequence your at anyway.