A brief history of the U.S. trying to add backdoors into encrypted data (2016) • Hacker News Board

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#31

Post by xyst » Sat, Feb 03, 2024, 9:44 PM UTC

for a long time, the US considered cryptography algos as a munition. Needed some arms license to export.

Also, US tried to convince the world only 56 bits of encryption was sufficient. As SSL (I don’t think TLS was a thing back then) was becoming more mainstream, US govt only permitted banks and other entities to use DES [1] to “secure” their communications. Using anything more than 56 bits was considered illegal.

https://en.m.wikipedia.org/wiki/Data_Encryption_Standard

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#32

Post by bayindirh » Sat, Feb 03, 2024, 10:07 PM UTC

coppsilgold wrote: post #4

FBI director James Comey have publicly lobbied for the insertion of cryptographic “backdoors” into software and hardware to allow law enforcement agencies to bypass authentication and access a suspect’s data surreptitiously. Cybersecurity experts have unanimously condemned the idea, pointing out that such backdoors would fundamentally undermine encryption and could exploited by criminals, among other issues. "could e…

Let’s see:

Mercedes recently forgot a token in a public repository which grants access to everything.

Microsoft forgot its “Golden Key” in the open, allowing all kinds of activation and secure boot shenanigans.

Microsoft’s JWT private key is also stolen, making the login page a decoration.

Somebody stole Realtek’s driver signing keys for Stuxnet attack.

HDMI master key is broken.

BluRay master key is broken.

DVD CSS master key is broken.

TSA master keys are in all 3D printing repositories now.

Staying on the physical realm, somebody made an automated tool to profile, interpret and print key blanks for locks with "restricted keyways" which has no blanks available.

These are the ones I remember just top of my head.

So yes, any digital or physical secret key is secure until it isn’t.

It’s not a question of if, but when. So, no escrows or back doors. Thanks.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#33

Post by fragmede » Sat, Feb 03, 2024, 10:10 PM UTC

dataangel wrote: post #20

2OEH8eoCRo0 wrote: post #14

Earlier quoted context omitted.

What's an update? They can sign and push any code they want remotely.

IIRC the question is when the phone is totally locked, e.g. if you turn it off then turn it back on and haven't entered the PIN yet. In this state even apple can't get an update to run, the secure hardware won't do it unless you wipe the phone first. And your data is encrypted until you unlock the phone. In practice though most people are screwed b/c it's all already in icloud.

with advanced data protection, it's encrypted before it hits iCloud, so apple, nor the feds can't get at it.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#34

Post by devwastaken » Sat, Feb 03, 2024, 10:14 PM UTC

coppsilgold wrote: post #7

devwastaken wrote: post #6

Earlier quoted context omitted.

It's not a false claim, assuming the feds will keep such a key "secure" is not backed by evidence. Top secret materials are leaked all the time. Private keys from well secured systems are extracted from hacks. The FBI having such a key would make them a very profitable target for the various corps that specialize in hacking for hire. For example, NSO group. If the power doesn't exist, nobody can exploit it.

Do military cryptographic keys leak often? Do nuclear codes leak? The times highly valuable cryptographic keys leaked for various cryptocurrency exchanges it has generally if not always been due to gross negligence. Such a key would be highly sensitive and it would also require very little traffic to use. You would just need to send the secure system a KEM ( I don't doubt they could secure it. Can even split the key…

You're creating so many assumptions that nothing you've stated could be concluded to be an honest reflection of reality.

Nobody has to know the rate of leaks, it's irrelevant. Gross negligence is not necessary, how would you even know? Leaks by definition are rarely exposed, we only see some of them.

A "highly sensitive" key doesn't mean anything. Assigning more words to it doesn't somehow change the nature of it. Humans are bad at securing things, that's why the best security is to not have a system that requires it.

Whatever hypothetical solution you have would be crushed under the weight of government committees and office politics until your security measures are bogus.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#35

Post by mnw21cam » Sat, Feb 03, 2024, 10:22 PM UTC

coppsilgold wrote: post #4

FBI director James Comey have publicly lobbied for the insertion of cryptographic “backdoors” into software and hardware to allow law enforcement agencies to bypass authentication and access a suspect’s data surreptitiously. Cybersecurity experts have unanimously condemned the idea, pointing out that such backdoors would fundamentally undermine encryption and could exploited by criminals, among other issues. "could e…

> As long as the government can keep a private key secure...

Which government? Software crosses borders.

You can bet that if the US mandated a back door to be inserted into software that was being exported to another country, that country would want to either have the master key for that back door, or a different version of the software with a different back door or without the back door. A software user could choose the version of the software that they wanted to use according to which country (if any) could snoop on them. It's unworkable.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#36

Post by mannyv » Sat, Feb 03, 2024, 10:29 PM UTC

There's talk that the NSA put its own magic numbers into elliptical curve seeds. Does that count?

https://www.bleepingcomputer.com/news/security/bounty-offere...

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#37

Post by londons_explore » Sat, Feb 03, 2024, 10:41 PM UTC

xyst wrote: post #31

for a long time, the US considered cryptography algos as a munition. Needed some arms license to export. Also, US tried to convince the world only 56 bits of encryption was sufficient. As SSL (I don’t think TLS was a thing back then) was becoming more mainstream, US govt only permitted banks and other entities to use DES [1] to “secure” their communications. Using anything more than 56 bits was considered illegal. ht…

Even now, if you join a discussion on crypto and say something like "Why don't we double the key length" or "Why not stack two encryption algorithms on top of one another because then if either is broken the data is still secure", you'll immediately get a bunch of negative replies from anonymous accounts saying it's unnecessary and that current crypto is plenty secure.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#38

Post by loughnane » Sat, Feb 03, 2024, 10:46 PM UTC

wtallis wrote: post #29

loughnane wrote: post #2

This topic comes up a bunch still. Someone please correct me, but as I understand it anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch. I know puri.sm[0] takes some steps to try to plug the hole, but haven't read up to see if it's effective or no. [0] https://puri.sm/learn/intel-me/

Most consumer products (as opposed to some of those marketed to businesses) don't have enough of the components in place for the ME to accomplish anything, good or bad.

What do you mean? What sort of components?

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#39

Post by loughnane » Sat, Feb 03, 2024, 10:47 PM UTC

bri3d wrote: post #23

loughnane wrote: post #2

This topic comes up a bunch still. Someone please correct me, but as I understand it anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch. I know puri.sm[0] takes some steps to try to plug the hole, but haven't read up to see if it's effective or no. [0] https://puri.sm/learn/intel-me/

> anyone using new chips that use Intel ME (or AMD's equivalent) have a gaping hole in their security that no OS can patch Not really; anyone using chips with Intel ME or AMD PSP have an additional large binary blob running on their system which may or may not contain bugs or backdoors (of course, also realizing a sufficiently bad bug is indistinguishable from a backdoor). There are tens to hundreds of such blobs run…

Yeah, this lives in the back of my mind too. I run debian on 11th gen intel, but with the non-free blobs included to make life easier. I've been meaning to try it without them, but it's too tempting to just get things 'up' instead of hacking on it.

Re: A brief history of the U.S. trying to add backdoors into encrypted data (2016)

#40

Post by nimbius » Sat, Feb 03, 2024, 10:55 PM UTC

Everyone forgets the speck and simon crypto the NSA wanted in the Linux kernel that were, ultimately, removed from it entirely after a lot of well deserved criticism from heavy hitters like Schneier.

https://en.m.wikipedia.org/wiki/Speck_(cipher)