Bastien Baranoff wrote:
> Hello all, the attack : you generate the rainbow tables for each possibles ki
> with a given rand set, send this rand (which is not random ;) the phone
> respond with sres you make the operation for 3 or 4 rand and meaningly
> decrease the possibility of ki. Do you think it is realisable ?
Someone please correct me if I'm wrong on this detail, but it is my
understanding that no mainstream commercial operator today (outside of
personal enthusiast tinkerers in Osmocom and similar communities)
issues native 2G SIM cards any more - instead all of their current SIM
cards are actually USIM/ISIM, and if GSM 11.11 SIM operation is
supported at all, it is only provided as a backward compatibility
mode. I reason that these "modern" SIMs must be using Milenage in
their native 3G/4G mode, thus their secret key material is not classic
Ki, but K/Ki (128 bits) plus OPc (another 128 bits), for a total of
256 bits of secret key material.
What happens when these "modern" SIMs are accessed via GSM 11.11 SIM
protocol, or when 2G authentication is requested in a USIM session?
I find it doubtful that they switch to COMP128 (any version) in this
mode, instead I reason that they use 2G mode of Milenage, which still
uses both K/Ki and OPc - thus the secret key material used even for 2G
Kc and SRES generation from RAND is still 256 bits rather than 128.
Again, someone please correct me if my reasoning is wrong here.
M~
Hi all!
[please follow-up-to the openbsc(a)lists.osmocom.org mailing list, if
there is any discussion, we don't want to drag it over tons of mailing
lists in parallel]
Some weeks ago, I created https://osmocom.org/issues/5397 but it seems nobody
noticed the ticket or had any comments to it.
So let me post this as RFC here on the mailing list:
In the past, we had a gitolite/gitosis setup, which was fine in the
early days of git, but it means that people cannot easily create new
repositories, see who has permissions, and we cannot delegate ownership.
Even updating SSH keys requires manual interaction of a sysadmin like
me.
I would therefore suggest to migrate git.osmocom.org to gitea[1]
This would allow the following features:
* users can self-create any number of personal repositories (like gitlab/github)
* we can create 'organizations' along the line of reasonably independent
osmocom member projects like op25, who can then manage their own
repos/permissions/...
* gitea can link to redmine wiki and redmine issue trackers (rather than
using its own built-in)
For those repositories hosted in gerrit (mainly CNI), we would still
keep git.osmocom.org a read-only mirror, like we do it right now.
For those repositories not hosted in gerrit, users/projects could then
accept merge requests in gitea. Coupling this with 3rd party
authentication via github/gitlab/etc should make it easier for the
occasional contributor to submit changes.
There is a downside, of course; A lot of repo URLs have to change. Most
of our current repositories are at git.osmocom.org/project.git while
gitea follows a git.osmocom.org/organization/project.git scheme. I'm not
sure there is any way to help to mitigate this...
Any thoughts, comments?
[1] https://gitea.io/
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Dear fellow Osmocom developers,
as you all know, we've sadly had to skip OsmoDevCon 2020 and 2021,
trying to compensate it at least to some extent with our OsmoDevCall
every two weeks.
The COVID-19 pandemic is far from over, and we don't know what the
upcoming winter season will bring.
Nevertheless, I think it would be a good idea to start a discussion of
whether we should plan for an OsmoDevCon in 2022.
I personally would say let's plan for the usual late April 2022 time frame,
and if the pandemic situation deteriorates, we can still cancel it with
something like one month lead time.
I would also personally suggest to limit attendance to people who are fully
vaccinated, and in addition do a self-test for all participants every
morning.
In terms of venue, we might also consider to move to a venue that allows better
ventilation. Irrespective of the above we can also bring the air filters from
the sysmocom office.
So with that as an input statement, I would like to hear your opinion
on the above proposals. Who would want to attend? Any complaints against
the "vaccinated only plus daily self-tests in the morning" approach?
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
