Hi.
Well perhaps someone then can add KASUMI later on, or even better
perhaps an permission from ETSI could be secured in the future. :D
I do however want to stress that we have labeled UMTS decryption as
"experimental" and thats probably a bit of an understatement,
since we only have one ciphered capture to work with (that one at least
works :D), and the actual configuration of ciphering in UTMS is
surprisingly complex.
And given that KASUMI isn't used in many other applications? Maybe its
better for the moment to try to focus on making RLC and RRC ciphering
configuration (if interests exists)
solid before hassling with kasumi, cause there is alot of work thats
needs to be done, not only configurations but also ways of tracking
single UE and GUI stuff for adding keys for specific UE's...
And currently mine and Rishie time working on the UTRAN dissectors is
running out so we probably wont be able to contribute as much.
But i do agree that its rather interesting that Mitsubishi doesn't seem
to specifiy the actual patent in the documents.
Btw. completly unrelated; How does the wireshark wiki work? should we
update the pages for the protocols that we have changed or how does that
work?
Have a nice friday!
Regards.
Jacob Nordgren
On 08/10/12 00:31, Joerg Mayer wrote:
On Fri, Aug 10, 2012 at 12:26:04AM +0200, Joerg Mayer wrote:
No, as long as it is only included in source form, there should be no problem
(at least the Intel lawyers didn't see a problem with putting patentencumbered
source code into Mesa) as long as this feature is not compiled in by default
but requires a magic configure switch. This puts the burden of verifying the
patent compliance on the person that configures Wireshark with that configure
switch - which is basically the same act as putting the (missing) kasumi source
files into your build tree and changing the #define in kasumi.h
Attached is the git head version of mesa's docs/patents.txt
Ciao
Jörg