Comment # 12
on bug 10783
from Matthijs Kooijman
Regarding the indentation errors: The original file is indented uses 4 spaces
per level and never uses actual tabs. The patch is created with one tab per
level. If you show tabs as 4 spaces, the indentation improves somewhat, but
there are still if/while structures that do not have their contents indented.
There's also trailing whitespace on some lines.
The code opens and closes a new gcrypt object for each 16-byte block being
decrypted. I don't know gcrypt, but I would not expect that to be needed (I
even wonder if gcrypt cannot handle the 16-byte chunking and cipher feedback
chaining method used already? Seems it does:
https://www.gnupg.org/documentation/manuals/gcrypt/Available-cipher-modes.html
though perhaps that doesn't allow also calculating the MIC?).
The code currently only dissects un-encrypted command packets, but I think it
should also try to dissect succesfully decrypted command packets as well?
Non-command packets are shown only as a hex dump in the treeview, it would be
useful if you could somehow also see the ASCII interpretation of those bytes
(not sure how to approach that, though).
I've attached a capture I've been using. The key used is
31:32:33:34:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff. The capture contains a number
of seemingly succesful decryptions (haven't verified the data, but he MIC is
said to be correct). Some packets have incorrect MICs. It's certainly possible
that there are errors in the capture, but since these packets do have a correct
FCS (checksum in the 802.15.4 layer), I suspect there is some problem in the
lwmesh decryption. Also, it's remarkable that the failing packets all havbe
10-14 bytes of encrypted data, and all packets of that length have failing
MICs. I was thinking that < 16 bytes wasn't properly handled, but there are
also packets with 7 or 8 bytes that do have a matching MIC. Another option
would be that these packets aren't proper LWM packets somehow, but my hardware
shouldn't be sending anything else and the LWM headers look ok to me, so I
suspect it's not that.
I don't have time to investigate this further now, but perhaps this capture
allows someone else to look closer.
You are receiving this mail because:
- You are watching all bug changes.