Talk:Encryption

Short

I removed the table of contents from this article because I felt it was distracting and served no purpose (there's no subsections!). Please add subsections! 68.173.113.106 (talk) 03:16, 7 March 2012 (UTC)

RfC concerning the Lavabit email service

There is a request for comments (RfC) that may be of interest. The RfC is at

Talk:Lavabit#RfC: Should information about Lavabit complying with previous search warrants be included?

At issue is whether we should delete or keep the following text in the Lavabit article:

Before the Snowden incident, Lavabit had complied with previous search warrants. For example, on June 10, 2013, a search warrant was executed against Lavabit user Joey006@lavabit.com for alleged possession of child pornography.

Your input on this question would be very much welcome. --Guy Macon (talk) 05:07, 29 August 2013 (UTC)

Added references

I've found articles for the needed citations. I will be removing the additional citations needed tag. BadSprad (talk) 14:22, 21 May 2015 (UTC)

You didn't mention

1. each piece of information has a list of possible encryptions, Alice and Bob (sender and receiver) know that list, a randomizer picks a random synonymous encryption (that causes encryptions to be large, but are manageable)
2. the size of the encryption output is variable, each information has lists of synonymous encryptions of many sizes of digits, each size-list must contain as many as possible synonymous encryptions
   • the reader of the message, must have a secondary key, to know the order of the digital fragmentation packages
     • ⚠ many packages of certain digital sizes do not encrypt anything, just pure noise,

you have to dedicate many digit-sizes to noise, otherwise Eve the eavesdropper might find some patterns.

1. typical and statistically common phrases are coded as one piece of information, they're not fragmented into separate letters
2. (this is problematic, it's not used because it reveals statistics about your letters, also can lead to permanent informational loss) some consciously made spelling mistakes might help you hide better you message but the orthographic mistakes must be selected by a computer because humans are bad randomizers

   (there is a myth that monkeys are good randomizers, a pure myth, monkeys neurotically press a range of buttons in a chaotic but not random way, read chaos, animals are bad randomizers and they can never type the Bible even after eternal infinities, because are restricted by their "envelope of chaos" function, their attractor. Monkeys cannot type the Bible, even after eternal infinities, because they are restricted by their chaotic attractor which by no means is random.

That requires huge lists from sender and receiver, also the messages are huge.

It has been used by the US, China and Russia (combined usually with 3 or more other encryptions) but you must have a clear line or preferably a cable (fiber optics). It's bad for space because it's slow, and if you make your lists smaller, then it's faster but anyone can decrypt your message. — Preceding unsigned comment added by 2A02:2149:8227:A300:9444:E682:3FB:B7E3 (talk) 18:27, 4 March 2018 (UTC)

you have to shuffle your lists, you need huge keys, it works (you don't write them by hand but then someone may steal the key, some people use several keys, and different security units handle them, they aren't allowed to communicate with each other, only with the commander. If one security group delivers the key to the enemy, the other keys are safe, so our encryption entropy. Even the commander isn't supposed to know all the details, only the generic management. (secrets leak outside the system, people don't play all day long with technology... some have sex with unknown people..... encryption won't help then) — Preceding unsigned comment added by 2A02:2149:847A:1E00:9444:E682:3FB:B7E3 (talk) 20:08, 4 March 2018 (UTC)

Shaky References

Reference 2, "History of Cryptography" is from Binance Academy, with no further sources at the reference source. Not sure where binance gets their info from, but this source is essentially just "dude trust me".

While I don't really doubt the truth of this claim, can we get a better source for early encryption and cryptographic history other than a binance article?

Zeph.tech (talk) 06:59, 8 September 2022 (UTC)

Various issues

I’d like to comment on some of this article’s issues. For convenience, I’ll refer to “the author”. Apologies for any formatting or other such errors.

(1) It refers the word “encryption”, to the article on “encoding”. But the latter article is nothing to do with modern cryptography or encryption. For example:

- It doesn’t or barely mentions any cryptographic terms: secret, cipher, key, nonce, stream, block, symmetric, asymmetric etc.

- It says that “codes were once common for ensuring the confidentiality of communications, although *ciphers are now used instead*” [my emphasis]

- Its only example of a “secret” code, is “any kind of imaginative encoding: flowers, game cards, clothes, fans, hats, melodies, birds, etc., in which the sole requirement is the pre-agreement on the meaning by both the sender and the receiver”. That’s far removed from modern encryption.

Encryption, and normal encoding, have diametrically opposite purposes. The purpose of encryption is to limit the number of people who can access certain information. The purpose of normal encoding is to *maximise* the number of people who can access certain information - for example, by providing a detailed public specification of a mapping between bytes and symbols, so different systems can unambiguously map bytes to symbols and vice-versa. Encryption is a *keyed* process - it relies on secret values that are known only to authorised parties. Encoding is normally an *unkeyed* process - no secret values are involved.

Of course, encoding and encryption are often used together. For example, to encrypt a text message, you’d first *encode* that message by using a known encoding scheme (eg. UTF-8) to map its symbols to bytes, then *encrypt* (ie. scramble) those bytes. The recipient would then *decrypt* (ie. unscramble) those bytes, then *decode* (unmap) those unscrambled bytes, back into symbols. However, that doesn’t make encoding and encryption, similar things. When I eat dinner, I sit at a table then eat with a fork. That doesn’t make tables and forks, similar things.

I believe it would be useful to include a brief description, explanation or example of encoding, in the encryption article, to clarify the difference. That example could certainly link to the encoding article. But simply linking “encryption”, to “encoding”, with zero clarification, is misleading and pointless.

(2) “Modern encryption schemes use the concepts of public key and symmetric key”.

That is very weirdly worded. Modern encryption schemes (ie. ciphers) are asymmetric, or symmetric. Asymmetric ciphers use “public” keys, and “private” keys. Symmetric ciphers use “secret” keys. The article’s current statement is like saying, “Foodstuffs use the concepts of T-bone steaks, and cereals”.

Also, modern ciphers can be classified in various ways: asymmetric versus symmetric, authenticated vs unauthenticated, deterministic vs probabilistic, stream vs block, and so on. It seems lacking to mention only one such classification.

(3) “Modern encryption techniques ensure security because modern computers are inefficient at cracking the encryption.”

That’s like saying, “Modern bank vaults ensure security because people can’t break into them”. Neither statement tells the reader anything useful. I suspect the author has no idea how modern ciphers actually do ensure security. Some simple examples could be given. Eg. RSA relies on the difficulty of factoring the products of large prime numbers.

(4) “It would take a supercomputer anywhere between weeks to months to factor [the] key”.

That’s just nonsense. A modern asymmetric key could not be factored by thousands of supercomputers running for the article author’s lifetime. See RSA Challenge.

(5) “Most applications of encryption protect information only at rest or in transit, leaving sensitive data in clear text and potentially vulnerable to improper disclosure during processing, such as by a cloud service for example.”

What does the author mean by *only* ”at rest or in transit”? What other states are there?

I feel that statement is not at all clear that it’s referring to the case where encrypted data must be *temporarily decrypted in order to process the plaintext somehow*. I suggest:

“Sometimes, encrypted data is temporarily decrypted in order to process the decrypted data; for example, to find all records for patients named Smith. If the processing host is untrusted, this exposes the decrypted data to unauthorised use or disclosure by that untrusted host.”

That would IMHO be a much clearer lead-up to the author’s subsequent mentions of homomorphic encryption, and secure multi-party computation.

(6) Homomorphic encryption, and secure multi-party computation, are fairly obscure topics IMHO. Much more common is simple “end-to-end encryption”, which lets two parties safely communicate via, and store data on, untrusted hosts. A section on that would be good.

(7) “It is possible to decrypt the message without possessing the key but, for a well-designed encryption scheme, considerable computational resources and skills are required.”

Is that referring to brute-force attacks? If so, that’s another nonsense statement. Just *iterating a counter* through each numeric value of (say) a 128 bit symmetric key, would take more energy than available in the universe. “Considerable computational resources” suggests that you might succeed by buying enough compute from Amazon! The article’s statement is like saying, “Finding a single marked grain of sand that was dropped from a high altitude airplane at a random location over the Pacific Ocean 15 years ago, would be very difficult”. It wouldn’t be “very difficult” - it would be absolutely impossible under any conceivable circumstances.

I’d also prefer, “decrypt the message without *initially* possessing the key”. A brute force attack works by *finding the key*; it doesn’t let you decrypt the message without *ever possessing* the key, which is what the article implies at present.

— In summary, a lot of this article reads to me like a school project. I feel it needs a thorough rewrite from someone who understands the subject properly, and can express themselves concisely. For various reasons that won’t be me. I’m surprised that an article on such an important topic, could be on such low quality.

13:52, 7 April 2025 (UTC)TC 1.147.13.120 (talk) 13:52, 7 April 2025 (UTC)