News for hackers. Stuff that matters.
Re:Insecure by design: protocols for encrypted phone calls by dotBen on Thursday February 25, 2016 @10:50AM (#11175173)
If a government agency responsible for signal monitoring and espionage suggests an encryption format, endorses one particular format over another or even just actively participates in such discussions -- shouldn't that raise alarm bells in most tech-savvy people's heads?

The reality is the telecommunication industries in UK, US and other nations are complicit with such activity because they are legally required to provide access to their partners in government intelligence. And they operate in highly regulated environments that they will be shut out of if they don't cooperate.

Encryption has moved to the OS level, which is why we're seeing similar pressure being presented to Apple with this terrorist's iPhone.

Re:Insecure by design: protocols for encrypted phone calls by makecheck on Thursday February 25, 2016 @04:29PM (#11177959)
It’s tricky.

In any technical field, it is important for the “good” and “best” people from that field to participate in group activities so that there is a better chance of sane decision-making. And in any sufficiently-complex field that has a government agency, you would certainly hope that at least some of those “good” and “best” people are working for the government. So what to do?

Perhaps one approach is to make sure no one group is over-represented, e.g. 5 different organizations that each have one vote or something.

Re:Insecure by design: protocols for encrypted phone calls by colejohnson66 on Thursday February 25, 2016 @02:25PM (#11177041)
> If a government agency responsible for signal monitoring and espionage suggests an encryption format, endorses one particular format over another or even just actively participates in such discussions -- shouldn't that raise alarm bells in most tech-savvy people's heads?

Yes, but the NSA did have a hand in AES

Re:Insecure by design: protocols for encrypted phone calls by nickik on Thursday February 25, 2016 @03:18PM (#11177468)
The NIST and other state organsiation continue to be active in this area. However not all they do is poor evil and all the open standards AES or SHA1 have also been studied and reviewed by many other cryptographers. Most consider them still save for practical uscases.

Nowdays the NIST is guiding the process of standartisation, but does not itself activally doing anything. Most cryptographers agree that in the process for SHA3 ran quite smothly and they did a good job. However when the NIST tried to over some improvments, the crypto community heavly stomped them and these improvments never went into the standart.

There were talks on these subject in the last couple of Chaos Communication Congresses.

Re:Insecure by design: protocols for encrypted phone calls by cvwright on Thursday February 25, 2016 @03:55PM (#11177712)
Sure, NIST ran the competition, but AES was designed by Daemen and Rijmen in Belgium, and vetted by a whole host of other academic cryptographers in an open process.

There's enough to be paranoid about already. No need to looking for problems where there aren't any.

Re:Insecure by design: protocols for encrypted phone calls by gh02t on Thursday February 25, 2016 @09:50PM (#11179531)
It's a fine line, because after all it is also [part of] the responsibility of the NSA to protect American citizens and businesses from foreign interception. They have two directly competing goals when recommending an encryption scheme: make it as secure as possible to prevent foreign/malicious actors from intercepting it, while they also want to be able to break any encryption scheme they recommend themselves.

To me, this says that they would be more likely to recommend fundamentally sound encryption schemes, but choose parameters where they can have hidden knowledge that lets them undermine it. Stuff like what people think they may have done with the eliptic curve constants, where they [supposedly] have chosen constants that they have extra knowledge about, but the method itself is apparently otherwise quite solid.