Talk:Encryption

New Warning

So we have a new warning. How useful is it?

"Remember Just because it is widely considered safe doesn't mean exploits can not be found."

Technically true, but technically true of all software ever written. Therefore vague. Therefore not very useful. Can we write something more practical?

Table with current state of encryption breakage? Dates a must.

References to court cases where the encryptioin has clearly been tested by State actors?

"Also remember that encryption mechanisms aren't a cure-all to your problems. Only when used correctly can encryption work to your advantage."

This is very vague. What are "encryption mechanisms"? What are our "problems"? What specific technology in what situation is encryption "used correctly" and what "advantage" are we seeking?

Let's make this warning useful. Let's split it up into specific (i.e. exact commands/situations) for each section in the article. And if there isn't an appopriate section, create one.

Mrsnooze (talk) 03:22, 20 February 2016 (EST)

Page Needs Rework

Much of this article refers to Full Disk Encryption

It doesn't explicitly state so. An appropriate header of FDE should probably be added, with a warning that FDE is only useful when your computer is switched off/drive unmounted etc. A section on cold boot attacks wouldn't go astray.

Page should be split into sections.

FDE

phone encryption?

single file encryption

web encryption

communication encryption?

encryption standards

others?

Mrsnooze (talk) 03:22, 20 February 2016 (EST)

If you want to make the change, just do it. I am not an expert on this topic.  Morpheus talk 11:18, 20 February 2016 (EST)

FBI vs Apple

So this story is still developing, but the FBI vs Apple iPhone encryption is a big deal. It's going to set a precident, which if goes in the FBI's favour, will open the floodgates to backdoored devices. We need a section on this at some point. The FBI is asking Apple to provide a signed, custom firmware patch to:

1. Allow more than 10 password guesses per hour.
2. Not allow the phone to wipe itself after 10 bad guesses.
3. Allow guesses to be made via usb/whatever interface, rather than the touchscreen.

This is so that the can run an effective bruteforce against the phone's pincode. The phone in question is the San Bernidino shooter's phone. Brute forcing with iPhones needs the pincode, iPhone TPM and iPhone cpuid (or similar - check this, risky business podcast 399 linked below explains it).

References: Slashdot:

• Judge Tells Apple To Help FBI Access San Bernardino Shooters' iPhone
• Congressman: Court Order To Decrypt iPhone Has Far-Reaching Implications
• Edward Snowden Calls For Google To Side With Apple On Encryption Debate
• Google CEO Finally Chimes In On FBI Encryption Case, Says He Agrees With Apple
• Paris Attacks Would Not Have Happened Without Crypto
• John McAfee Offers To Decrypt San Bernardino iPhone For the FBI and Save America
• Where Do the Presidential Candidates Stand On Encryption?
• N. Carolina Senator Drafting Bill To Criminalize Apple's Refusal To Aid Decryption
• DoJ Says Apple's Posture on iPhone Unlocking Is Just Marketing
• Apple: Terrorist's Apple ID Password Changed In Government Custody

Soylent News:

• Apple Wants Court To Rule If It Can Be Forced To Unlock iPhones
• Apple Ordered by Judge to Help Decrypt San Bernadino Shooter's phone
• FBI vs. Apple Encryption Fight Continues

Risky Business infosec podcast:

• Risky Business #399 -- Apple vs the Government of the United States

Ars Technica:

• How Apple will fight the DOJ in iPhone backdoor crypto case
• Apple: We tried to help FBI terror probe, but someone changed iCloud password
• Feds to court: Apple must be forced to help us unlock seized iPhone
• Encryption isn’t at stake, the FBI knows Apple already has the desired key
• Trump urges supporters to boycott Apple in wake of encryption brouhaha
• Senator drafting bill to criminalize Apple’s refusal to aid decryption
• Google CEO: Forcing Apple to comply with FBI may set “troubling precedent”

Mrsnooze (talk) 03:52, 20 February 2016 (EST)

All closed-source software is backdoored!

I removed some of the FUD regarding Microsoft and Mac OSX. The reported Bitlocker attack requires EM detection of TPM chips; it cannot be generalized to Bitlocker as a software system. To be honest, if the CIA needs to attack the TPM chip, this should be proof that there is actually no backdoor in Bitlocker... — Preceding unsigned comment added by Rfaelens (talk • contribs)

Misc

We should probably move all the disk encryption to its own page and use this as a overall page of encryption in general. -- God (talk) 02:20, 17 March 2015 (EDT)