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

161–170 of 207 posts

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

#161

Post by londons_explore »

Geisterde wrote: post #88
londons_explore wrote: post #37

Earlier quoted context omitted.

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.

Well, I think that would sevearly inhibit future development. Scaling on bitcoin has been a delicate game of optimizing every bit that gets recorded, but also support future developments that dont even exist yet, there is no undo button either. New signature schemas and clevar cryptography tricks can do quite a bit, but when you slap another layer of cryptography on you will inevitably make things worse in the long r…

If you reveal you have broken sha-256, then your bug bounty becomes worthless. The smart move is to steal and drain a few wallets slowly.

And that's exactly what we see - and every time it happens, the bitcoin community just laughs that someone must have been bad at key management or used a weak random number generator.

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

#162

Post by londons_explore »

KennyBlanken wrote: post #145
londons_explore wrote: post #37

Earlier quoted context omitted.

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.

I'll do you one better. The head of security for Golang, a google employee, was also part of the TLS 1.3 committee and in Golang, it's impossible by design to disable specific ciphers in TLS 1.3 The prick actually had the nerve to assert that TLS 1.3's security is so good this should never be necessary, and that even if it were, they'll just patch it and everyone can upgrade. So someone releases a 0-day exploit for a…

Seems like a stupid design, if only for the fact that some uses of TLS, where a very specific client is connecting, you might want to enable precisely the one cypher suite you expect that client to use.

Then all your performance tests can rely on the encryption and key exchange will always use the same amount of CPU time etc.

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

#163

Post by Geisterde »

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…

Ill take "what is vault 7" for $500.

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

#164

Post by Geisterde »

londons_explore wrote: post #161
Geisterde wrote: post #88

Earlier quoted context omitted.

Well, I think that would sevearly inhibit future development. Scaling on bitcoin has been a delicate game of optimizing every bit that gets recorded, but also support future developments that dont even exist yet, there is no undo button either. New signature schemas and clevar cryptography tricks can do quite a bit, but when you slap another layer of cryptography on you will inevitably make things worse in the long r…

If you reveal you have broken sha-256, then your bug bounty becomes worthless. The smart move is to steal and drain a few wallets slowly. And that's exactly what we see - and every time it happens, the bitcoin community just laughs that someone must have been bad at key management or used a weak random number generator.

> management or used a weak random number generator.

Except that has been the case in every instance thus far. The dev that lost his bitcoin last year was using arcane software, after a biopsy they found the library being used only had like 64 bits of entropy.

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

#165

Post by anticensor »

p-e-w wrote: post #91
progbits wrote: post #19

As this is from 2016 it doesn't include this new fun revelation: > On 11 February 2020, The Washington Post, ZDF and SRF revealed that Crypto AG was secretly owned by the CIA in a highly classified partnership with West German intelligence, and the spy agencies could easily break the codes used to send encrypted messages. https://en.m.wikipedia.org/wiki/Crypto_AG

> The company had about 230 employees, had offices in Abidjan, Abu Dhabi, Buenos Aires, Kuala Lumpur, Muscat, Selsdon and Steinhausen, and did business throughout the world. That's a... really strange list of office locations, especially considering the relatively small number of employees. > The owners of Crypto AG were unknown, supposedly even to the managers of the firm, and they held their ownership through beare…

Codify all the management policy in the main charter, leaving nothing else to the board to decide?

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

#167

Post by ykonstant »

Goodroo wrote: post #118
1337biz wrote: post #105

Earlier quoted context omitted.

Would be interesting what similar companies are (in parts) most likely agency fronts. My guess would be quite a few in the soft privacy selling business, such as VPN or email providers.

Proton mail is a CIA front email provider

Hmm... should I choose a provider with a history of spying on everyone and destabilization, or Google? ...OK, I'll go with the CIA.

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

#168

Post by ryaniscool »

consp wrote: post #156
tjoff wrote: post #143

Earlier quoted context omitted.

> [...] and this enabled others to OCR it, and recompile it offshore. Did it? Or did it just give them plausible deniability? I remember playing with OCR as a kid and all the software I could get my hands on gave horrendous results, even if the input was as perfect as one could hope for. And even today I sometimes run tesseract on perfect screenshots and it still makes weird mistakes. Would be interesting to know if…

Banks used it on checques for ages, why would it be that difficult? You do need a compatible typesetting though.

Where did you get your information? MICR lines, the line of numbers at the bottom of the check, use magnetic ink. The acronym stands for Magnetic Ink Character Recognition. So for ages, they didn't use optics at all.

In the modern day, cheque OCR is monopolized by one company, Mitek. They may use tesseract somewhere in their stack but I've never read that anywhere.

Post reply on HN