Encryption branch / BSC-MSC split

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/OpenBSC@lists.osmocom.org/.

Sylvain Munaut 246tnt at gmail.com
Wed Jun 9 12:25:14 UTC 2010


Hi,

> I have to check your code.  My idea was to have two tables, one for actual
> keys (ki), and the other one for auth tuples.  The tuples would probably
> need a 'last used' counter, so we can make sure we don't use the most
> recently used tuples again.

I've just made some changes to my code (compiles but not tested yet):
 - I have renamed the table AuthTuples to AuthLastTuples and use it to
store the last used tuple (whatever the algorithm used, either
comp128v1 or xor or ...). This will be useful so that we don't do the
'AUTH' part each time and just re-use the session key a couple of
times before renewing it.
 - In a future commit, I'll add a AuthKnownTuples table and all the
code required to implement a new 'algo_id' that would use only known
tuples. It will have a last_used timestamp and some function to 'pick'
a random one to use.

Trying to do both 'functions' in a single table resulted in a big mess
so I think they're better off splitted.


> So you actually have it in the right file, I was wrong.  Thus, we could
> merge it.  However, this part will nonetheless probably change a lot
> once we make the split...

Really ? In the end, it just sends messages so I would think that as
holger said, only the gsm48_sendmsg will be replaced with
bsc_dtap_send or something.

I think the async HLR change will have much more impact.


I'll test my updated code tonight and push it to my encryption if it
doesn't break.


    Sylvain




More information about the OpenBSC mailing list