This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
☎ Max.Suraev at fairwaves.ruThank 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