Ask Your Question

Decode SNMPv3 fails

asked 2024-07-05 06:59:55 +0000

Gargamel gravatar image

updated 2024-07-06 07:28:18 +0000


Wireshark Version 4.2.5 (v4.2.5-0-g4aa814ac25a1)

I have configured a working SNMPv3 connection. So I know the encryption settings and I have already done several other decryptions with Wireshark before. But in this case I always get "Decrypted data not formatted as expected, wrong key?". As mentioned I have configured this SNMPv3 connection by myself and know the parameters I have configured very well and the connection is working with this parameters. Is there an issue in Wireshark with decryption of SHA1 and AES256 PDUs?

Example output with tshark in Linux (but GUI looks the same):

tshark -r /tmp/test.pcap -o 'uat:snmp_users:"","snmpnbuser","SHA1","Arthur_123","AES256","Arthur_123"' | more
Running as user "root" and group "root". This could be dangerous.
    1   0.000000 → SNMP 830 encryptedPDU: Decrypted data not formatted as expected
    2   0.000105 → SNMP 830 16604 → 162 Len=788
    3   0.000157 → SNMP 831 16604 → 162 Len=789
    4   0.000203 → SNMP 831 encryptedPDU: Decrypted data not formatted as expected
    5   0.000246 → SNMP 831 encryptedPDU: Decrypted data not formatted as expected
    6   0.000289 → SNMP 831 encryptedPDU: Decrypted data not formatted as expected
    7   1.051979 → SNMP 827 encryptedPDU: Decrypted data not formatted as expected
    8   1.052081 → SNMP 827 encryptedPDU: Decrypted data not formatted as expected
    9   1.052126 → SNMP 675 encryptedPDU: Decrypted data not formatted as expected
   10   1.052174 → SNMP 717 16604 → 162 Len=675
   11   1.052214 → SNMP 695 encryptedPDU: Decrypted data not formatted as expected
   12   8.062186 → SNMP 830 encryptedPDU: Decrypted data not formatted as expected

Example PCAP file:

Encryption parameters are the same as in the tshark command above.



edit retag flag offensive close merge delete


Hi I did some additional testing and changed passwords and auth protocol and priv protocol. The problem seems to be related to the priv protocol AES256. AES128(AES) seems to work. Unfortunately I can't change this settings in the other system as to many external systems would be affected. Any suggestions? BR, Michael

Gargamel gravatar imageGargamel ( 2024-07-05 08:53:19 +0000 )edit

Please add the output of tshark -v to the question.

Chuckc gravatar imageChuckc ( 2024-07-05 10:47:06 +0000 )edit

Added Version 4.2.5 (v4.2.5-0-g4aa814ac25a1) to the question as requested.

Gargamel gravatar imageGargamel ( 2024-07-05 13:42:57 +0000 )edit

16381: SNMP: Allow for key expansion algorithm selection has been merged.
Available for testing from automated builds.
For Windows, look for Wireshark-4.3.0rc1-437-gad804dac7f8c-x64.exe or later.
Update SNMP users by changing the additional column: Key expansion method to AGENT++.

Chuckc gravatar imageChuckc ( 2024-07-11 13:33:10 +0000 )edit

2 Answers

Sort by » oldest newest most voted

answered 2024-07-09 11:41:36 +0000

Chuckc gravatar image

(Adding as additional answer so these links don't get lost down in "more comments")
Analysis of the capture file resulted in two items to look at:
19916: SNMP AES192/AES256 key expansion supports only single expansion algorithm

snmp4j: EngineID doesn’t match RFC3411

edit flag offensive delete link more


Hi I'm no programmer so it's not so easy to answer. We are using JBI and I guess Servicemix SNMP. I couldn't find too much documents about it as I'm not in our R&D department.



Gargamel gravatar imageGargamel ( 2024-07-10 06:48:16 +0000 )edit

answered 2024-07-05 13:23:11 +0000

Jaap gravatar image

SHA1 doesn't provide enough key bits for AES256, so key extension needs to be applied. This isn't standardised, however there's draft-reeder-snmpv3-usm-3desede-00 which goes into this. Wireshark seems to be doing that in the SNMP dissector, although I'm not sure if it exactly follows the algorithm in section 2.1 of this draft. It seems to use "K1 | K2" rather than "K2" in the third round, "K1 | K2 | K3" rather than "K3" in the fourth round, etc. Unfortunately I've no setup to dive into this.

edit flag offensive delete link more


Unfortunately I don't have enough points to upload PCAP file. BR, Michael

Gargamel gravatar imageGargamel ( 2024-07-05 13:46:25 +0000 )edit

Place it on a public file share (Dropbox, Microsoft, Google, ...) then update the question with a link to it.

Chuckc gravatar imageChuckc ( 2024-07-05 13:59:01 +0000 )edit

Added link to to the question.

Gargamel gravatar imageGargamel ( 2024-07-06 07:30:36 +0000 )edit

Few observations from the capture file.

  1. The SNMP software appears to be Agent++, that could help to get an insight. Strangely enough the AuthoritativeEngineId encoding is incorrect. Does not appear to impact authentication though.
  2. Even though key extension is necessary, for the applicable key sizes, the current implementation in the dissector has to do one round, which performs correctly. It's subsequent rounds that do not follow the draft-reeder-snmpv3-usm-3desede-00 method. It would take a closer look at the Agent++ code to see how they do key extension (PrivAES::extend_short_key) to see if/how this matches.
Jaap gravatar imageJaap ( 2024-07-06 14:01:47 +0000 )edit
    00.. .... = Class: UNIVERSAL (0)
    ..0. .... = P/C: Primitive Encoding
    ...0 0100 = Tag: OCTET STRING (4)
    Length: 13
    msgAuthoritativeEngineID: 80001370010a59fd10a8e7de2c
        1... .... = Engine ID Conformance: RFC3411 (SNMPv3)
        Engine Enterprise ID: AGENT++ (4976)
        Engine ID Format: IPv4 address (1)
        Data not conforming to RFC3411
            [Expert Info (Warning/Protocol): Data not conforming to RFC3411]
                [Data not conforming to RFC3411]
                [Severity level: Warning]
                [Group: Protocol]

80001370    = AGENT++ (4976)
01          = IPv4 address (1)
0a 59 fd 10 =
a8e7de2c    = timestamp ???


                    The fifth octet indicates how the rest (6th and
                    following octets) are formatted. The values for
                    the fifth octet are:

                      0     - reserved, unused.

                      1     - IPv4 address (4 octets)
                              lowest non-special IP address


    /* 4-byte IPv4 address */
    if (len_remain==4) {
        proto_tree_add_item(tree, hf_snmp_engineid_ipv4, tvb, offset, 4, ENC_BIG_ENDIAN);

If they have added a timestamp? or other value, it should be (fifth octet):

                    128-255 - as ...
Chuckc gravatar imageChuckc ( 2024-07-06 14:40:40 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2024-07-05 06:59:55 +0000

Seen: 99 times

Last updated: Jul 10