9 Jun
2010
9 Jun
'10
2:25 p.m.
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