[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Use of Encryption in Heartbeat Packets
Andrew Krywaniuk writes:
> Encryption does provide a "quick authentication check."
I disagree this. I don't think it is going to be faster for any packet
size in normal operation, and for slow ciphers it is going to be very
much slower. On the other hand the saving offered by it are quite
small compared to the doing the real MAC in the first place.
What you are comparing is the speed of
1) HASH(Last-CBC-Block || Message-ID) + Decrypt(1st-block)
to the speed of the
2) HMAC-HASH(Rest of the packet)
to do the first check, and then in the case 1 you need to do also the
Decrypt(rest of the packet after 1st block) +
HMAC-HASH(Rest of the packet).
Here the case 1 is the encrypted packet having MAC inside the
encrypted part and the sequence number in the first block so random
packets can be discarded after decrypting that one block. The case 2
is when the packet has only MAC, and no encryption at all.
If you don't have any spi's in the packet the packet "Rest of the
packet" is going to be only the notify payload (12 + 16 = 28 bytes).
So the packet in total is 28 bytes of header + 8 bytes of sequence
number + 20 bytes of hash + 28 bytes of notify. The total length is
going to be 84 bytes, and the encrypted part of it is 56 bytes. The
authenticated part of the message is 28 bytes.
If we assume IKE SA is using 3des-md5, then the speeds are about
following:
1) md5(last-cbc-block || message-id) = 6 ms
3des-cbc of one block = 20 ms
3des-cbc of the rest of the blocks = 119 ms
in total it is going to be 26 ms + 119 ms + 30 ms.
2) Hmac-md5 of 64 bytes = 30 ms.
I.e in the DoS case you are saving for only the 4 ms, but in addition
you need to do the extra decryption for the rest of the packet, so for
each valid packet you waste 145 ms (total decryption time + the IV
generation time).
If the packet contains 200 byte spi list payload also, then the timing
is going to be:
1) md5(last-cbc-block || message-id) = 6 ms
3des-cbc of one block = 20 ms
3des-cbc of the rest of the blocks = 614 ms
in total it is going to be 26 ms + 614 ms + 30 ms.
2) Hmac-md5 of 256 bytes = 57 ms
I.e in the DoS case you are saving for for 31 ms, but you are then
wasting the 640 ms for each valid packet.
For blowfish-cbc and md5 the values in the case 1 are little bit
different:
1) md5(last-cbc-block || message-id) = 6 ms
blowfish-cbc of one block = 4 ms
blowfish-cbc of the rest of the blocks = 18 ms
So for the DoS case you save 20 ms for the DoS packet and do only 28 ms
extra work for valid packet.
For the larger packet the numbers are:
1) md5(last-cbc-block || message-id) = 6 ms
blowfish-cbc of one block = 4 ms
blowfish-cbc of the rest of the blocks = 95 ms
And for DoS case you save 47 ms, and you loose 105 ms in the valid
packet case.
> In formal-speak, encryption provides an O(1) authentication check of a NbnS
> indicator of packet validity. (NbnS = Necessary, but not Sufficient)
Yes, the time is O(1), but the constant factor is quite large (one
hash for the iv and one cbc decryption) compared to the only hmac-hash
for the rest of the packet.
In the DoS case the saving of the cpu is quite small, but in the valid
packet case the wasting of the cpu is quite large. For the faster
cipher the numbers are not that bad, but you still waste quite a lot
of cpu time for valid packets.
I think the gain you get for decrypting the first cbc block first and
checking the sequence number first is not enought to justify the
wasting of the cpu time for normal valid packets.
Ps. The numbers are from our crypto library using 500 MHz alpha. For
the hardware accelerated case the overhead of starting the decryption
etc is propably also going to play important role.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups: