
Nuts and Bolts of Encryption: A Primer for Policymakers [pdf] - petethomas
https://www.cs.princeton.edu/~felten/encryption_primer.pdf
======
alkonaut
Most important note to policy makers: encryption is a reality we can't limit
or forbid. It's maths.

Deliberately weakened encryption, special "master keys" or legal restrictions
on the use of powerful encryption are not even remotely feasible.

The bottom line is: everyone, especially those we wouldn't prefer did, can
communicate securely when they want.

A policymaker who still thinks that there is some kind of "pragmatic middle
way" where the intelligence community can listen to potential terrorists while
the rest of us can still do secure online banking, is delusional and needs to
be told as much.

~~~
adrianN
If you ban encryption, only criminals will be able to use encryption. That is
very convenient, since it's easy to detect when people are communicating on a
secure channel.

The same argument applies of course if you only allow encryption that has a
master key that allows LEA to eavesdrop. That is probably safe enough for
online banking (it's the system we currently have with https), so from a
policymaker's point of view this is an okay solution.

~~~
EthanHeilman
>That is very convenient, since it's easy to detect when people are
communicating on a secure channel.

This is a fairly complicated question. Disk/file encryption is not easy to
detect without access to the disk , however I won't discuss that here because
you only addressed communication.

Generally when policy people talk about encryption they mean technologies
which protect confidentiality, but not technologies which protect
authentication e.g. signature algorithms, MACs, etc. Authentication
technologies often contain random fields such as nonces this provides a very
obvious location to store encrypted data in a message. Given that ciphertexts
should be indistinguishable from randomness, an attacker should not be able to
tell that a random field is not random without the key. There are already
tools which hide ciphertexts in nonce fields.

Compression also provides a useful place to hide ciphertexts since it looks
random as well.

Most criminals will not go to the lengths above. Most people including most
criminals prefer convenience over security. That being said, if communication
security is important to a crime (and it usually isn't), and the criminals are
competent at INFOSEC (they usually aren't) they can and will use encryption
which is not easily detectable (spies can and will use hard to detect
encryption even if encryption is illegal).

We are moving toward a society in which almost anything done in public is
recorded and analyzed via video, RFID/cell tower access patterns/social
media/license plate readers. Police have never had more tools to investigate
crime and never had more evidence to convict people. If LEOs so wished and had
the resources to handle the caseload and arrests they could get ~90% clearance
for jaywalking.

------
JumpCrisscross
> _No prior background on encryption or data security is assumed_

Second sentence under "encrypted storage": "Alice generates a secret key that
only she knows, and she uses the secret key to encrypt the data".

Both people I showed this to, each highly intelligent and accomplished in
their fields, gave up at that point. "Secret keys" are defined on the next
page, but a brief should define concepts before deploying them.

------
DarkKomunalec
This seems useful, but I have to admit I'm dissatisfied with the tech
community's response to government efforts to cripple encryption, specifically
the "but then the -bad guys- will also exploit the backdoors!" stance. While
true, the better argument is that keeping secrets should not be a crime, but a
fundamental right - the right to privacy.

Government should not have infinite power to peer into the private lives of
people.

~~~
post_meridiem
The problem is that in the U.S., we don't have a fundamental right to privacy.
Constitutional guarantees of privacy are either specific (e.g., to practice
religion) or indirect (e.g., search/seizure).

But I do agree that it should be a more broadly defined fundamental right.

~~~
DarkKomunalec
In addition to the 1st amendment problems of banning certain kinds of code, I
think forcing encryption to have a backdoor could be construed as part of a
search, and so run afoul of the 4th amendment. Who knows what the courts might
say though - I wonder if there's any precedent...

~~~
post_meridiem
The 4th does state that it is "The right of the people to be secure in their
[...] papers [...]." I'd love to witness a judicial argument that seeks to
extend this to code/binary 'goods.'

------
marknadal
Not that the article isn't decent, but presentation and context makes a huge
difference. For instance, even though this is only 5 pages long, it being a
PDF with formal titles will turn a lot of people off (which is unfortunate).
I've been trying to combat that, so we decided to create animated 1 minute
cartoons about cryptography (
[http://gun.js.org/explainers/data/security.html](http://gun.js.org/explainers/data/security.html)
). They certainly are not a deep dive into encryption, but hopefully they make
it fun for people (including kids) in a friendly and approachable way. So far
our user study on them has gone well, but there is a lot to be improved.

~~~
homarp
Target audience is 'policymakers'. I'm sure the presentation is perfect for
the target audience.

------
lukeadams
I'm not in the industry, so keep that in mind.

While this document comes across as a decent primer on the general theory
behind encryption, I wish it covered the security implications of historical
policy proposals (key escrow and DRM come to mind).

It seems important to make sure that policymakers are not only educated on
encryption, but on the pitfalls or "fallacies" that come about when, well,
trying to write policy regarding it. Such misconceptions, I think, are more
dangerous than a fundamental misunderstanding of the system as a whole as they
allow for crippling crypto by law (picking and choosing implementation
details), instead of simply misinformed blanket laws.

------
axoltl
While I understand the audience isn't supposed to be technical, implying that
encryption confers integrity is a common misconception we shouldn't be
enforcing. Encryption and authentication are two separate concepts, even
though there are algorithms that provide both.

~~~
gwu78
Encryption: getting easier every day

Authentication: difficult if not practically impossible[1]

    
    
       [1]Outside of organizations where members follow rules.
    

If you agree, then here is a question:

Why does SSL, hereafter "TLS", _not_ separate the two concepts for the user?

The user is never presented with the information that TLS-enabled software can
encrypt data, e.g., in transit, requiring almost no effort on her part, _but
that there is no reliable way for software alone to verify an endpoint or
content on an untrusted network such as the internet._

Instead she is led to believe it is all or nothing, and that the software she
is using is performing both, with equal rates of success.

Verification (authentication) requires human effort.

Software can help but computers alone cannot solve the problem.

Delegating verification to third parties, e.g., a "CA system" or a startup, is
antithetical to the goal of encryption -- protection from third parties. It
does not solve the problem.

~~~
marcosdumay
> Why does SSL, hereafter "TLS", not separate the two concepts for the user?

Because encryption without authentication is worthless. It's Alice passing a
secret message on paper to anybody on the street that will claim to be Bob.

~~~
gwu78
"... encryption without authentication is worthless."

I have heard this before, i.e., seen it in HN comments.

There are uses for encryption without authentication.

I am not an expert on encryption. This is all I will say.

In your example, Alice may not know where Bob is, but if the message is
encrypted with Bob's public key then unless I am mistaken only Bob can decrypt
it. She can leave the message somehere for Bob to get it.

Does Bob need to know the message was sent by the real Alice?

Do web servers check client certificates?

Assuming what you say is true, that unless your authentication solution is as
good as your encryption solution, then the encryption is "worthless", then I
think there is a large amount of "worthless" encryption being performed using
TLS.

How many users have control over routing on the internet?

Even if a user had a solution to verify a physical computer on the internet,
e.g., SSH, whether she could actually reach that computer in order to verify
it is not necessarily within her control.

She might as well just assume a third party, i.e.. "anybody on the street",
could easily obtain a copy of the encrypted data she is transferring.

File encryption can be useful without any authentication of any other party.
Some files are not "messages" intended for any other party to see.

