Stories
Slash Boxes
Comments

SoylentNews is people

posted by mrpg on Sunday February 18 2018, @11:06AM   Printer-friendly
from the double-speak dept.

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"


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by pipedwho on Sunday February 18 2018, @09:56PM (4 children)

    by pipedwho (2032) on Sunday February 18 2018, @09:56PM (#639824)

    This is absolutely true. However, Joe did qualify with:

    This is not saying: make up your own stuff from scratch and hope it sticks... this is saying: research the methods that have been proven, roll your own implementation from vetted published solutions, and include enough variation that when a successful attack method for the common implementations inevitably gets released it won't work on your implementation.

    There are various parameters and things you can do with an open source implementation of something that you otherwise trust. For example, at the lowest level lets say you're paranoid and worry about a weakness in AES (ignore that is has some proven security bounds), so you decide to add some extra rounds to your 'variant'. That change is within the design parameters of AES and will not only add security (at the detriment of performance, which may not matter to you), but also very likely 'break' any mass deployed automated cracking scripts/tools that assume that the protocol is just using standard AES.

    You might also decide to add an 'obfuscation' protocol (based on otherwise secure crypto) on top of the existing 'trusted' solution. For example, you add some additional fixed encryption using AES (or Twofish, Serpent, etc) on top of the already effective protocol elements (especially the key exchange section). You might even just encode the fixed key constant in your app, creating an 'obfuscation' layer more than anything else. However, if the 'trusted' App falls to some exploit that allows a trojan or worm to 'mass harvest' messages from people communicating with the original App, your variant is still 'safe'. Yes, someone could analyse and easily crack that too. But, it's a lot of manual effort for a single payoff. And the mass deployed harvesting tools can't 'see' inside the encrypted data, so it just looks like garbage (or another 'unknown' protocol).

    All you've done is taken an open source tool such as PGP and made a modification that is described by cryptographic literature as otherwise 'valid' or 'safe'. Whether or not it makes much difference (or even adds any additional 'security' in the classical sense) is irrelevant to what Joe was alluding to.

    But, you are right, people with no experience with cryptographic implementation should definitely avoid rolling their own.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 3, Insightful) by JoeMerchant on Monday February 19 2018, @01:58AM

    by JoeMerchant (3937) on Monday February 19 2018, @01:58AM (#639911)

    Thank you - I try not to spell things out too pedantically, it takes too long to read (and write.)

    IMO, the most powerful security is a combination of the best available algorithms plus obscurity. If the crackers don't know what they're dealing with, it will take actual (expensive) human brain power to try to break it, and unless you're a top priority target that's not likely to happen.

    What is likely to happen is a the cracking of a widely used tool (or app) and the subsequent mass harvesting of all traffic that passed through it - that will catch all kinds of people who weren't even on anyone's radar, until a mass harvester tripped on a few keywords in their archived communications streams from years gone by.

    --
    🌻🌻 [google.com]
  • (Score: 2) by Wootery on Tuesday February 20 2018, @03:34PM (2 children)

    by Wootery (2341) on Tuesday February 20 2018, @03:34PM (#640670)

    So the advice essentially boils down to become an expert cryptographer, then roll your own.

    That advice is... unhelpful.

    What's really wrong with just implementing an algo like Curve25519?

    You might also decide to add an 'obfuscation' protocol

    Or just use a proper algorithm like Curve25519 and don't pretend that amateur-hour band-aids are the solution.

    • (Score: 2) by pipedwho on Wednesday February 21 2018, @08:22AM (1 child)

      by pipedwho (2032) on Wednesday February 21 2018, @08:22AM (#641076)

      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

        by Wootery (2341) on Wednesday February 21 2018, @09:40AM (#641092)

        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.

        back in the day where it was common for people/companies to try and roll their own low level crypto algorithms

        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.