Re-reading the terms quoted by Guy, my impression is that its the algorithm rather than the reference implementation that the administrative charge gives an organisation access to, so re-implementing would not help.
There are multiple algorithms for ciphering and integrity (currently 3), which all take the same inputs. Those inputs are all available to the PDCP dissector, and we are allowed to call AES, so I did the reworking that was needed to make it convenient to call other algorithms. I work for an organisation that creates equipment conforming to those algorithms (and presumably has paid the charge), so assumed that it was OK to call the algorithm internally within the development group I work in. So far I haven't shared it with anyone at all.
At the top of packet-pdcp-lte.c, I added the following:
/* Define this symbol if you have a working implementation of SNOW3G f8() and f9() available */
#define HAVE_SNOW3G
#ifdef HAVE_SNOW3G
#include <epan/snow3g_algorithm.h>
#endif
Probably the #include line was a mistake - this file is not part of Wireshark but the path does imply this. The prototypes of f8() and f9() are pretty standard, but I did this rather than extern'ing snow3g versions of these functions. I am happy to delete that line in the checked-in version and maintain a bigger diff on my own machine.
I also checked in the calls to snow3g_f8() and snow3g_f9(), with the same argument order + meaning as the reference implementation. As I said above, the f8/f9 interface is fairly standard, and all of the inputs are described in not-restricted specs. If the concensus is that this can't be included I will delete those calls too, and replace them with a comment. If even this is too much I can revert everything related to snow3g, I don't need the grief.
I did in the past try to determine if it could be permitted for Wireshark to use the implementation, but received no answer.
Martin
