[PATCH] Add A5 and GEA ciphers

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/.

Harald Welte laforge at gnumonks.org
Mon Apr 8 12:55:47 UTC 2013


Hi Max,

I agree with Sylvain's comments, but like to add:  The filename should
not be gprs_gea.c but gprs_gea34.c or something along the lines.  There
are other ciphers (gea1/gea2) and that should somehow be reflected in
the file name.

Regarding coding style: We generally open the curly braces on the same
line as  in "for (a;b;c) {".  We also don't indent the "case" statements
in a switch, e.g.:

	switch (foo) {
	case A:
		foo = 1;
		break;
	}

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?

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.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the baseband-devel mailing list