Feature #2562
closedKI with varying lengths
0%
Description
According to openbsc/gsm_data_shared.h, there is an
#define A38_XOR_MIN_KEY_LEN 12 #define A38_XOR_MAX_KEY_LEN 16
but there is no concept of varying key lengths in osmo-hlr. For 2G, there is the 128bit KI and that's it:
In struct osmo_sub_auth_data we have only the uint8_t ki[OSMO_A5_MAX_KEY_LEN_BYTES] in .gsm.
In OsmoNITB, we allow to pass a shorter KI for the VTY command
subscriber imsi 123456 a3a8 xor 123456789abc123456789abc
and in the old struct gsm_auth_info we store an a3a8_ki_len, which gets populated from the binary length found in the db.
Adding VTY commands to osmo-hlr, the question is whether we should simply require a KI of 128bit and be done with it.
Otherwise we need to adjust libosmocore's struct osmo_sub_auth_data to indicate a ki_len.
And should probably add regression tests with varying KI lengths for XOR.
Updated by neels over 6 years ago
- Status changed from New to Feedback
- Assignee set to laforge
Updated by laforge over 6 years ago
On Mon, Oct 09, 2017 at 03:23:21PM +0000, neels [REDMINE] wrote:
According to openbsc/gsm_data_shared.h, there is an
#define A38_XOR_MIN_KEY_LEN 12
#define A38_XOR_MAX_KEY_LEN 16
The question is: where does this come from? Is there some spec referefence
for this? In general my gut feeling is we don't have to care.
Updated by laforge over 6 years ago
- Status changed from Feedback to New
- Assignee changed from laforge to neels
Updated by neels over 6 years ago
- Status changed from New to Rejected
Let's reject for now, if anyone requests varying lengths we may come back to this.