Obvious next step
If we find that you are using 'noPrismNet' you must have something to hide and are therefore a Terrorist. Send them to Gitmo and do not pass 'Go'.
The Internet Engineering Task Force (IETF) has posted “PRISM-Proof Security Considerations” aimed at making it much harder for governments to implement programs like the PRISM effort whistleblower Edward Snowden exposed as one of the tools in the NSA's spookery toolbag. The proposal has just one author - Phillip Hallam-Baker of …
If we find that you are using 'noPrismNet' you must have something to hide and are therefore a Terrorist. Send them to Gitmo and do not pass 'Go'.
You are missing the point. A backlash at open standards level by a body not controlled by US law and not run by US government personnel (like NIST) is likely to be very difficult to contain.
I just read the draft, it is a typical IETF problem statement draft (fairly well written too). The way IETF works is - problem statement -> architecture -> implementation standards. The chickens are not coming home to roost. Yet. That will happen around the architecture drafts so to early to count them either.
In any case, if someone told me a few years back that we will be discussing a draft to defend the internet against USA at an IETF hosted by Huawei (they are the host of the Vancouver meeting) I would have asked him what did he smoke lately. The mere fact this is becoming a reality and a continuation of the old adage about "The best golpher is black, the best wrapper is white..." is by itself... hmm... entertaining...
That's funny, because I saw the obvious next step as this:
Unknown zero day compromises target's IP stack -> All your security measures are belong to US. ;)
That was a truly awful pun, have an upvote.
They're trying to solve the wrong problem. Stopping the NSA from reading my email is not the problem. The real problem is the NSA knowing who I talk to and when (metadata).
The IETF designs and implements internet standards. They can, for instance, redesign the email standard to hide or obscure email headers. Or require TLS connections between email servers. Or make email transport encrypted instead of plaintext.
The IETF is one of the bodies that can solve the metadata problem. Your criticism is uninformed.
Oh dear. Let me explain. The ietf can't do anything as long as we are using tcpip as a basic transport. The reason is that all the packets include source and destination addresses. That is metadata and it can't be obfuscated or encrypted without breaking the internet itself. Tor attempts to do what you claim is sufficient but it's compromised because in the end, it's reliant on the underlying protocols.
The only way you can prevent the nsa from identifying the parties involved in a communication - and believe me that's all they really want 99% of the time - is to hide one of the end points. You need a broadcast protocol where reception is anonymous, If we tried to multicast over the current architecture we'd simply flood the network and render it unusable.
I don't believe there's a general purpose answer that doesn't require a massive rewiring that, lets face it, isn't going to happen.
But if it's an SMTP packet, the destination IP address will be a mail server. The actual recipient is just data (at the IP level) and could easily be encrypted. The problem with encryption is that it mostly relies on trusted parties (such as certificate issuers) who can easily be subverted by local government agencies.
Encryption does not rely on certificates being issued by trusted parties. It doesn't rely on certificates at all - it is only TLS (SSL) that uses certificates for the initial key exchange.
If the IETF is redesigning the Internet, they may as well come up with a better way of handling key exchanges. E.g. you could put public keys into DNS instead of sticking them into certificates (of course, this just moves the trust issue to your DNS records, but at least those can be managed and verified by yourself).
Then headers will have to be encrypted as well as the body and the successor to SMTP will have to operate on encrypted headers.
> Encryption does not rely on certificates being issued by trusted parties.
To be usefully secure it does. Without this, your traffic can be subject to a man-in-the-middle attack: encrypted from endpoint A to eavesdropper, re-encrypted from eavesdropper to endpoint B.
> you could put public keys into DNS instead of sticking them into certificates
Yes of course, this is old news, see RFC 4025, RFC 2536, RFC 3110. The problem is what happens if somebody modifies the DNS response and substitutes their own key. Your key needs to be verified/signed. This is what DNSSEC does, and effectively the DNS root becomes the One And Only True Certificate Authority (in turn delegating authority to subdomain owners)
> of course, this just moves the trust issue to your DNS records, but at least those can be managed and verified by yourself
There's not much point verifying your own public key, as you already have it. What you care about is verifying the public key of the person you're talking to. You can of course do this manually - e.g. you can collect a business card from them in person, and the business card can have the public key's fingerprint on it. But that's not very useful for the majority of cases.
E.g. you could put public keys into DNS instead of sticking them into certificates (of course, this just moves the trust issue to your DNS records, but at least those can be managed and verified by yourself).
Far from perfect, but a great improvement on the current CA system. With the current SSL certs, a CA in Iran controlled by the Iranian government can forge a certificate for any server regardless of whether the server owners have anything to do with Iran.
With DNSSEC, and putting your server cert in DNS, you get to choose the TLD (DNS top level domain) registry, and its policies. Not perfect, because TLDs are all directly or ultimately controlled by national governments, but at least you get to choose which government can subvert your cert based on the TLD of the domain you register, rather than allowing your cert to be subverted by any of them.
They actually have a better way to do it.
With the current SSL certs, a CA in Iran controlled by the Iranian government can forge a certificate for any server regardless of whether the server owners have anything to do with Iran.
True, but this only has an impact if you choose to trust the Iranian CA (many computers in Iran may well be configured to do so, I have no idea). The risk for most of us is that (I imagine) the NSA can tell the standard top-level CAs to provide them with the same capability, and 99% of computers on the Internet will blindly trust them.
[Some IPSs use this capability. You configure all the computers on your network to trust the certificate on the IPS, which can then act as a man-in-the-middle and monitor all 'encrypted' traffic in and out of your organisation.]
Back in the late 90's when encrypted internet was first being suggested there was a "it will use PKI" and "it will use Trusted Third Parties" drive/mantra/dogma (you choose).... where this started and how it was promoted I am not sure, but it is most definitely where the problem lies!
We implemented a system with in-security designed in and "they" (whomever they were) knew it...
1. Trusted third parties aren't - some actors are broken, eg. Iranian government issues certificate for google.com
2. Trusted third parties can be leant on by governments to provide intermediate signing certificates
3. Trusted third parties can be spoofed as part of a MITM attack
The current certificate based system is both:
a) over complex, and
b) has mixed goals
is it "encryption" and "key exchange" or is it "authentication"?
IMHO what its needed is:
* very good ciphers (AES128 is ok, others are better)
* excellent key agreement or key exchange protocols (eg. ECDHE)
* separation of roles (key exchange and authentication)
* no "trusted third parties", no certificates - use DNS for pub/private keys and authentication codes - effectively "self sign". I can assert that I am me as I own my DNS.
We already have all the components to do this, and do it properly - we only need the will (we have the way).
So, we either need another upgrade to TLS/SSL to fully support a strong, no certificate, approach or we need a new protocol... if its a new protocol then on the web lets call it HTTPZ ('Z' being used to indicate encryption)
Unfortunately, whilst a nice idea in principle, it is becoming clearer as more information is released that the underlying infrastructure of the current internet has been fatally compromised by the efforts of security services worldwide.
I can't see that there will ever be an internet which is free from the possibility of such interception,apart from starting again from scratch with new hardware, software and cryptography standards untainted by government interference, and this is not a feasible or practical solution for the internet as a whole.
this is not a feasible or practical solution for the internet as a whole
I don't know about that: Just look how quickly DNSSec and IPv6 have been implemented.
Oh, wait, I think I see your point...
(I remember attending seminars on IPv6 when I was at 'varsity, way back in the previous millennium, and it's still years away from being ubiquitous.)
The NSA didn't have 'Staff in "Leadership positions" in the IETF' as claimed in an article I came across on G+ yesterday which claims exactly that and that they actively disrupt processes like security standards. Written by someone on one of those committees, i believe.
I don't have a link but a quick Google should turn something up pretty quick i'd imagine.
EDIT: This TechDirt article should get you closer - http://www.techdirt.com/articles/20130909/11430124454/john-gilmore-how-nsa-sabotaged-key-security-standard.shtml
The IETF can propose what they like but the big question then is ‘how it is going to get funded’?
The history of the Internet both past and on-going illustrates exactly this point. Originally like, or lump, it the Internet was derived from a world-wide defense (military) network. The [defense scientists/fascist jackbooted minions of our totalitarian leaders (delete to taste as appropriate) ] would have funded Arpanet because they wanted to exchange defense information.
If you had used it at that time why would you have assumed that your email wasn't monitored?
Going forward this network was then handed over to commercial interests. Fast forward again most of the organisations who are heavily interested (i.e. funding) the internet are perhaps even more interested in [obtaining marketing information/spying]. They provide the funding because they can see the value of the [marketing info/illegal interceptions].
Where is the money going to come from to fund the IETF’s Utopian ideas for the PRISM free Internet? Or if you prefer in El Reg speak who is going to spaff up the cash?
Who is spaffing it up now ? You. And me. We all are, in our monthly Internet fees.
Because, if I am not mistaken, everyone on the Internet is paying for that connection. So if I were told that I could have a "secure from all spying" connection at €5 more than my actual connection fee, I just might say yes - on the principle of the matter.
And I think there are a lot of people like me.
OK so that pay's for the running costs of this new PRISM free internet. Now who is going to pay for the Infrastructure?
A hundred years ago, every pub of note had a “snug” with “priest windows” to protect the privacy of (priests, magistrates, police, ladies) who wanted an anonymous drink; attitudes to drunkenness changed & laws against drunk children put an end to anonymity. Many of the “snugs” that remain now have CCTV to cut down drug trading & prostitution. In a posh suburban pub you’re more likely to be invited to a swingers group or a spot of dogging than to use a prostitute, partly because the police veto on pub-licencing means the barman might report it, but also because we’re a much more open society now.
The answer to PRISM is not to add more security, but enable better targeting by more transparency:  IPv6 does away with the need for NAT & ISP proxy servers that hide end-points making it easier to filter raw traffic  more honesty on what search words will attract attention: assuming that a google-search for gang-rape or sarin should be more private than searching for it in a bar is naïve and simultaneously prudish & disgusting.
If you really, really, really want privacy, buy a global proxy-service, but don’t expect any search engines to help you find stuff
..... posh suburban pub you’re more likely to be invited to a swingers group or a spot of dogging ... google-search
You may have a point here, after searching for 15 combinations of 'where posh pub channell drinks Stephen' I can't hear any black choppers.
So your answer to mass invasion of privacy is to stop bothering to have any hopes of privacy, just write it off as a thing of the past...
No doubt you believe that "if you have nothing to hide, you have nothing to fear" as well, please post the URI of your blog where you detail every aspect of your personal and intimate relationships... after all you don't have anything to hide... so there should be no problem with you personally having nothing hidden, should there?
Well I never? It seems there is more on the issue of black choppers. After a little more searching I found a forum advertising BI black choppers.
Looking at the posting I guess this would be somebody tentatively looking to maybe use UAV’s to gather business intelligence. Anyway I fired off an email inquiry, further it would seem they would be very keen to demonstrate their products, and I have been invited to a local BI black chopper roast.
Just wondering if the wife would like to go as well she likes a nice BBQ, although she might not be so keen on UAV’s.
Sadly the paper is a little light on for actual ideas about how the internet can be PRISM-proofed,… … Simon Sharwood, 12th September 2013
Understandably is the paper a little light on actual ideas about how the internet can be better monitored and more smartly mentored, Simon, which is surely the galloping white knight to the rescue of the damsel in distress side of PRISM-like programs, of which there are bound to be quite a number on the dark black knight side too, given Man's powerful and uncontrolled, and some would even say and have one believe, uncontrollable urges.
But only very few have a chance or any hope of being effective and worthwhile for IT is not a space and virtual environment which tolerates or caters for fools and their tools even should countless numbers of them imagine it and IT does and can provide them with all of their needs and feeds and seeds.
Nice try, but that was understandable punctuation and not nearly enough random capitals. Please try again!
I thought that the problem is that the NSA isn't using covert means, they just roll up to the ISP and say "we want your data". How is any sort of clever protocol going to help that? PRISM didn't take message contents, just interconnect info, and the ISP has to know that in order to route the messages, even if the content is end-to-end encrypted.
As an aside, is the author the PHB that used to stir up scb on Usenet? Always good for winding people up...
“two layers of public key exchange using the credentials of the parties to negotiate a temporary key which is in turn used to derive the symmetric session key used for communications”
Isn't that DH key exchange?
Is public-key cryptography still really so much more computationally expensive than symmetric-key as only to be suitable for temporarily encrypting a symmetric key which is then used for the real encrypted exchange?
Because it seems to me that the system as a whole is only as strong as the weaker of the two layers. If you can crack the public-key encryption then you get the symmetric key; but if you can go straight to breaking the final symmetric-key encryption, then you don't need to bother breaking the public-key encryption with which it was protected.
There were two reasons for using symmetric session keys, the first is their suitability for use in stream ciphers and the second is the expense of asymmetric crypto. This has not changed to my knowledge, and what I have seen recently is that practical brute-forcing of symmetric session keys is somewhere around 80 bits, so 128 bit symmetric is still essentially impossible to crack in short (or indeed long) order.
From my perspective the whole problem is that the man in the street has lost understanding of how the abuse of government power has disadvantaged him, what we need to return things to a more even LEA vs citizen balance is for the people who collect the data and the politicians who insist of making it possible (not that I didn't say legal) should be held to account.
I will be writing to my MP to explain that unless he is prepared to tell me that he will, independent of his party whip, support the repeal of laws which allow indiscriminate collection of data traffic and the enactment of laws that provide real, sharp-toothed protection that requires senior legal oversight of any interception then he can forget my vote coming his (or indeed any other candidate's) way.
We have an opportunity here, while good well-implemented crypto is good in general, it's useless unless the rubber-hose option is removed from the equation, we the citizenry need to tell those who govern in our name that we've had enough of their approach and their cluelessness.
"Is public-key cryptography still really so much more computationally expensive than symmetric-key as only to be suitable for temporarily encrypting a symmetric key which is then used for the real encrypted exchange?"
Yes definitely. The reason being that an asymmetric key can only be used to encrypt or decrypt a number, based upon arithmetic operations involving the key components and the number. Fine if the number is random and of a size suitable for use as a symmetric key. This will still take forever if your number is a DVD's worth of data, as carrying out a modular exponentiation or eliptic curve computation on a number sized in Gigabytes will take very much longer than such calculations involving prime products of random 1024 bit numbers, and random 256 bit numbers large enough to be suitable for use as AES256 keys.
Symmetric block cyphers can chomp through a DVD's worth of data and more at Gigabit Ethernet speed.
The reason being that an asymmetric key can only be used to encrypt or decrypt a number
Sigh. Any digital signal is "a number".
carrying out a modular exponentiation or eliptic curve computation on a number sized in Gigabytes will take very much longer than such calculations involving prime products of random 1024 bit numbers
And would require excessive storage as well, which is why no one with any sense would try such a thing. They'd partition the bit stream into bit strings of suitable length.
Asymmetric encryption of such strings is still too slow to be practical for transmitting lots of data, of course, which is one of the reasons why asymmetric encryption is only used to encrypt a session key. Another is that it's possible there are better-than-brute-force attacks against common asymmetric ciphers that require large amounts of ciphertext, which is an argument against encrypting lots of data with your asymmetric cipher. Similarly, the more data you encrypt with a given cipher, the more vulnerable you are to side-channel (power, timing, etc) attacks. These latter two apply to symmetric-encryption implementations as well, but because they're conventionally used to encrypt lots of data, they've been studied much more extensively for that case and good implementations have been hardened against those sorts of attacks (eg by blinding to obscure side-channel leakage).
becomming snoop proof is a 2 step process
1. clean up the end-points.
this requires that the end-point be subjected to a software intentory and audit to insure that all and only the desired software is present. open source o/s preferred
you cannot have a meaningful discussion about encryption until you have satisfied (1) (above) .
2. use GnuPG -- again open source -- to authenticate and secure communication links. this is a task that each user will have to learn and practice . the current practice of thransmitting masses of x.509 certificates authenticated by massive "Certificate Authorities" -- has been compromised on occasion and has ben the subject of significant inquiries by good COMSEC folks.
> 1. clean up the end-points.
> this requires that the end-point be subjected to a software intentory and audit to insure that all and only the desired software is present. open source o/s preferred
That doesn't give me much comfort.
Imagine this. I have a smartphone with say 512M of flash. I build my open-source image, I verify the binary matches the source code, I load it onto the flash using a JTAG loader, I flip the write-disable bit, and I boot my phone. Secure right?
Nope. Suppose that unbeknown to me, the CPU boots from a *different* ROM inside the silicon. This includes a virtualisation stack which emulates the phone. Then this boots the image in my 512M flash. The phone software performs exactly as expected, but the outer virtualisation layer has full access to my phone's RAM contents, it can read any encryption keys out of RAM, etc etc.
This ultimately is what we have to defend against: Byzantine hardware. Unless you have your own chip fab, this is going to be extraordinarily difficult to do. The more traffic is encrypted on the Internet, the more the focus will shift to backdoors in endpoints, initially in their operating systems but ultimately in the hardware itself.
Does anyone think we should start using pen and paper again?
Hahahahahaaaa! What, seriously? HAHAHAHAHAHAHAAAAA!!!
Encryption won't keep NSA out entirely, but it will make it harder for them to pick us out of the crowd. Decrypting still takes extra time & effort and that little bit of hassle may be enough to keep their noses out of your business.
The same goes for storing stuff on Dropbox, iCloud, etc. Take it down and stash everything in a CloudLocker (www.cloudlocker.it), which works just the same but it's private and stays in your home where they still need a warrant to see inside.
First, after reading that IETF list of attacks, it seems a good reference point to from which to start collating all forms of attack, not only from governments but cyber criminals as well.
However, does anyone think governments will take this lying down? I very much doubt it. It stands to reason on the grounds that the US has spent trillions of dollars in implementing its PRISM and other surveillance activities, and it would not want that investment to be wiped out by IETF let alone lose access to the information to which it has already gained access.
If solutions are found for the attacks then I'd imagine governments would either ban their implementation, or alternatively stop or block users from accessing them. ISPs would be forced to block new protocols by law etc.
If so, then I'd hope internet users would then cause an almighty uproar on the grounds that IETF's proposals would also defeat much cyber criminal activity. The matter would then get very heated politically.
If perhaps IETF's proposals were made illegal in the US/UK etc. then they could be implemented (or at least partially) in 'neutral' counties, which, in turn, would be blocked to users by the US/UK etc.--in effect this I'd mean that for US users the Internet's governance would end up like the situation in China.
If IETF's proposals come to naught then do not be surprised if governments have infiltrated or subverted the IETF process. I wouldn't put it past them.
I seem to recall that the initial purpose of the computer was to break machine ciphers. Why is anyone surprised that people ( governments, etc ) would use them for that?
No one is, or should be, surprised that GCHQ/NSA/etc break codes and spy on people. That is, after all their job, and the other side (e.g. China) will do the same.
What people are, and rightly should be, upset about is the presumption that everyone is a criminal and should have all of their activity recorded, decrypted and analysed "because they can".
It goes far beyond what most folk consider is acceptable under the usual police requirement of justifiable suspicion. Add in to that the secretive and rather despotic use of orders that you can do jail time for simply revealing that you have been ordered to do something, and the apparent lack of meaningful judicial oversight or even political knowledge outside of a select few, and it is a very wrong situation for society to find itself in.
We don't need unbreakable encryption or other silver bullets, all we need is widely used non-compromised encryption that means it is not trivial to gather everything about everyone you unless you are already under suspicion, rather like the old days when an agent had to be posted to watch you and resources limited that to the "most interesting" of all.
The real problem isn't the NSA, it's the Great Firewall of China and internet surveillance by other non-democratic regimes. How one imagines people will be able to use technical measures to avoid that is beyond me.
Wouldn't ubiquitous use of IPSec or the like do this? This operates at IP level, so in theory you can set it up IPSec on your end, and as it's enabled on the other end it'll be used automatically (i.e. applications would not need to be rewritten to use IPSec.) Ubiquitous use of ipsec would have a similar effect to increasing use of https, even if NSA has shortcuts the time involved would still make it so they would have to target individual sessions rather than ubiquitous sniffing and cataloging.