Michael> Are you sure you tested 3des-cbc with hmac-md5 or with some Michael> other authentication algorithm? I don't doubt that for some Michael> other authentication algorithms where authlen is set Michael> correctly your code works fine.
every night, 170 different test cases for Openswan. please: marajade-[~/src/tcpdump/tcpdump] mcr 1003 %cd tests marajade-[src/tcpdump/tcpdump/tests] mcr 1005 %sh esp2.sh test esp2...reading from file 08-sunrise-sunset-esp2.pcap, link-type EN10MB (Ethernet) passed.
I tried to do what the tcpdump man page says and used
3des-cbc:0xa...
After looking into esp2.sh I found that it should be
3des-cbc-hmac96
The man page doesn't mention the existence of the hmac96 syntax at all.
Sorry for the confusion. But this is what the -E part of the man page causes. It's quite unusable.
Michael
If this doesn't match what you are trying to do, then please provide
a new pcap file that does. I think you just missed the "96" at the end
of the algorithm name.
That may be a bug that we go ahead without it. (96bits = 12 bytes)
Michael> For *-cbc algorithms the problem seems to be that Michael> decryption starts at the end of the encrypted area and Michael> works its way backwards to the start. If authlen is wrong Michael> everything is decrypted into garbage. This is because the Michael> encrypted blocks are chained and a block can only be Michael> decrypted if the previous block (the one behind) was Michael> decrypted sucessfully.
No, that's not correct at all. Encryption and decryption proceed in the same direction. The problem is that the last two bytes of the plaintext are special in ESP. Last byte is the next-protocol (usually 4), and next to last is the number of pad bytes.
I was wrong. Not decrypting the next-protocol was the probklem. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
