PKC 2024

April 15-17, 2024

Sydney, Australia

Australian crypto export restrictions

A short summary by Vanessa Teague

Australia is renowned for sunny beaches, unique wildlife, and idiotic encryption export restrictions. We hope you enjoy your visit, but we don't want it to be compulsorily extended beyond your chosen departure date, so please read on.

The following is my uneducated personal interpretation. I am not a lawyer, and although I have been reading these rules carefully for a long time, there may be various things I missed or misunderstood. Please interpret this advice as a best-effort guide from a non-expert, not any kind of reliable legal advice.

What communications are prohibited?

Australia's Defence Export Controls Act prohibits the supply of DSGL technology to another person if

  1. the supply is from a place in Australia to a place outside Australia; or

  2. if the supply is the provision of access to DSGL technology--at the time of the provision of access, the supplier is in Australia and the other person is outside Australia

unless the supplier has a permit from the Defence Export Controls Office (DEC).

For example, emailing some code for a new encryption algorithm, or giving someone access to a private git repository that contains some code for a new encryption algorithm, is a crime if you are in Australia and the recipient is overseas. The distinction between working code and a clearly-specified algorithm is not clear.

This might all sound like a disaster for Australian industry, but there are a number of exemptions and exceptions that mean that most ordinary users and suppliers of encryption are unaffected. The most important is the good old ITAR "public domain" exemption, which excludes everything widely available to the general public. This means that most of Australian industry can ignore it. Only people inventing new encryption algorithms, or new attacks, are affected.

What technologies are controlled?

Encryption software is controlled under Australia's Defence and Strategic Goods List.

Section 5A002 controls "Cryptography for data confidentiality", specifically:

  1. A “symmetric algorithm” employing a key length in excess of 56 bits, not including parity bits;

  2. An "asymmetric algorithm" where the security of the algorithm is based on any of the following:

    1. Factorisation of integers in excess of 512 bits (e.g., RSA);
    2. Computation of discrete logarithms in a multiplicative group of a finite field of size greater than 512 bits (e.g., Diffie-Hellman over Z/pZ); or
    3. Discrete logarithms in a group other than mentioned in paragraph b.2. in excess of 112 bits (e.g., Diffie-Hellman over an elliptic curve); or

  3. An "asymmetric algorithm" where the security of the algorithm is based on any of the following:

    1. Shortest vector or closest vector problems associated with lattices (e.g., NewHope, Frodo, NTRUEncrypt, Kyber, Titanium);
    2. Finding isogenies between Supersingular elliptic curves (e.g., Supersingular Isogeny Key Encapsulation); or
    3. Decoding random codes (e.g., McEliece, Niederreiter).

Note that this applies only to encryption, not signatures, ZKPs, etc.

Section 5A004 also controls "Systems, equipment and components, for defeating, weakening or bypassing information security" including by performing cryptanalytic functions or by circumventing authentication or authorisation controls.

Exceptions and exemptions

The most important exception is that software and information that are "in the public domain" are not controlled.

Apart from that, the DSGL lists a number of specific exemptions for encryption software, for example:

The summary of all this is that you are affected only if you are developing a new encryption algorithm or a new attack, which you are quietly discussing with your coauthors but have not yet made public.

Specific details and Q & A

Point 1: Do not attempt to apply logic or reason, let alone science. You'll only make it worse for yourself.

Q: You mean that whether or not I go to jail – for up to a decade - depends on whether the recipient of my email was overseas at the time they received it? Seriously?

A: Please see point 1.

Q: OK, how do I prove that my encryption algorithm can only encrypt medical records?

A: Please see point 1.

Q: Don't you have a fundamental research exemption?

A: No.

Q: Don't you have a constitutional protection of free speech?

A: No.

Q: Why not just apply for a permit?

A: Well (perhaps obviously) that's the first thing we tried. You may still consider it worth trying. However, (a) DEC likes to take a long time to grant the permit, and then entertain themselves giving you permission to do something less than what you asked for, (b) even if you get the permit, you do not actually have any real protection because the permit can be revoked, at any time, by delivering the revocation notice to anyone "who appears to work at [your] address in a management or executive position." So don't let the undergrads wear a suit to campus.

Q: I don't want any trouble. In practice, what is the easiest way to just keep doing research without danger?

A: For most of us, the "public domain" exemption works – if you're not too proud to put a scrappy draft or in-progress codebase up on a public website, you're done. Then you can send as many emails about it, or let as many people collaborate on it, as you want.

DEC claims that this is valid only if it was already in the public domain, but I'm pretty sure this is just an unjustified effort at overreach – the word "already" does not appear in the relevant regulations or laws, which say simply that things in the public domain are exempt.

I note for the benefit of people of diverse nations of origin that the actual written law is the thing that matters. There is no chance the Australian military can jail you for something that is not actually prohibited by law, even if you really annoy them. I have considerable empirical evidence on this point.

Q: My research involves attacks on systems in practical use, so just making it public while in progress is not responsible. Is there a good solution?

A: I'm sorry. I hear Ruhr University Bochum is hiring.

Q: What if I take my own code out of the country by plane, on my own laptop?

A: This is contested, and I have argued with the Australian military over this question, but a careful examination of the law finds no crime here. It is a crime to supply encryption software to another person (my emphasis) if the recipient is overseas. I see no crime, anywhere in Australian law, of taking encryption out of the country per se.

Q: Has anyone ever been prosecuted under these laws?

A: As far as I know, nobody has been prosecuted in Australia for exporting encryption. There have been prosecutions under the same legislation, which also covers the export of some things that are actually harmful.

Q: Is there any likelihood of law reform?

A: Yes, but be careful what you wish for. A bill currently before the Australian Parliament would expand these penalties to apply to communications to non-Australians inside Australia, unless those foreigners are from special nice countries we trust (specifically, the US and the UK). As an Australian of Anglo-Celtic origin, I'm too disgusted even to write about it. I will update this page if the new law comes into force before PKC.