Wireshark mailing list archives
ws_base32_decode should be named *_encode and seems non standard
From: Antoine d'Otreppe <a.dotreppe () aspyct org>
Date: Thu, 29 Nov 2018 18:22:21 +0000
Hi all, Something about the ws_base32_decode function looks weird, and I'm a little confused. Can I please have a sanity check? 2 things: 1. ws_base32_decode is actually an encode 2. it's not the standard base32 as defined in RFC4648 Let me explain. 1. It's actually an encode The function is used only in one place in wireshark, in packet-fc00.c Looking at the git history reveals that the function initially lived within that dissector, and was called `Base32_encode`. See commit 26e883a75c37e18f633e47dcd85e2648ee1f03ae Also, the function is used by the dissector (line 139) to convert a byte array into a char array. That fits the definition of encode in most languages. 2. it's not the standard RFC4648 I tried the function, and it doesn't seem to have the same output as other base32 encoders. With python 3.7.1: helloworld -> NBSWY3DPO5XXE3DE On some encoder online: helloworld -> NBSWY3DPO5XXE3DE With ws_base32_decode: helloworld -> ILZYGW5NX33EHWRM It's also not using the same alphabet as python, so for the sake of the test I modified the code to have the same alphabet. In packet-fc00.c, there's a comment line indicating `Cjdns style base32 encoding` My guess is that this encoding was specific to the cjdns/fc00 protocol. Can anyone validate, or invalidate, this reasoning? If that's correct, should I put this function back into the fc00 dissector and replace it with a standard version of base32 as described in RFC4648? https://tools.ietf.org/html/rfc4648#page-8
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- ws_base32_decode should be named *_encode and seems non standard Antoine d'Otreppe (Nov 29)