Wireshark mailing list archives
Re: snow3g dissector in violation of GPLv2+
From: Martin Mathieson <martin.r.mathieson () googlemail com>
Date: Thu, 16 Jan 2014 09:54:48 +0000
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 () loplof de> 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 () gmail com>wrote:I don't know if it matters or not (as I'm not a lawyer and barely knowanything 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, forwhich 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 papercopies 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 3GPPConfidentiality 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 maybe 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 papercopies 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 () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe -- Joerg Mayer <jmayer () loplof de> 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 () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- snow3g dissector in violation of GPLv2+ Joerg Mayer (Jan 15)
- Re: snow3g dissector in violation of GPLv2+ ronnie sahlberg (Jan 15)
- Re: snow3g dissector in violation of GPLv2+ Pascal Quantin (Jan 15)
- Re: snow3g dissector in violation of GPLv2+ Guy Harris (Jan 15)
- Re: snow3g dissector in violation of GPLv2+ Joerg Mayer (Jan 15)
- Re: snow3g dissector in violation of GPLv2+ Martin Mathieson (Jan 16)
- Re: snow3g dissector in violation of GPLv2+ Joerg Mayer (Jan 16)
- Re: snow3g dissector in violation of GPLv2+ Martin Mathieson (Jan 16)
- Re: snow3g dissector in violation of GPLv2+ Joerg Mayer (Jan 16)
- Re: snow3g dissector in violation of GPLv2+ Guy Harris (Jan 15)