Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

atlasobscura.com

Post reply on HN
Print view View original

71–80 of 207 posts

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

#71

Post by paulpauper »

londons_explore wrote: post #37
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.

two encryption algorithms will mean needing two completely unrelated , unique passwords. this can be impractical and increase odds of being locked out forever

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

#72

Post by inquirerGeneral »

mmaunder wrote: post #43

Honorable mention for the ITAR regs that prevented Phil Zimmerman from exporting PGP 128 bit encryption until Zimmerman and MIT press printed the source as a book protected by the first amendment, exported it, and this enabled others to OCR it, and recompile it offshore. Also that ITAR enabled Thawte in South Africa (where I’m from) as a business to completely dominate sales for 128 bit SSL certs outside the US. Thaw…

I didn't know any of this. Thanks.

"The U.S. Munitions List changes over time. Until 1996–1997, ITAR classified strong cryptography as arms and prohibited their export from the U.S.[5]

Another change occurred as a result of Space Systems/Loral's conduct after the February 1996 failed launch of the Intelsat 708 satellite. The Department of State charged Space Systems/Loral with violating the Arms Export Control Act and the ITAR.[6][7]

As a result, technology pertaining to satellites and launch vehicles became more carefully protected." https://en.wikipedia.org/wiki/International_Traffic_in_Arms_....

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

#73

Post by paulpauper »

jarjar2_ wrote: post #60

One of my favorite comics about cryptography. https://xkcd.com/538/ Government routinely posits a desperate need for backdoors in crypto and crypto secured products, but almost universally they get the data they want without needing a manufacturer provided backdoor. So why they insist on continuing to do that is beyond me. It's almost security theater. If they really want your protected information they will be able…

A backdoor, which works anywhere and way better than the wrench option.

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

#74

Post by BLKNSLVR »

hunglee2 wrote: post #55

the biggest threat to a citizens privacy is always your own government.

Yep. I use Chinese brand phones because if they're snooping all my shit, they're much further away from me than my own government and not likely to have sharing arrangements.

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

#75

Post by aspenmayer »

bri3d wrote: post #63
dylan604 wrote: post #56

Earlier quoted context omitted.

Are these blob type of attacks accessible after boot? Essentially, are these only accessible if you have physical access? And at that point, isn't it game over anyways?

Intel ME allows intentional remote access through the ME in some enterprise scenarios (vPro). The driver support matrix is quite small and this is a massively overblown concern IMO, but it’s the root of a lot of the hand wringing. However, onboard firmware based attacks are absolutely accessible remotely and after boot in many scenarios. It’s certainly plausible in theory that an exploit in ME firmware could, for exa…

> The closed-sourceness is only a tiny part of the problem, too - a lot of the worst attacks so far are actually in open source based EFI firmware, which is riddled with bugs.

Can you elaborate and/or provide context/links?

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

#76

Post by jarjar2_ »

paulpauper wrote: post #73
jarjar2_ wrote: post #60

One of my favorite comics about cryptography. https://xkcd.com/538/ Government routinely posits a desperate need for backdoors in crypto and crypto secured products, but almost universally they get the data they want without needing a manufacturer provided backdoor. So why they insist on continuing to do that is beyond me. It's almost security theater. If they really want your protected information they will be able…

A backdoor, which works anywhere and way better than the wrench option.

They don't need it, which was my point. They have all the tools the need right now to get what they want. Why should anyone grant them more?

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

#77

Post by aspenmayer »

BLKNSLVR wrote: post #74
hunglee2 wrote: post #55

the biggest threat to a citizens privacy is always your own government.

Yep. I use Chinese brand phones because if they're snooping all my shit, they're much further away from me than my own government and not likely to have sharing arrangements.

Wouldn’t Chinese branded phones be a higher priority target by foreign agencies in the first place?

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

#78

Post by sweetjuly »

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/

People always complain about ME/PSP but it misses the point: there is no alternative to trusting your SoC manufacturer. If they wanted to implement a backdoor, they could do so in a much more powerful and secretive way.

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

#79

Post by MattPalmer1086 »

meroes wrote: post #45
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…

Do you have more on the legality aspect? I knew NSA pressured for a weaker key but what aspect could be made illegal? I had to write an undergrad paper on the original DES and I never saw an outright illegality aspect but wouldn’t be surprised. They also put in their own substitution boxes which I surprisingly never found much info on how exactly NSA could use them. So much speculation but why no detailed post mortem…

It seems that they changed the S boxes to make them more resistant to differential analysis (which they knew about but the public didn't). So this is actually a case of them secretly strengthening the crypto.

Presumably this is because they didn't want adversaries being able to decrypt stuff due to a fundamental flaw. I guess it's possible they also weakened it in another way, but if so nobody has managed to find it.

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

#80

Post by CWuestefeld »

mmaunder wrote: post #43

Honorable mention for the ITAR regs that prevented Phil Zimmerman from exporting PGP 128 bit encryption until Zimmerman and MIT press printed the source as a book protected by the first amendment, exported it, and this enabled others to OCR it, and recompile it offshore. Also that ITAR enabled Thawte in South Africa (where I’m from) as a business to completely dominate sales for 128 bit SSL certs outside the US. Thaw…

At the time, I had a t-shirt that said "this t-shirt is a munition", because it also had on it the RSA public key algorithm encoded as a barcode.
Post reply on HN