Age | Commit message (Collapse) | Author | Files | Lines |
|
As discussed on the mailinglist, rewriting dissectors to use Libgcrypt
functions as Libgcrypt will be mandatory after change 20030.
Removal of following functions:
- crypt_md4
- crypt_rc4*
- aes_cmac_encrypt_*
- md5_*
- sha1_*
- sha256_*
Further candidates:
- aes_*
- rijndael_*
- ...
Added functions:
- ws_hmac_buffer
Added const macros:
- HASH_MD5_LENGTH
- HASH_SHA1_LENGTH
Changes on epan/crypt/* verified with captures from
https://wiki.wireshark.org/HowToDecrypt802.11
Changes on packet-snmp.c and packet-radius.c verified with captures from
https://wiki.wireshark.org/SampleCapture
Changes on packet-tacacs.c verified with capture from
http://ccie-in-3-months.blogspot.nl/2009/04/decoding-login-credentials-regardless.html
Change-Id: Iea6ba2bf207cf0f1bf2117068fb1abcfeaafaa46
Link: https://www.wireshark.org/lists/wireshark-dev/201702/msg00011.html
Reviewed-on: https://code.wireshark.org/review/20095
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
|
|
It doesn't need to exist after AirPDcapDecryptWPABroadcastKey() returns.
Change-Id: Ifaf08dfb285be3cf54429f7b77d44565962d4450
Reviewed-on: https://code.wireshark.org/review/12808
Reviewed-by: Guy Harris <guy@alum.mit.edu>
|
|
at the moment, AirPDcapDecryptWPABroadcastKey() does not free the buffer
allocated by AES_unwrap() if there's an error while parsing the returned data
this could be fixed by adding more g_free() calls or by using wmem
memory
Change-Id: I332968da2186fbd17cbb7708082fa701dcab668e
Reviewed-on: https://code.wireshark.org/review/12744
Reviewed-by: Michael Mann <mmann78@netscape.net>
|
|
for cipher_len==56, some bytes of the output array are not written
An alternative approach would be to add a check for cipher_len.
I understand from RFC 3394 that the AES key wrap algorithm works on
multiples of 64bits and has no upper limit, we couldn't easily reject 56
bytes cipher_len.
Bug: 11527
Change-Id: Ie82357bbe5512de391813dd55098df7a16bda9ae
Reviewed-on: https://code.wireshark.org/review/12741
Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
|
|
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>
|
|
This means wsutil now links against libcrypt.
Protect a bunch of the crypt header files from multiple inclusion.
svn path=/trunk/; revision=51100
|
|
svn path=/trunk/; revision=40511
|
|
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
|
|
svn path=/trunk/; revision=26070
|
|
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
|
|
present in the wireshark code
svn path=/trunk/; revision=21429
|
|
according to its pedigree.
svn path=/trunk/; revision=20401
|
|
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
|