Have it allocate the buffer for the unwrapped key and return a pointer
to it, rather than having it be handed a buffer for that key.
That makes it a bit easier to validate, in AES_unwrap, that we don't
write past the end of the buffer.
Change-Id: Id02852c23054b3ed33eeeb383e7aa6cf12d02ed9
Reviewed-on: https://code.wireshark.org/review/8371
Reviewed-by: Guy Harris <guy@alum.mit.edu>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
its own crypt-aes.
change the integer types to glib style integers
this may/will be helpful if/when we implement our own version of
kerberos
aes decryption of dcerpc since the existing libraries can not (yet)
handle when header signing is used.
we should implement our own decryption of this for cfx+aes just as we
did for classic+arcfour
svn path=/trunk/; revision=29228
Although this patch successfully recognizes group keys and decrypts packets
properly using the group key, there is a limitation. If an AP is using key
rotation, clicking on individual packets in a trace may not properly decrypt a
packet encrypted with a group key. This is because the current structure used
in Wireshark only supports one active unicast and one active group key. If a
new key has been seen, but you are looking at a packet encrypted with an older
key, it will not decrypt. The summary lines, however, do show the packets
properly decrypted.
I've written up a much longer and more detailed explanation in a comment in the
code, along with a proposed idea for a solution, plus a clunky work-around in
the GUI when using the current code.
I also suspect there might still be a problem with decrypting TKIP groups keys
that are sent using WPA2 authentication. In the most common operation, if you
are using WPA2, you'll also be using AES keys. It's not a common AP
configuration to use WPA2 with TKIP. In fact, most APs don't seem to support
it. Since it is an uncommon setup, I haven't put aside the time to test this
patch against such an AP. I do have access to an AP that supports this, so
when I have the time I'll test it and if needed, will submit another patch to
handle that odd-ball condition.
From me:
Remove the decrypt element of s_rijndael_ctx (which was unused, as indicated
in the comments).
Preserve the GPL licensing text in several files (which the patch shouldn't
have removed).
Remove changes that added whitespace.
Convert C++-style comments to C-style.
Update to include recent SVN changes (e.g. renaming variables named "index").
Remove extraneous printf's.
Define DEBUG_DUMP in airpdcap_debug.h.
Comment out some instances of DEBUG_DUMP.
Change malloc/free to g_malloc/g_free.
Use g_memdup instead of allocating and copying.
Use gint16 instead of INT16 in airpdcap_rijndael.c.
Add Brian to AUTHORS.
svn path=/trunk/; revision=25879
distcheck failure. Move the nmake build targets for airpdcap from
epan/dissectors to epan. This will probably break the Windows build.
svn path=/trunk/; revision=20231
2006-12-28 17:22:12 +00:00
Renamed from airpdcap/airpdcap_rijndael.c (Browse further)