Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Encryption
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== The debate around encryption == The question of balancing the need for national security with the right to privacy has been debated for years, since encryption has become critical in today's digital society. The modern encryption debate<ref>{{Cite web |last= Catania |first= Simone |date=2022-11-02 |title=The Modern Encryption Debate: What's at Stake? |url=https://circleid.com/posts/20221102-the-modern-encryption-debate-whats-at-stake|website=CircleID |language=en}}</ref> started around the '90s when US government tried to ban cryptography because, according to them, it would threaten national security. The debate is polarized around two opposing views. Those who see strong encryption as a problem making it easier for criminals to hide their illegal acts online and others who argue that encryption keep digital communications safe. The debate heated up in 2014, when Big Tech like Apple and Google set encryption by default in their devices. This was the start of a series of controversies that puts governments, companies and internet users at stake. === Integrity protection of Ciphertexts === Encryption, by itself, can protect the confidentiality of messages, but other techniques are still needed to protect the integrity and authenticity of a message; for example, verification of a [[message authentication code]] (MAC) or a [[digital signature]] usually done by a [[Hash function|hashing algorithm]] or a [[Pretty Good Privacy|PGP signature]]. [[Authenticated encryption]] algorithms are designed to provide both encryption and integrity protection together. Standards for [[cryptographic software]] and [[Hardware encryption|hardware to perform encryption]] are widely available, but successfully using encryption to ensure security may be a challenging problem. A single error in system design or execution can allow successful attacks. Sometimes an adversary can obtain unencrypted information without directly undoing the encryption. See for example [[traffic analysis]], [[Tempest (codename)|TEMPEST]], or [[Trojan horse (computing)|Trojan horse]].<ref>{{cite web|url=https://usa.kaspersky.com/internet-security-center/threats/trojans#.VV3oaWDTvfY|title=What is a Trojan Virus β Malware Protection β Kaspersky Lab US|date=3 October 2023 }}</ref> Integrity protection mechanisms such as [[message authentication code|MACs]] and [[digital signature]]s must be applied to the ciphertext when it is first created, typically on the same device used to compose the message, to protect a message [[End-to-end principle|end-to-end]] along its full transmission path; otherwise, any node between the sender and the encryption agent could potentially tamper with it. Encrypting at the time of creation is only secure if the encryption device itself has correct [[Key (cryptography)|keys]] and has not been tampered with. If an endpoint device has been configured to trust a [[root certificate]] that an attacker controls, for example, then the attacker can both inspect and tamper with encrypted data by performing a [[man-in-the-middle attack]] anywhere along the message's path. The common practice of [[Transport Layer Security#TLS interception|TLS interception]] by network operators represents a controlled and institutionally sanctioned form of such an attack, but countries have also attempted to employ such attacks as a form of control and censorship.<ref>{{cite news|url=https://thehackernews.com/2019/07/kazakhstan-https-security-certificate.html|title=Kazakhstan Begins Intercepting HTTPS Internet Traffic Of All Citizens Forcefully|first1=Mohit|last1=Kumar|date=July 2019|publisher=The Hacker News}}</ref> === Ciphertext length and padding === {{main| Padding (cryptography)}} Even when encryption correctly hides a message's content and it cannot be tampered with at rest or in transit, a message's ''length'' is a form of [[metadata]] that can still leak sensitive information about the message. For example, the well-known [[CRIME]] and [[BREACH]] attacks against [[HTTPS]] were [[side-channel attack]]s that relied on information leakage via the length of encrypted content.<ref>{{cite report|url=https://tools.ietf.org/html/rfc7457|title= Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)|first1=Y.|last1=Sheffer|first2=R.|last2=Holz|first3=P.|last3=Saint-Andre|date= February 2015}}</ref> [[Traffic analysis]] is a broad class of techniques that often employs message lengths to infer sensitive implementation about traffic flows by aggregating information about a large number of messages. [[Padding (cryptography)|Padding]] a message's payload before encrypting it can help obscure the cleartext's true length, at the cost of increasing the ciphertext's size and introducing or increasing [[Overhead (computing)|bandwidth overhead]]. Messages may be padded [[Padding (cryptography)#Randomized padding|randomly]] or [[Padding (cryptography)#Deterministic padding|deterministically]], with each approach having different tradeoffs. Encrypting and padding messages to form [[PURB (cryptography)|padded uniform random blobs or PURBs]] is a practice guaranteeing that the cipher text leaks no [[metadata]] about its cleartext's content, and leaks asymptotically minimal <math>O(\log\log M)</math> [[Entropy (information theory)|information]] via its length.<ref>{{cite journal|url=https://petsymposium.org/2019/files/papers/issue4/popets-2019-0056.pdf|title=Reducing Metadata Leakage from Encrypted Files and Communication with PURBs|first1=Kirill|last1=Nikitin|first2=Ludovic|last2=Barman|first3=Wouter|last3=Lueks|first4=Matthew|last4=Underwood|first5=Jean-Pierre|last5=Hubaux|first6=Bryan|last6=Ford|journal=Proceedings on Privacy Enhancing Technologies (PoPETS)|volume=2019|issue=4|pages=6β33|doi=10.2478/popets-2019-0056|year=2019|arxiv=1806.03160 |s2cid=47011059|doi-access=free}}</ref>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)