Re: Internal key management system

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Internal key management system
Дата
Msg-id CAD2md3H=mVCnm=HiWXHqB6s1N+4huUkV5eGLqjQQWu8jjzntPQ@mail.gmail.com
обсуждение исходный текст
Ответ на Internal key management system  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Список pgsql-hackers
On Tue, 11 Feb 2020 at 09:58, Andres Freund <andres@anarazel.de> wrote:
> Isn't that basically a problem of the past by now?  Partially due to
> changed laws (e.g. France, which used to be a problematic case), but
> also because it's basically futile to have import restrictions on
> cryptography by now. Just about every larger project contains
> significant amounts of cryptographic code and it's entirely impractical
> to operate anything interfacing with network without some form of
> transport encryption.  And just about all open source distribution
> mechanism have stopped separating out crypto code a long time ago.

Australia passed some stunningly backwards crypto laws only quite recently. The Defense Trade Control Act (DCTA) imposes restrictions not only on exporting crypto software, but even on teaching about cryptography without a permit. While supposedly restricted to military items and software, it's rather broad and unclear how that is determined. It's one of those "written broadly, applied selectively, trust us to be nice" laws, because they're NEVER abused, right? See https://www.defence.gov.au/ExportControls/Cryptography.asp .

More recently we passed another idiotic "did you even bother to listen at all to the people who explained this to you" law called the Telecommunications (Assistance and Access) Act. This allows the Government to order companies/organisations to permit "lawful access" to encrypted communication, including end-to-end encrypted communications. It doesn't legislatively order the creation of backdoors, it just legislates that companies must be able to add them on demand, so ... um, it legislates backdoors. The law was drafted quickly, with little consultation, and rammed through Parliament during Christmas with the usual "but the Terrorists" handwaving. (Nevermind that real world terrorist organisations are communicating mainly through videogames chats and other innocuous places, not relying on strong crypto.) The law is already being abused to attack journalists. It has some nasty provisions about what Australia may order employees of a company to do as well, but thankfully the politicians who drafted those provisions did not appear to understand things like revision control or code review, so their real world threat is minimal.

My point? In practice, much of what we do with crypto is subject to a variety of legal questions in many legal jurisdictions. Not much is outright illegal in most places, but it's definitely complicated. I do not participate in anything I know to be illegal or reasonably suspect to be illegal - but with the kind of incredibly broad laws we have now on the books in so many places, talking about the Ceasar Cipher / rot13 could be a violation of someone's crypto law somewhere if you get the wrong judge and the wrong situation.

The main change has been that it got simpler in the US, so enough developers stopped caring. The US's Dep't of Commerce export restrictions were weakened and the set of countries they applied to were narrowed, allowing US companies and citizens the ability to participate in projects containing non-crippled crypto.

There are still plenty of places where any sort of non-backdoored crypto is entirely illegal, we just say "that's your problem" to people in those places.

I wholly support this approach. Pretty much everything is illegal somewhere. Patents are pain enough already.

(Apologies for thread-breaking reply, this is not from my usually-subscribed account. I do not speak in any way for my employer on this matter.)

--
Craig Ringer

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kohei KaiGai
Дата:
Сообщение: PL/Python - lifetime of variables?
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Delaying/avoiding BTreeTupleGetNAtts() call within _bt_compare()