5 Dec
2012
5 Dec
'12
7:36 p.m.
Hello.
Attached patch will bring a5/3 support to osmo_a5. The implementatin is done based on
spec, results are compared to reference implementation from standard and test vectors.
Unfortunately there are several deficiencies:
- it doesn't work with real phonein test network yet
- no tests included
- code is probably suboptimal here and there
Anyway I would love to read your comments. It would be especially great if someone
will manage to test it against real phones in actual network.
--
best regards,
Max, http://fairwaves.ru
6 Dec
6 Dec
7:24 a.m.
Attached patch will bring a5/3 support to osmo_a5. The
implementatin is done based on
spec, results are compared to reference implementation from standard and test vectors.
Unfortunately there are several deficiencies:
- it doesn't work with real phonein test network yet
Maybe you need to accept the 8 byte of the key in the inverse order.
There is always a mixup there because different spec refer to the key
in different order and n osmo_a5() we want the key in the same order
as we received from the SIM.
- no tests included
Addind a test vector to ../../tests/a5/a5_test.c should be trivial.
That test is far from exhaustive but it does show gross errors.
Anyway I would love to read your comments. It would be
especially great if someone
will manage to test it against real phones in actual network.
I think it'd be useful to split the kasumi impl in its own file, so
that we can use it to implement GEA3 GPRS cipher as well.
Also, use TAB for indentation, that's the proper style in osmocom
projects. (basically the kernek coding style).
I extracted and merged the return -ENOTSUP part of this patch.
Cheers,
Sylvain
10:43 a.m.
On Thu, Dec 06, 2012 at 08:24:23AM +0100, Sylvain Munaut wrote:
I think it'd be useful to split the kasumi impl in
its own file, so
that we can use it to implement GEA3 GPRS cipher as well.
please note that there is already a libosmo-crypt-a53
(http://cgit.osmocom.org/cgit/libosmo-crypt-a53) which implements A5/3
and GEA3. However, it's based on the reference code, which may be
problematic to distribute.
I belive Erik Tews was working on a clean re-implementation without
copyrighted reference code, but I'm not sure what was the result of it
(maybe I don't remember)
There
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
1:11 p.m.
06.12.2012 11:43, Harald Welte пишет:
--
best regards,
Max, http://fairwaves.ru
On Thu, Dec 06, 2012 at 08:24:23AM +0100, Sylvain
Munaut wrote:
> I think it'd be useful to split the kasumi impl in its own file, so
> that we can use it to implement GEA3 GPRS cipher as well.
I'd do that in
2nd version of a patch: both Kasumi and KGcore functions are shared so
it make sense.
please note that there is already a libosmo-crypt-a53
(http://cgit.osmocom.org/cgit/libosmo-crypt-a53) which implements A5/3
and GEA3. However, it's based on the reference code, which may be
problematic to distribute.
Awesome, I can use it for easier testing :)
Is there build instructions somewhere? Has it bean tested against actual phones?
1:41 p.m.
Hi,
Also, please put any internal method as 'static' so we can avoid
polluting the namespace.
It's automake ...
I think GEA3 has been tested, but not A5/3. It's doesn't even
integrate with the osmo_a5(...) functions.
GPRS cipher and Auth use a sort of plugin system, mostly because the
algorithm used in there are still secret and so implementation is
sometime provided by external devices / libraries / processes. For the
A5/x ciphers, they're all public so they use direct linking and not a
dynamic plugin system.
Cheers,
Sylvain
> I think
it'd be useful to split the kasumi impl in its own file, so
> that we can use it to implement GEA3 GPRS cipher as well.
I'd do that in
2nd version of a patch: both Kasumi and KGcore functions are shared so
it make sense. please note
that there is already a libosmo-crypt-a53
(http://cgit.osmocom.org/cgit/libosmo-crypt-a53) which implements A5/3
and GEA3. However, it's based on the reference code, which may be
problematic to distribute.
Awesome, I can use it for easier testing :)
Is there build instructions somewhere? Has it bean tested against actual phones?
4:38 p.m.
06.12.2012 14:41, Sylvain Munaut пишет:
Hi,
Also, please put any internal method as 'static' so we can avoid
polluting the namespace.
Done.
I still didn't managed to make it work with phones but now patch is split into
logical parts so I hope at least some of the code will be useful.
I've tried to compile libosmo-crypt-a53 but got multitude of errors like:
configure.in:5: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:15: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.in:35: error: possibly undefined macro: AM_CONFIG_HEADER
and
./configure
day 341, Четверг 0\0\
./configure: line 1979: syntax error near unexpected token `dist-bzip2'
./configure: line 1979: `AM_INIT_AUTOMAKE(dist-bzip2)'
Anyway, this is exactly version from standards against which I've already tested
mine. I do not want to add any test vectors until I make the code compatible with
real phones.
--
best regards,
Max, http://fairwaves.ru
> I
think it'd be useful to split the kasumi impl in its own file, so
> that we can use it to implement GEA3 GPRS cipher as well.
I'd do that in
2nd version of a patch: both Kasumi and KGcore functions are shared so
it make sense. 
2:06 p.m.
Am Donnerstag, den 06.12.2012, 11:43 +0100 schrieb Harald Welte:
I belive Erik Tews was working on a clean re-implementation without
copyrighted reference code, but I'm not sure what was the result of it
(maybe I don't remember)
Hi
Yes, a student started working on the project. However, unfortunately
just before she was about to finish, a colleague decided to change the
schedule and she had to speed up her work. As a result, I would not
reconment to use the code. Also I should add, I wasn't ever able to use
the code by myself :-(
4:39 p.m.
06.12.2012 15:06, Erik Tews пишет:
Am Donnerstag, den 06.12.2012, 11:43 +0100 schrieb
Harald Welte:
Do you know any details about test setup used for this code? I'm still puzzled why
I'm unable to make it work in real networks so any advices would be greatly
appreciated.
--
best regards,
Max, http://fairwaves.ru
I belive Erik Tews was working on a clean
re-implementation without
copyrighted reference code, but I'm not sure what was the result of it
(maybe I don't remember)
Hi
Yes, a student started working on the project. However, unfortunately
just before she was about to finish, a colleague decided to change the
schedule and she had to speed up her work. As a result, I would not
reconment to use the code. Also I should add, I wasn't ever able to use
the code by myself :-(
4:53 p.m.
06.12.2012 17:43, Sylvain Munaut пишет:
Yes, result is still wrong :(
Either I'm doing it wrong or there's smth else which got to be swapped... or some
other bugs lurking in shadows :)
--
best regards,
Max, http://fairwaves.ru
Do you know
any details about test setup used for this code? I'm still puzzled why
I'm unable to make it work in real networks so any advices would be greatly
appreciated.
Did you try to swap the byte order of the key like I originally
suggested ?
7 Dec
7 Dec
11:45 p.m.
When testing A5/3 one should be wary of using Samsung phones, from what
I hear they have shipped models with broken A5/3 support, something
which has in turn caused delays for operators wishing to roll out A5/3.
The core network components have to resort to IMEI filtering to work
around these incompatibilities.
f
On Wed, 2012-12-05 at 20:36 +0100, ☎ wrote:
Hello.
Attached patch will bring a5/3 support to osmo_a5...
Unfortunately there are several deficiencies:
- it doesn't work with real phonein test network yet
8 Dec
8 Dec
1:36 p.m.
08.12.2012 00:45, Frank A. Stevenson пишет:
When testing A5/3 one should be wary of using Samsung
phones, from what
I hear they have shipped models with broken A5/3 support, something
which has in turn caused delays for operators wishing to roll out A5/3.
The core network components have to resort to IMEI filtering to work
around these incompatibilities.
Are there list of affected models somewhere?
Or list of phones known to work reliable with a5/3 (everything except samsung)?
--
best regards,
Max, http://fairwaves.ru
4218
days inactive
4221
days old
baseband-devel@lists.osmocom.org
11 comments
5 participants
participants (5)
-
Erik Tews -
Frank A. Stevenson -
Harald Welte -
Sylvain Munaut -
☎