From: Marc Gonzalez <marc.w.gonzalez@free.fr>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: France didn't want GSM encryption
Date: Mon, 30 Sep 2019 13:14:24 +0200 [thread overview]
Message-ID: <3e5347a2-9aa7-bffb-2343-42eda87a6c83@free.fr> (raw)
In-Reply-To: <CAHk-=wj9BSMzoDD31R-ymjGpkpt0u-ndX6+p0ZWsrJFDTAN+zg@mail.gmail.com>
[ Trimming recipients list ]
On 27/09/2019 18:23, Linus Torvalds wrote:
> It's not the crypto engine that is part of the untrusted hardware.
> It's the box itself, and the manufacturer, and you having to trust
> that the manufacturer didn't set up some magic knocking sequence to
> disable the encryption.
>
> Maybe the company that makes them is trying to do a good job. But
> maybe they are based in a country that has laws that require
> backdoors.
>
> Say, France. There's a long long history of that kind of thing.
>
> It's all to "fight terrorism", but hey, a little industrial espionage
> is good too, isn't it? So let's just disable GSM encryption based on
> geographic locale and local regulation, shall we.
>
> Yeah, yeah, GSM encryption wasn't all that strong to begin with, but
> it was apparently strong enough that France didn't want it.
Two statements above have raised at least one of my eyebrows.
1) France has laws that require backdoors.
2) France did not want GSM encryption.
The following article claims that it was the British who demanded that
A5/1 be weakened (not the algorithm, just the key size; which is what
the USgov did in the 90s).
https://www.aftenposten.no/verden/i/Olkl/Sources-We-were-pressured-to-weaken-the-mobile-security-in-the-80s
Additional references for myself
https://lwn.net/Articles/368861/
https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States
https://gsmmap.org/assets/pdfs/gsmmap.org-country_report-France-2017-06.pdf
https://gsmmap.org/assets/pdfs/gsmmap.org-country_report-France-2018-06.pdf
https://gsmmap.org/assets/pdfs/gsmmap.org-country_report-France-2019-08.pdf
As for your first claim, can you provide more information, so that I could
locate the law(s) in question? (Year the law was discussed, for example.)
I've seen a few propositions ("projet de loi") but none(?) have made it into
actual law, as far as I'm aware.
https://www.nextinpact.com/news/98039-loi-numerique-nkm-veut-backdoor-dans-chaque-materiel.htm
https://www.nextinpact.com/news/107546-lamendement-anti-huawei-porte-pour-backdoors-renseignement-francais.htm
Regards.
next prev parent reply other threads:[~2019-09-30 11:14 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-25 16:12 [RFC PATCH 00/18] crypto: wireguard using the existing crypto API Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 01/18] crypto: shash - add plumbing for operating on scatterlists Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 02/18] crypto: x86/poly1305 - implement .update_from_sg method Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 03/18] crypto: arm/poly1305 - incorporate OpenSSL/CRYPTOGAMS NEON implementation Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 04/18] crypto: arm64/poly1305 " Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 05/18] crypto: chacha - move existing library code into lib/crypto Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 06/18] crypto: rfc7539 - switch to shash for Poly1305 Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 07/18] crypto: rfc7539 - use zero reqsize for sync instantiations without alignmask Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 08/18] crypto: testmgr - add a chacha20poly1305 test case Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 09/18] crypto: poly1305 - move core algorithm into lib/crypto Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 10/18] crypto: poly1305 - add init/update/final library routines Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 11/18] int128: move __uint128_t compiler test to Kconfig Ard Biesheuvel
2019-09-25 21:01 ` Linus Torvalds
2019-09-25 21:19 ` Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 12/18] crypto: BLAKE2s - generic C library implementation and selftest Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 13/18] crypto: Curve25519 - generic C library implementations " Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 14/18] crypto: chacha20poly1305 - import construction and selftest from Zinc Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 15/18] net: WireGuard secure network tunnel Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 16/18] netlink: use new strict length types in policy for 5.2 Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 17/18] wg switch to lib/crypto algos Ard Biesheuvel
2019-09-25 16:12 ` [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption Ard Biesheuvel
2019-09-25 22:15 ` Linus Torvalds
2019-09-25 22:22 ` Linus Torvalds
2019-09-26 9:40 ` Pascal Van Leeuwen
2019-09-26 16:35 ` Linus Torvalds
2019-09-27 0:15 ` Pascal Van Leeuwen
2019-09-27 1:30 ` Linus Torvalds
2019-09-27 2:54 ` Linus Torvalds
2019-09-27 3:53 ` Herbert Xu
2019-09-27 4:37 ` Andy Lutomirski
2019-09-27 4:59 ` Herbert Xu
2019-09-27 4:01 ` Herbert Xu
2019-09-27 4:13 ` Linus Torvalds
2019-09-27 10:44 ` Pascal Van Leeuwen
2019-09-27 11:08 ` Pascal Van Leeuwen
2019-09-27 4:36 ` Andy Lutomirski
2019-09-27 9:58 ` Pascal Van Leeuwen
2019-09-27 10:11 ` Herbert Xu
2019-09-27 16:23 ` Linus Torvalds
2019-09-30 11:14 ` Marc Gonzalez [this message]
2019-09-30 21:37 ` France didn't want GSM encryption Linus Torvalds
2019-09-30 20:44 ` [RFC PATCH 18/18] net: wireguard - switch to crypto API for packet encryption Pascal Van Leeuwen
2019-09-27 2:06 ` Linus Torvalds
2019-09-27 10:11 ` Pascal Van Leeuwen
2019-09-26 11:06 ` Ard Biesheuvel
2019-09-26 12:34 ` Ard Biesheuvel
2019-09-26 8:59 ` [RFC PATCH 00/18] crypto: wireguard using the existing crypto API Jason A. Donenfeld
2019-09-26 10:19 ` Pascal Van Leeuwen
2019-09-26 10:59 ` Jason A. Donenfeld
2019-09-26 11:06 ` chapoly acceleration hardware [Was: Re: [RFC PATCH 00/18] crypto: wireguard using the existing crypto API] Jason A. Donenfeld
2019-09-26 11:38 ` Toke Høiland-Jørgensen
2019-09-26 13:52 ` Pascal Van Leeuwen
2019-09-26 23:13 ` Dave Taht
2019-09-27 12:18 ` Pascal Van Leeuwen
2019-09-26 22:47 ` Jakub Kicinski
2019-09-26 12:07 ` [RFC PATCH 00/18] crypto: wireguard using the existing crypto API Ard Biesheuvel
2019-09-26 13:06 ` Pascal Van Leeuwen
2019-09-26 13:15 ` Ard Biesheuvel
2019-09-26 14:03 ` Pascal Van Leeuwen
2019-09-26 14:52 ` Ard Biesheuvel
2019-09-26 15:04 ` Pascal Van Leeuwen
2019-09-26 20:47 ` Jason A. Donenfeld
2019-09-26 21:22 ` Andrew Lunn
2019-09-26 21:36 ` Andy Lutomirski
2019-09-27 7:20 ` Jason A. Donenfeld
2019-10-01 8:56 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e5347a2-9aa7-bffb-2343-42eda87a6c83@free.fr \
--to=marc.w.gonzalez@free.fr \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=pvanleeuwen@verimatrix.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).