I tested the reserved COMP128v23 code from www.hackingprojects.net the values in the python file match the ones outputed by the sysmoSIM-GR1 (which also supports COMP128 v2 and v3) so I implemented it in C, and added it to libosmocore I then checked the output from osmo-auc-gen again the values provided also the python code and all values matched
Here are te patched WARNING: I also renamed COMP128 to COMP128v1, but don't know if this breaks any compatibility with other projects
kevin
Hi Kevin,
On Sat, Nov 02, 2013 at 07:02:12PM +0100, Kevin Redon wrote:
I tested the reserved COMP128v23 code from www.hackingprojects.net
Thanks, I didn't even know that there was now a publicly-documented, publicly-leaked vresion of COMP128v2/v3 available. This of course means that nobody can claim the algorithm is a trade secret anymore, and thus I don't see problems with us implementing it in libosmocore for subsequent use in other osmocom projects like osmo-nitb, etc.
I then checked the output from osmo-auc-gen again the values provided also the python code and all values matched
thanks!
WARNING: I also renamed COMP128 to COMP128v1, but don't know if this breaks any compatibility with other projects
Exactly to avoid that, I would simply skip it. I know it's sort-of strange that comp128 refers to v1 without explicitly stating it, but I think for the sake of simplicitly we should keep it.
Finally, I hope somebody will have enough reason of porting osmo-nitb over to the generic osmo_auth API in libosmocore, rather than calling the comp128[v1] algorithm directly. At that point, COMP128v2/v3 as well as milenage support will come more or less automagically.
Afer that, we could probably resort to not exporting the comp128() functions directly anymore, but require all users to go through the osmo_auth_* API.
Regards, Harald
Hi,
WARNING: I also renamed COMP128 to COMP128v1, but don't know if this breaks any compatibility with other projects
Exactly to avoid that, I would simply skip it. I know it's sort-of strange that comp128 refers to v1 without explicitly stating it, but I think for the sake of simplicitly we should keep it.
We could also use a weak alias and mark it as deprecated like we did for some of the hexdump function.
Cheers,
Sylvain
I've now merged your patches, except the re-name. I squashed all in one, there's no point in having 7 commits for one single feature addition.
Regards,
On Sun, Nov 03, 2013 at 03:09:42PM +0100, Harald Welte wrote:
I've now merged your patches, except the re-name. I squashed all in one, there's no point in having 7 commits for one single feature addition.
I started to use "#pragma once" in my own header files and the PCU. This feature was introduced in gcc 3.4 (released in 2004). I would like to use it in future header files everywhere.
comments?
holger
Hi Holger,
On Sun, Nov 03, 2013 at 06:49:45PM +0100, Holger Hans Peter Freyther wrote:
I started to use "#pragma once" in my own header files and the PCU. This feature was introduced in gcc 3.4 (released in 2004). I would like to use it in future header files everywhere.
I don't see any problems, but then the gain from three fairly simple lines to one line is not really all that big.
Hi,
On Sun, Nov 03, 2013 at 06:49:45PM +0100, Holger Hans Peter Freyther wrote:
I started to use "#pragma once" in my own header files and the PCU. This feature was introduced in gcc 3.4 (released in 2004). I would like to use it in future header files everywhere.
I don't see any problems, but then the gain from three fairly simple lines to one line is not really all that big.
What about other compilers ?
I'm thinking on particular of people building part of it on Windows ? (VCC is pretty much out already but what about ICC ?)
Cheers,
Sylvain
baseband-devel@lists.osmocom.org
-
Harald Welte -
Holger Hans Peter Freyther -
Kevin Redon -
Sylvain Munaut