[Martin Mathieson <martin.r.mathieson@xxxxxxxxxxxxxx>]

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

On Wed, Jan 15, 2014 at 11:56 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:

Well, as long as the documentation at
http://www.gsmworld.com/technicalprojects/wp-content/uploads/2012/04/snow3gspec.doc
is sufficient to do an actual implementation, it shouldn't be too hard to write the
necessary code with a GPLv2+ compatible license - the actual spec is very short
(6 pages).

Ciao
    Jörg

On Wed, Jan 15, 2014 at 03:32:43PM -0800, Guy Harris wrote:
>
> On Jan 15, 2014, at 3:17 PM, Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:
>
> > I don't know if it matters or not (as I'm not a lawyer and barely know anything about GPLv2 requirements) but the algorithm source code is available from here: http://www.gsma.com/technicalprojects/fraud-security/security-algorithms
>
> ...under terms that probably aren't GPL compatible.
>
> 3GPP Confidentiality and Integrity Algorithms 128-EEA3 & 128-EIA3
>
>       ...
>
> Individuals or companies intending to implement and/or use the 128-EEA3 & 128-EIA3 Algorithms will be required to sign a Restricted Usage Undertaking with an appointed custodian, such as the GSM Association. Commercial implementors of the algorithms will need to demonstrate that they satisfy approval criteria specified in the Restricted Usage Undertaking and formal permission to use the algorithms will need to be obtained by way of signing the Restricted Usage Undertaking and paying the EUR4,000 administrative charges that applies to non-members of the GSMA.
>
> The 128-EEA3 & 128-EIA3 algorithms are based on the ZUC algorithm, for which the DCS Centre holds essential patents. Beneficiaries of the 128-EEA3 & 128-EIA3 algorithms must also be licensed by DACAS. DACAS grants royalty-free licenses under those patents under separate written license agreements and subject to other terms and conditions which are believed fair and commercially reasonable. DACAS reserves the right to refuse or withdraw the license to/from the parties that refuse to license, or claim unfair, unreasonable or discriminatory royalty rates for their essential IPR. Implementors can apply for the ZUC patent license here.
>
>       ...
>
> Every Beneficiary must send to the GSM Association two signed paper copies of the Restricted Usage Undertaking – one copy will be countersigned and returned. Non-GSM Association members must also enclose the Administrative Charge of € 4,000.
>
> 3GPP Confidentiality and Integrity Algorithms UEA2 and UIA2
> The GSMA , having cooperated in the development of the 3GPP Confidentiality and Integrity Algorithms UEA2 and UIA2 ("The UEA2 & UIA2 Algorithm"), has been granted distribution rights to the Algorithms that have been developed through the collaborative efforts of the 3GPP Organisational Partners.
>
> The UEA2 and UIA2 Algorithm specifications are available below and may be used only for the development and operation of equipment conforming to the UEA2 & UIA2 Algorithm or standards based on it. Every Beneficiary intending to implement and/or use the UEA2 & UIA2 Algorithm must sign a Restricted Usage Undertaking with a Custodian and demonstrate that they satisfy the approval criteria specified in the Restricted Usage Undertaking. A fee of EUR4,000 is chargeable to non-members of the GSMA  wishing to implement and/or use the UEA2 and UIA2 Algorithm.
>
>       ...
>
> Every Beneficiary must send to the GSM Association two signed paper copies of the Restricted Usage Undertaking – one copy will be countersigned and returned. Non-GSM Association members must also enclose the Administrative Charge of € 4,000.
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe