[PATCH] Add A5 and GEA ciphers

Max.Suraev at fairwaves.ru
Mon Apr 8 14:20:19 UTC 2013

Thank you for review, comments are inline, rewrite in progress :)

08.04.2013 14:55, Harald Welte пишет:
> I'm also not sure if the gea3/gea4 should become part of libosmogsm
> itself, or if they should simply exist in the form of a
> libosmo-crypt-gea34 or the like.  Actually, I once created such a
> library (plugging into gprs_cipher_register()) using the reference
> implementation of the cipher.  I'm not 100% sure on this, though.  Does
> anyone have an opinion on this?

I think that they should because they are based on exactly the same kgcore primitive
used by a5/3,4.
Also I've tried to add register call (see gprs_gea.c) but when I call
gprs_cipher_supported(GPRS_ALGO_GEA3) in gea_test.c it returns 0. How can I test that
gea3 registered properly and is available via plugin interface?

Also, how should we change gprs_auth plugin api so it would work for 128 bit keys
(GEA4)? Just change uint64_t to uint8_t or there's more to it?

> Even if it gea3/gea4 becomes part of libosmogsm, then I would like to
> have no direct functions exported to applications, but require
> applications to go through the gprs_cipher_* API.  The same holds true
> for the A5/* family.  Rather than having explicit function calls for
> each of the variants, I would love to have one set of functions with
> just a parameter or struct member defining the specific algorithm to be
> used by the implementation.

I completely agree about hiding implementation of particular algorithms although I
think that gea* belongs in libosmogsm - just like milenage and comp128 which re also
supposed to be used via plugin api.

Is it enough to just remove function names from libosmogsm.map or there got to be
"deeper" hiding?

best regards,
Max, http://fairwaves.ru

More information about the baseband-devel mailing list