SoylentNews is people
SoylentNews
Riana Pfefferkorn, a Cryptography Fellow at the Center for Internet and Society at Stanford Law School, has published a whitepaper on the risks of so-called "responsible encryption". This refers to inclusion of a mechanism for exceptional access by law enforcement to the cleartext content of encrypted messages. It also goes by the names "back door", "key escrow", and "golden key".
Federal law enforcement officials in the United States have recently renewed their periodic demands for legislation to regulate encryption. While they offer few technical specifics, their general proposal—that vendors must retain the ability to decrypt for law enforcement the devices they manufacture or communications their services transmit—presents intractable problems that would-be regulators must not ignore.
However, with all that said, a lot more is said than done. Some others would make the case that active participation is needed in the democratic process by people knowledgeable in use of actual ICT. As RMS has many times pointed out much to the chagrin of more than a few geeks, "geeks like to think that they can ignore politics, you can leave politics alone, but politics won't leave you alone." Again, participation is needed rather than ceding the whole process, and thus its outcome, to the loonies.
Source : New Paper on The Risks of "Responsible Encryption"
Related:
EFF : New National Academy of Sciences Report on Encryption Asks the Wrong Questions
Great, Now There's "Responsible Encryption"
(Score: 2) by pipedwho on Wednesday February 21 2018, @08:22AM (1 child)
Because you're just as likely to stuff up your implementation of Curve25519 if you're not an experience cryptography programmer anyway. So it's not particularly useful to use a single protocol element without considering the rest of the cryptographic system design.
If you want to use Curve25519 just find some trusted Open Source project that already uses it.
Or better yet, add it 'in series' with an already trusted/vetted Open Source project so you have something that is resistant to automated mass data vacuum scripts that might target the public version of your chosen tool. Even if you end up with a ham fisted effort that turns out to be insecure, at least you can fall back to the trusted secure implementation you have as the basis of your modified application.
So, the advice is don't try to roll your own. If you do, play it safe and do it in an additive way that doesn't touch or use any key material from the trusted implementation that you're modifying. If you have done a lot of research on the topic, then feel free to make some more subtle but secure changes to the parameters (if you don't understand what this means, you haven't done enough research, and are not ready to change anything).
I've seen far too many amateur hour totally insecure implementations that use otherwise secure algorithms like AES, RSA, Curve25519, SHA, etc. But they do something stupid (and usually a cascade of equally dumb things) that ends up pretty much voiding any security that the algorithms offered. It's better than back in the day where it was common for people/companies to try and roll their own low level crypto algorithms. At least these days we have some good building blocks to use from the likes of NIST, and if you don't trust NIST, then Dan Bernstein.
(Score: 2) by Wootery on Wednesday February 21 2018, @09:40AM
Ultimately I agree, of course, but we were putting on our tin-foil hats and pretending we couldn't trust any existing implementations. Perhaps the best answer to that hypothetical is simply in that case all is already lost.
The horror, the horror. A proprietary 4096-bit crypto scheme sounds great on paper, to a clueless pointy-haired boss at least, but as you say, it's like saying you've given your security guards hand-made 11mm handguns.