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.
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.
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.
> 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.
"... 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.
> 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.
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 ). 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.
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.
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.
>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.
Just to clarify, I've seen an argument repeatedly that secure backdoors for law enforcement are foolish because they're a mathematical impossibility. So that we're not discrediting our (anti backdoor) position by guilt of exaggeration, we can safely admit that's false.
The problem isn't with mathematical impossibilities but the practical realities of implementing these techniques and the inherent, insurmountable side channel attacks.
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.
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.
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...
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.'
16 comments
[ 3.2 ms ] story [ 58.5 ms ] threadWhile 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.
Authentication: difficult if not practically impossible[1]
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.
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.
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.
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.
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.
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.
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.
https://dspace.mit.edu/bitstream/handle/1721.1/97690/MIT-CSA... https://en.wikipedia.org/wiki/Key_escrow https://en.wikipedia.org/wiki/Secret_sharing
The problem isn't with mathematical impossibilities but the practical realities of implementing these techniques and the inherent, insurmountable side channel attacks.
Government should not have infinite power to peer into the private lives of people.
But I do agree that it should be a more broadly defined fundamental right.