Incenser, or how NSA and GCHQ are tapping internet cables (2014)(electrospaces.net)
electrospaces.net
Incenser, or how NSA and GCHQ are tapping internet cables (2014)
https://www.electrospaces.net/2014/11/incenser-or-how-nsa-and-gchq-are.html
93 comments
I don't know why, but NordVPN has always made me wonder if it might be a honey pot. Just the way they came on the scene, had so much advertising money, made sure to bill themselves as the "no logs" option you heard the most about etc. But that's just pure speculation on my part
Considering the low barrier to entry, I would say that most of them are just run by dilettantes wanting to make an easy buck, but that amounts to the same thing because an intelligence service would be able to have their way with the infrastructure of just about any commercial VPN provider.
My thought was to sell a VPN-business-in-a-box where you plug in your domain name, AWS creds, and payment details and in exchange you get a fully built VPN business including a web site, VPN nodes, iOS app ready to submit to Apple, and so on. Just add customers...
My thought was to sell a VPN-business-in-a-box where you plug in your domain name, AWS creds, and payment details and in exchange you get a fully built VPN business including a web site, VPN nodes, iOS app ready to submit to Apple, and so on. Just add customers...
> Maybe they just don't want to target me because my systems are so hardened?
They most likely don't want to target you in the first place.
Yes, they're doing mass surveillance, but for the targeted stuff, they still have targets, and most of us won't make the list.
They most likely don't want to target you in the first place.
Yes, they're doing mass surveillance, but for the targeted stuff, they still have targets, and most of us won't make the list.
https://www.linuxjournal.com/content/nsa-linux-journal-extre...
The bar seems quite low
The bar seems quite low
The reporting is bullshit. The (both the linuxjournal and its DasErste source) claims the rules call Linux Journal an extremist forum. The actual rules say
"These variables define terms and websites relating to the TAILs (The Amnesic Incognito Live System) software program, a comsec mechanism advocated by extremists on extremist forums."
There is a huge difference between matching some of those criteria (which may cause your surveillance data to be retained longer) and actually being targeted for active attacks.
Regarding the longer retention, the Linuxjournal article says that "the Tagesschau story provides new details about how the NSA's XKEYSCORE program decides which traffic to keep indefinitely" but I found no such information in the Tagesschau story (http://web.archive.org/web/20141005083429/http://www.tagessc...)
The consequences of having traffic to one of the tagged sites were never really publicly explained, always just "THE NSA IS WATCHING SPECIFICALLY FOR (random thing the NSA had a selector for)". Given how many people match each of these selectors, just matching one of them can't mean that much.
"These variables define terms and websites relating to the TAILs (The Amnesic Incognito Live System) software program, a comsec mechanism advocated by extremists on extremist forums."
There is a huge difference between matching some of those criteria (which may cause your surveillance data to be retained longer) and actually being targeted for active attacks.
Regarding the longer retention, the Linuxjournal article says that "the Tagesschau story provides new details about how the NSA's XKEYSCORE program decides which traffic to keep indefinitely" but I found no such information in the Tagesschau story (http://web.archive.org/web/20141005083429/http://www.tagessc...)
The consequences of having traffic to one of the tagged sites were never really publicly explained, always just "THE NSA IS WATCHING SPECIFICALLY FOR (random thing the NSA had a selector for)". Given how many people match each of these selectors, just matching one of them can't mean that much.
Discussed at the time:
How NSA and GCHQ are tapping internet cables - https://news.ycombinator.com/item?id=8680983 - Dec 2014 (60 comments)
How NSA and GCHQ are tapping internet cables - https://news.ycombinator.com/item?id=8680983 - Dec 2014 (60 comments)
Quite interesting that the article and the electrospaces.net website cannot be shared on Facebook:
This URL goes against our Community Standards on spam: electrospaces.net To protect people on Facebook from spam, we don't allow content that contains such URLs.
This URL goes against our Community Standards on spam: electrospaces.net To protect people on Facebook from spam, we don't allow content that contains such URLs.
Curiously, yes indeed. Facebook blocked me from posting it because "spam".... Deliberate? I'd like to think not, but here's the question, how does one let them know of this? Their silly little series of notifications that it's forbidden gives no option for actually voicing any text complaint, except a generic disagreement check box. Ridiculous.
Quite interesting indeed. I'm most interested in the submarines and technology involved in performing such operations. How do they operate? what modifications are needed? what computing platforms do they possess? That being said, I really like the idea of submarine super computing platforms. Not because it brings to life the inner Tom Clancy, but knowing that a small part of the idea may present some kind of practical utility in the world of clandestine operation.
These are submarine cables (that is, cables installed under the sea) not cables installed or used by submarine boats.
How are submarine cables installed?
By surface ships. Near shore they use a towed plough to bury the cable, away from shore they just unreel the cable and let it lie on the seafloor.
The tapping of this particular cable happens on land with the paid aid of Cable&Wireless.
[deleted]
It's likely a false positive. We have no interest in trying to block it based on content.
(I work on network security/integrity, including terrestrial and subsea optical, at aforementioned company).
(I work on network security/integrity, including terrestrial and subsea optical, at aforementioned company).
I am sorry if you feel offended, probably undeservedly, but understand that I heard a lot of explanations from the aforementioned company and those explanation usually turn out to be lies. It makes it difficult for me to trust anything from the aforementioned company without some more substantial proof.
You know the story Jack and the Wolf?
I looked at electrospaces website and I just can't figure out what cause it to be classified as "spam". Please, don't tell me it is AI because it has become so easy and convenient to avoid any responsibility by just saying "AI did it, not us".
You know the story Jack and the Wolf?
I looked at electrospaces website and I just can't figure out what cause it to be classified as "spam". Please, don't tell me it is AI because it has become so easy and convenient to avoid any responsibility by just saying "AI did it, not us".
I won't carry any water for aforementioned company's explanations, "AI did it" or not.
Speaking generally, spam detection (even in email) often has as much to do with the behavior of whoever is trying to send a message as it does the content. I _suspect_ that a group of people were spamming it as evidence for their conspiracy theories and enough people reported the messages that it got added to a filter. Same thing happens with domains used for phishing (Google Safe Browsing), email spam filters, or other things.
Anyway, I'm not offended. I'm surprised that people here, upon hearing hoofbeats (spam), thought zebras (conspiracy to suppress information) instead of horses (spam filter false positive).
I'm sure someone will look into why electrospaces was marked as spam on Monday...
Speaking generally, spam detection (even in email) often has as much to do with the behavior of whoever is trying to send a message as it does the content. I _suspect_ that a group of people were spamming it as evidence for their conspiracy theories and enough people reported the messages that it got added to a filter. Same thing happens with domains used for phishing (Google Safe Browsing), email spam filters, or other things.
Anyway, I'm not offended. I'm surprised that people here, upon hearing hoofbeats (spam), thought zebras (conspiracy to suppress information) instead of horses (spam filter false positive).
I'm sure someone will look into why electrospaces was marked as spam on Monday...
It may well be false positive. But history of lies, suppression, lack of transparency and strangely convenient coincidences make people look for zebras first.
How one can tell FB that this might be a false-positive though?
As always with reaching megacorps: any official channel would be hopelessly flooded with spam, so your only hope is to reach an employee through alternative means. Usually a sufficienlty large Titter storm is the most robust way. But, as illustrated here, luck can be had on any social network.
That’s the beauty of it: you can’t.
Facebook doesn't listen to us peasants anyway, just like Google and the other mafia giants.
Obviously, it spreads misinformation and conspiracy theories, just look at this post about the nsa and GCHQ. Obviously just a bunch of tinfoil hat republican trumpies.
Curious if they can also tap encrypted content? Maybe for high interest targets a certain amount of cracking power can be directed to it?
They can easily crack content using 1024-bit Diffie-Hellman key exchanges with hardcoded parameters, which used to be common in VPN software and some servers. There was a big collective facepalm in the crypto community when this was revealed. Basically, they found a way to spend a lot of compute power once to crack a parameter set, then they can use it basically for free for any sessions using those parameters.
Other than that and backdoored software (e.g. stuff using RSA Bsafe with Dual-EC-DRBG, which has an NSA backdoor, or those Juniper VPNs which used the same), I don't think they can do much about modern TLS besides exploit obvious flaws in the implementations.
Other than that and backdoored software (e.g. stuff using RSA Bsafe with Dual-EC-DRBG, which has an NSA backdoor, or those Juniper VPNs which used the same), I don't think they can do much about modern TLS besides exploit obvious flaws in the implementations.
Vpn configurations are so often poorly chosen and we should not let critical infrastructure run on outdated IPsec for instance.
It may seem natural to build such infrastructure for a life span of 20-30 years but do you remember what state of the art was back in 2001? Most of that is now basically considered broken. Software is living and should never be « set-and-forget »
It may seem natural to build such infrastructure for a life span of 20-30 years but do you remember what state of the art was back in 2001? Most of that is now basically considered broken. Software is living and should never be « set-and-forget »
What? Software is immortal and binary - there are no transcription errors or mutations in a correct copy routine.
Why shouldn't software be set and forget? Don't Ada and VHDL have massive amounts of re-use of things written in the 80's and 90's?
Why shouldn't software be set and forget? Don't Ada and VHDL have massive amounts of re-use of things written in the 80's and 90's?
"- there are no transcription errors or mutations in a correct copy routine."
You only know it's correct after you verify the fact so formally that should read ...correct copy and verify routine.
Incidentally, we used to have switches to verify after copy such as /v but programming sloppiness and impatience - in having to wait extra time for the verify - has meant that the entropy for data processing integrity has increase as a consequence.
Right, no one seems to give a damn about such matters these days.
You only know it's correct after you verify the fact so formally that should read ...correct copy and verify routine.
Incidentally, we used to have switches to verify after copy such as /v but programming sloppiness and impatience - in having to wait extra time for the verify - has meant that the entropy for data processing integrity has increase as a consequence.
Right, no one seems to give a damn about such matters these days.
It's sad.
> Why shouldn't software be set and forget?
Even if you had bug-free hardware and formally verified software, your cryptography is broken and your kit has side channel issues that were never dreamed of 20 years ago.
Even if you had bug-free hardware and formally verified software, your cryptography is broken and your kit has side channel issues that were never dreamed of 20 years ago.
The software may not change, but the world around it does.
That's bullshit I regularly re-use old code. Let's just admit it - that's a cover for today's bad programmers.
I should clarify: I'm talking about software related to security. I'm sure you wouldn't want to use outdated broken crypto just because libraries already exist for it, for example.
That's a great counterexample.
Makes sense. I think my question was also: for high interest targets could they dedicate enough computing power to crack encryption most people consider secure enough. They don't have to crack everything, just one or two very important targets.
I guess we can't really know unless there are more leaks.
I guess we can't really know unless there are more leaks.
> I don't think they can do much about modern TLS besides exploit obvious flaws in the implementations
Which unfortunately means they can do quite a bit as we've seen, implementation is often much trickier than theory.
Which unfortunately means they can do quite a bit as we've seen, implementation is often much trickier than theory.
Compromising Certificate Authorities and various root endpoints is probably what’s is done since https became ubiquitous.
Compromising certificate authorities does not help in decrypting the data that is transmitted unless it is an active attack that modifies data.
That is way too obvious and I doubt any western country would do it on their homeland, the political risk is just too big.
Yeah. You don’t do this to your own country people. You get one of your five eyes friends to do it for you.
It‘s not exactly like there‘s no precedent… https://news.ycombinator.com/item?id=9076351
Because we have Certificate Transparency the evidence if this was happening is publicly available (whereas without CT it's just given to everybody connecting to this hypothetical bogus server)
So, where's the evidence? Without CT you could imagine that the spooks are snooping on everybody else and that's why you don't have any evidence -- they knew you were too smart, but with CT you can go look for evidence they snooped your grandmother's online bingo or your second cousin's Trump fandom forum, and well, seems like there just isn't any.
The Russians don't care if they're known to be doing crimes, that's why they sent assassins to England to murder an ex-spy and then offered the most stupid transparent lie about the men being "tourists". But the NSA is kinda sensitive about this stuff, they like plausible deniability. So, why would they choose a method that provides a signed paper trail proving they did it?
So, where's the evidence? Without CT you could imagine that the spooks are snooping on everybody else and that's why you don't have any evidence -- they knew you were too smart, but with CT you can go look for evidence they snooped your grandmother's online bingo or your second cousin's Trump fandom forum, and well, seems like there just isn't any.
The Russians don't care if they're known to be doing crimes, that's why they sent assassins to England to murder an ex-spy and then offered the most stupid transparent lie about the men being "tourists". But the NSA is kinda sensitive about this stuff, they like plausible deniability. So, why would they choose a method that provides a signed paper trail proving they did it?
This is simplistic.
The security is found to be sometimes lax with these CAs. There have also been problems with audits, CTs and paper trail. I recommend this episode of the following podcast on security of CAs:
https://securitycryptographywhatever.buzzsprout.com/1822302/...
CTs help, but you really have to see who is behind them and how they are operated.
It’s known that hacking companies run CAs, accepted by Firefox and Chrome (at least for a period of time).
The security is found to be sometimes lax with these CAs. There have also been problems with audits, CTs and paper trail. I recommend this episode of the following podcast on security of CAs:
https://securitycryptographywhatever.buzzsprout.com/1822302/...
CTs help, but you really have to see who is behind them and how they are operated.
It’s known that hacking companies run CAs, accepted by Firefox and Chrome (at least for a period of time).
The beautiful thing with CT is that there will always be a paper trail.
Either the certificate is included in the CT log, then the web site operator can notice that an illegitimate certificate was issued. This makes this approach risky, and infeasible against big services (since they presumably monitor CT logs for misissuances for their domains).
Or it isn't included in the CT log, then the certificate itself is a digitally signed admission of incompetence by the CA, and IIRC at least some browsers will reject the certificate if it doesn't have a CT receipt (SCT) from at least one accepted log.
The remaining options would be to compromise (or compel) an accepted CT log to issue SCTs without recording the certificate. This would require attacking two entities, and if caught (i.e. the victim noticed the cert wasn't in CT), would mean the end of the log.
These do not guarantee that such an attack will be discovered or stopped, but let's not pretend that these didn't massively raise the stakes for attacks against CAs. Previously, if an intelligence service could get a CA to misissue a certificate, they could only be caught if the victim identified the certificate as misissued, stored a copy, and even then it'd become a he-said-she-said.
Either the certificate is included in the CT log, then the web site operator can notice that an illegitimate certificate was issued. This makes this approach risky, and infeasible against big services (since they presumably monitor CT logs for misissuances for their domains).
Or it isn't included in the CT log, then the certificate itself is a digitally signed admission of incompetence by the CA, and IIRC at least some browsers will reject the certificate if it doesn't have a CT receipt (SCT) from at least one accepted log.
The remaining options would be to compromise (or compel) an accepted CT log to issue SCTs without recording the certificate. This would require attacking two entities, and if caught (i.e. the victim noticed the cert wasn't in CT), would mean the end of the log.
These do not guarantee that such an attack will be discovered or stopped, but let's not pretend that these didn't massively raise the stakes for attacks against CAs. Previously, if an intelligence service could get a CA to misissue a certificate, they could only be caught if the victim identified the certificate as misissued, stored a copy, and even then it'd become a he-said-she-said.
Yes, in the absence of SCTs the certificate just won't work in Chrome, Safari or Edge.
You'd have to compromise at least the CA, and Google, and one other log operator. All the clients that care about SCTs have effectively the same requirement today, certificates must be logged by Google and by a trusted party which isn't Google. For example, you might get a certificate from Let's Encrypt, logged by Google and Cloudflare before it was delivered to you by Let's Encrypt.
You'd have to compromise at least the CA, and Google, and one other log operator. All the clients that care about SCTs have effectively the same requirement today, certificates must be logged by Google and by a trusted party which isn't Google. For example, you might get a certificate from Let's Encrypt, logged by Google and Cloudflare before it was delivered to you by Let's Encrypt.
So Firefox doesn't enforce CT, while everything else does?
This + some of the other news about how they handle privacy make me doubt how prudent it is to use Firefox, from a security/privacy perspective :(
This + some of the other news about how they handle privacy make me doubt how prudent it is to use Firefox, from a security/privacy perspective :(
That's correct. I believe one obstacle is the consideration that Google + one other (the policy in Safari, Chrome and Edge) doesn't look like a very neutral policy, but it would likely now be impossible to implement any other policy.
However, although Firefox doesn't check SCTs, I believe you can add an extension to do this with the same policy everybody else has. Also, in practice all CAs in Mozilla's trust programme more or less have to use CT because Mozilla's incident process assumes you have working CT logs.
But yes, it would definitely be better if Firefox just checked SCTs even if they have to suck it up on the policy neutrality for compatibility reasons.
It would also be be nice if all clients that check SCTs implemented a Gossip protocol, and some other steps to complete CT as originally conceived. As shipped, today's clients would not reveal e.g. a split horizon CT log visible only to some particular group. It's just that we have every reason to think that this tree is bare of fruit, and so meticulously searching the highest branches is a much higher cost for likely no extra reward.
However, although Firefox doesn't check SCTs, I believe you can add an extension to do this with the same policy everybody else has. Also, in practice all CAs in Mozilla's trust programme more or less have to use CT because Mozilla's incident process assumes you have working CT logs.
But yes, it would definitely be better if Firefox just checked SCTs even if they have to suck it up on the policy neutrality for compatibility reasons.
It would also be be nice if all clients that check SCTs implemented a Gossip protocol, and some other steps to complete CT as originally conceived. As shipped, today's clients would not reveal e.g. a split horizon CT log visible only to some particular group. It's just that we have every reason to think that this tree is bare of fruit, and so meticulously searching the highest branches is a much higher cost for likely no extra reward.
Now that CloudFlare is a thing there is an incredible obvious way to snoop encrypted data..
Not really.. i mean to sites whose owners set them up with cloudflare... sure but cdns aren't knew. Akamai,fastly,etc... are a thing. But it's not that different than compromising could provider or server hosting providers.
I think you misunderstand the purpose of dragnet, it is to identify targets of interest. Decrypting content is not needed, i mean it is desirable but even with sni encryption and DoH it is possible to identify targets of interest. Once identified,from what I have heard, they target your device or a common server targets of interest use, compromising those allows them to see much more than decrypted TLS.
Since we are speculating, what makes you so sure submarine cable tapping spies that can compromise cloudflare (or coerce) cannot do the same with say... Let'sEncrypt's root signing keys? They don't even have to mess with CT logs that way. Unless you are sayinf the handful of private keys used to encrypt most TLS traffic are impossible to compromise, even with nation state resources.
I think you misunderstand the purpose of dragnet, it is to identify targets of interest. Decrypting content is not needed, i mean it is desirable but even with sni encryption and DoH it is possible to identify targets of interest. Once identified,from what I have heard, they target your device or a common server targets of interest use, compromising those allows them to see much more than decrypted TLS.
Since we are speculating, what makes you so sure submarine cable tapping spies that can compromise cloudflare (or coerce) cannot do the same with say... Let'sEncrypt's root signing keys? They don't even have to mess with CT logs that way. Unless you are sayinf the handful of private keys used to encrypt most TLS traffic are impossible to compromise, even with nation state resources.
Collect all, decrypt if/when able.
Even if they can't, one of the key things to come out of Snowden's revelations was that the metadata of the state of the network alone is sufficiently interesting to be worth keeping. Unless everyone talks to everyone else with a constant bandwidth message, information _will_ leak. It's just a matter of "how much".
I'm always happy to see snowden mentioned, and how his leaks seemingly will never go away. One of my fears was that he would be forgotten in 1-2 years.
You can always keep the encrypted data until technology has advanced far enough to easily decrypt it.
There's an excellent chance you will wait forever.
I'm going to give the same example I always do. In 1977 they standardised DES. DES was already publicly known to be weak in two specific ways, the keys are too short (56-bits), and the block size is too small (64-bits). This was done intentionally. Today you can break DES... by exploiting these two weaknesses with today's cheaper hardware. No other meaningful attacks on DES worked, it has performed exactly as designed for well over forty years.
At the turn of the century DES was replaced by AES. AES has 128-bit or 256-bit keys, and 128 bit blocks. So, brute force attacks known to be viable for DES are never going to be possible for AES because physics. You would need one of those mathematical breakthroughs that never happened for DES in, as I wrote, almost fifty years. Don't hold your breath.
Because of this, encrypted material probably gets less valuable over time, as keys which did exist and might become available to you in future are instead lost or destroyed. And the pace accelerates. With TLS 1.2 it was plausible that you (assuming "you" are a powerful adversary able to do stuff like seize people's property) could seize a running HTTPS server and use its "ephemeral" secrets to decrypt traffic from yesterday, or maybe even last week, but in TLS 1.3 the mechanism is more fleeting, perhaps you can decrypt messages from ten minutes ago, but without the client's help perhaps not at all.
I'm going to give the same example I always do. In 1977 they standardised DES. DES was already publicly known to be weak in two specific ways, the keys are too short (56-bits), and the block size is too small (64-bits). This was done intentionally. Today you can break DES... by exploiting these two weaknesses with today's cheaper hardware. No other meaningful attacks on DES worked, it has performed exactly as designed for well over forty years.
At the turn of the century DES was replaced by AES. AES has 128-bit or 256-bit keys, and 128 bit blocks. So, brute force attacks known to be viable for DES are never going to be possible for AES because physics. You would need one of those mathematical breakthroughs that never happened for DES in, as I wrote, almost fifty years. Don't hold your breath.
Because of this, encrypted material probably gets less valuable over time, as keys which did exist and might become available to you in future are instead lost or destroyed. And the pace accelerates. With TLS 1.2 it was plausible that you (assuming "you" are a powerful adversary able to do stuff like seize people's property) could seize a running HTTPS server and use its "ephemeral" secrets to decrypt traffic from yesterday, or maybe even last week, but in TLS 1.3 the mechanism is more fleeting, perhaps you can decrypt messages from ten minutes ago, but without the client's help perhaps not at all.
Storage is almost free so you can easily afford to wait just about forever, you don’t need to crack AES to crack TLS because you can also crack the key exchange or find a weakness in the RNG or the algorithm and we all know everybody knows something is impossible until someone comes around and does it.
The perfect is the enemy of the good. By that I mean that there is no perfect security, at some point, if given long enough, security of any system (computer or otherwise) can/will be broken. The point is to slow it down for long enough that it is of no use.
I have to wonder what kind of information is useful enough to wait forever for? What kind of personal information of mine, for example, will be useful after I'm dead? There may be something.
Even if we look at state actors it doesn't change - if China's government manages to decrypt something the UK has that is useful now, like some advanced technology, will it still be advanced when its encryption is cracked? Slow them down for even 20 years and it'll be too long to wait.
I have to wonder what kind of information is useful enough to wait forever for? What kind of personal information of mine, for example, will be useful after I'm dead? There may be something.
Even if we look at state actors it doesn't change - if China's government manages to decrypt something the UK has that is useful now, like some advanced technology, will it still be advanced when its encryption is cracked? Slow them down for even 20 years and it'll be too long to wait.
These are generic platitudes that are not very useful. Obviously you can’t consider whether some random guys data is interesting when you are capturing it in an encrypted state. You just capture everything just in case. And who knows, a way might suddenly appear to decrypt all of it and then you won’t be happy if you didn’t capture it.
Yes, knowing that any data captured cannot be decrypted until after I’m dead is definitely generic as I don’t know anyone who will live long enough for decryption to happen in their lifetime, do you?
If not, then you’re wrong about it being a platitude because you’ve given absolutely no reason how that data will be useful, other than ”who knows, a way might suddenly appear to decrypt all of it”. Maybe they’ll also invent a time machine but I’d prefer to stick to the realms of reality rather than sci-fi when assessing risk.
If not, then you’re wrong about it being a platitude because you’ve given absolutely no reason how that data will be useful, other than ”who knows, a way might suddenly appear to decrypt all of it”. Maybe they’ll also invent a time machine but I’d prefer to stick to the realms of reality rather than sci-fi when assessing risk.
"Storage is almost free so you can easily afford to wait just about forever."
Forever is a long time. The point made above is valid, which is that data devalues greatly over time.
Take in point the famous case of the Zodiac Killer: https://en.m.wikipedia.org/wiki/Zodiac_Killer. Recent work seems to suggest that his encrypted messages are close to being solved (decrypted). If in fact we do have a solution and we've learned his identity then this information is of much less value now than if it would have been available 50+ years ago. For starters, it seems the killer is now dead. Thus, being able to decrypt his messages after this lengh of time is of little practical use other than of academic interest and or offering some resolution to his victims' families.
The value of encrypted data held by the NSA and GCHQ in anticipation of finding a decryption key will rot in exactly the same way. In short, it's only worth keeping the data whilst it's potentially useful.
Forever is a long time. The point made above is valid, which is that data devalues greatly over time.
Take in point the famous case of the Zodiac Killer: https://en.m.wikipedia.org/wiki/Zodiac_Killer. Recent work seems to suggest that his encrypted messages are close to being solved (decrypted). If in fact we do have a solution and we've learned his identity then this information is of much less value now than if it would have been available 50+ years ago. For starters, it seems the killer is now dead. Thus, being able to decrypt his messages after this lengh of time is of little practical use other than of academic interest and or offering some resolution to his victims' families.
The value of encrypted data held by the NSA and GCHQ in anticipation of finding a decryption key will rot in exactly the same way. In short, it's only worth keeping the data whilst it's potentially useful.
If DES had larger key sizes would it have remained uncracked?
3DES is essentially DES with larger key sizes (effectively twice as long, choosing 3 x 56 bit keys, ie 168 bits gets you a cipher equivalent to 112 bits of strength due to the meet-in-the-middle attack on such constructions) at a price of being three times as expensive to use. So, almost enough security to be acceptable, at a price of being far slower.
But, 3DES is still DES, the blocks are still 64 bits which is too small. Sweet32 is an example of a more-or-less practical attack (practical enough to demo, but probably never used in anger) that breaks 3DES for HTTPS by "just" moving a couple of hundred gigabytes of data over the wire.
Lucifer (the cipher that the NSA cut down to make DES) used 128-bit keys and 128-bit blocks. It is vulnerable to differential cryptanalysis (which the NSA knew about before academics discovered it, and so the NSA fixed it in DES). If you imagine Lucifer was instead fixed by a similar technique to the one used in DES but not shortened to provide a NOBUS there's no obvious reason Lucifer would be insecure today. There are most sophisticated analysis techniques than differential cryptanalysis today, but the defences in DES warded those off, and so you might expect similar for Lucifer.
But, 3DES is still DES, the blocks are still 64 bits which is too small. Sweet32 is an example of a more-or-less practical attack (practical enough to demo, but probably never used in anger) that breaks 3DES for HTTPS by "just" moving a couple of hundred gigabytes of data over the wire.
Lucifer (the cipher that the NSA cut down to make DES) used 128-bit keys and 128-bit blocks. It is vulnerable to differential cryptanalysis (which the NSA knew about before academics discovered it, and so the NSA fixed it in DES). If you imagine Lucifer was instead fixed by a similar technique to the one used in DES but not shortened to provide a NOBUS there's no obvious reason Lucifer would be insecure today. There are most sophisticated analysis techniques than differential cryptanalysis today, but the defences in DES warded those off, and so you might expect similar for Lucifer.
What are you practically going to do with the decrypted secret records of Phillip II of Spain (1556 – 1598), the James A Garfield administration (1881), or suspected spy Joe Bloggs of San Francisco 1930-2000 ?
If nothing else, it can increase our understanding of history: https://www.sciencenews.org/article/marie-antoinette-letters...
It's probably cheaper to scrape all the keys than try to crack it
During the cold war both sides recorded everything because they realised that today's "unbreakable" encryption would be nothing in 10 years time. That's not quite so true anymore as Moores law is stumbling, but it's still a pretty cheap strategy, you just need a big pile of storage...
I hate it when people say that, especially when they know very well bruteforce isn't exactly the only way to break a cipher. I think if theu are honest, they all admit all of it is speculation (educated, but still), no one knows if there will be a discovery in physics, mathematics or information theory that can undo a cipher. Or even just a weakness in the cipher.
Do you really think they would allow HTTPS if they couldn't read it?
It's unlikely that "they" can break TLS protected traffic at scale, however, it's likely that they don't need to.
Usually, TLS is terminated on a load balancer and then the data in the data-centre flows in clear text. I is good practice to encrypt internal traffic but few companies do it because of the overhead. So "they" could sniff unencrypted traffic there, if they pay the data-centre providers.
Also, NSA is known to have modified network gear [1], so if they do that on a load balancer (or hack a software one) they can just sniff the encrypted traffic downstream and extract the session keys from the equipment. Then they can just decrypt the traffic without having to actually break RSA/ECC.
Other governments have had less subtle approaches by doing MITM attacks with compromised certificate roots, which is now somewhat mitigated with certificate pinning in modern browsers.
And of course there is the topic of secure protocols but compromised by design apps, such as WhatsApp. Even admitting that the Signal protocol is implemented correctly in WhatsApp, because the app is closed-source, they can read the unencrypted traffic from the app itself, and if they get caught doing it, they can say it's for moderation purposes [2].
If all of the above fails, you can always rely on Pegasus or similar. Once you have a rootkit on the device, you have access to everything in clear-text.
[1] https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa... [2] https://gizmodo.com/whatsapp-moderators-can-read-your-messag...
Usually, TLS is terminated on a load balancer and then the data in the data-centre flows in clear text. I is good practice to encrypt internal traffic but few companies do it because of the overhead. So "they" could sniff unencrypted traffic there, if they pay the data-centre providers.
Also, NSA is known to have modified network gear [1], so if they do that on a load balancer (or hack a software one) they can just sniff the encrypted traffic downstream and extract the session keys from the equipment. Then they can just decrypt the traffic without having to actually break RSA/ECC.
Other governments have had less subtle approaches by doing MITM attacks with compromised certificate roots, which is now somewhat mitigated with certificate pinning in modern browsers.
And of course there is the topic of secure protocols but compromised by design apps, such as WhatsApp. Even admitting that the Signal protocol is implemented correctly in WhatsApp, because the app is closed-source, they can read the unencrypted traffic from the app itself, and if they get caught doing it, they can say it's for moderation purposes [2].
If all of the above fails, you can always rely on Pegasus or similar. Once you have a rootkit on the device, you have access to everything in clear-text.
[1] https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa... [2] https://gizmodo.com/whatsapp-moderators-can-read-your-messag...
"Also, NSA is known to have modified network gear <...> they can just sniff the encrypted traffic downstream and extract the session keys from the equipment. Then they can just decrypt the traffic without having to actually break RSA/ECC."
Exactly, this fact seems to have been lost on many. There's nothing wrong with using encryption on a day-to-day basis such as when we use https web pages, or buy something online, or when we don't want Google to read our email but it's another matter altogether when the stakes are much higher such as, say, leaking human rights abuses from within the confines of a totalitarian state.
When the stakes are high there are many other considerations to address. Not only do you have to consider what happens inside a server but also think about its physical security along with the possibility that data recovery tools may be used by the State to recover a copy of a critical email you sent after which you deleted. And that's just for staters.
An important rule to always assume and to adhere to before going online is that it's a safe bet that the State will be able to access anything you say or do on your PC, smartphone and or when you are online - and that it will be able to do so long after the event.
Exactly, this fact seems to have been lost on many. There's nothing wrong with using encryption on a day-to-day basis such as when we use https web pages, or buy something online, or when we don't want Google to read our email but it's another matter altogether when the stakes are much higher such as, say, leaking human rights abuses from within the confines of a totalitarian state.
When the stakes are high there are many other considerations to address. Not only do you have to consider what happens inside a server but also think about its physical security along with the possibility that data recovery tools may be used by the State to recover a copy of a critical email you sent after which you deleted. And that's just for staters.
An important rule to always assume and to adhere to before going online is that it's a safe bet that the State will be able to access anything you say or do on your PC, smartphone and or when you are online - and that it will be able to do so long after the event.
Yes, if they have alternative means to discover that data. "They" don't need to decrypt TLS but if they did, they could. We are speculating here.
The only benefit of https today seems to be planned obsolescence. There are a lot of certificates issued by states or organization which cannot be reasonable trusted. Also in case of a lot of OS' (android, ios, Macosx, windows) you do not control your endpoint. So i do not see any added benefit for https.
> So i do not see any added benefit for https
Doesn't it, at least, protect against snooping by (most) non-state actors? I'm pretty sure MI6 can break into my house, that doesn't mean I'm going to give up on locking my door.
Doesn't it, at least, protect against snooping by (most) non-state actors? I'm pretty sure MI6 can break into my house, that doesn't mean I'm going to give up on locking my door.
I operate under the assumption that all transatlantic cable endpoints and satellite down links and large-scale ISPs are already compromised. Maybe not as obvious as having a dedicated “NSA Room”, because the tech has progressed to the point where it’s no longer necessary.
The smaller fry may or may not be compromised, but it wouldn’t take more than trivial effort for them to become compromised if the NSA wants in.
Any commercial VPN you can install, is likewise already compromised. You could install your own endpoints at a service provider, but all those service providers are already compromised (see above).
I’m sure that TOR was hard for them, and may still offer some challenges, but I’d be really surprised if they can’t compromise it when they want to.
And I’m also certain that I personally remain a person of interest for them, based on some things I said back during Crypto Wars I. I’m sure there’s a lot of people above me in the list, but I’m also certain it’s a fairly long list and that I’m on it.
So, I think the only thing a reasonable person can do is to continue to operate their lives, make sure they address the non-nation-state attackers that they can, and try not to attract the attention of the NSA.
The smaller fry may or may not be compromised, but it wouldn’t take more than trivial effort for them to become compromised if the NSA wants in.
Any commercial VPN you can install, is likewise already compromised. You could install your own endpoints at a service provider, but all those service providers are already compromised (see above).
I’m sure that TOR was hard for them, and may still offer some challenges, but I’d be really surprised if they can’t compromise it when they want to.
And I’m also certain that I personally remain a person of interest for them, based on some things I said back during Crypto Wars I. I’m sure there’s a lot of people above me in the list, but I’m also certain it’s a fairly long list and that I’m on it.
So, I think the only thing a reasonable person can do is to continue to operate their lives, make sure they address the non-nation-state attackers that they can, and try not to attract the attention of the NSA.
[deleted]
How do these programs impact China collection, if at all? Are they able to collect Chinese SIGINT of any significance through these cables, or does the 'Golden Shield Project' and 'Great Firewall' prevent info from going out?
Well, national traffic will usually not land on these cables so they need other means to intercept it.
https://www.aerosociety.com/news/eavesdropping-from-space/
https://www.aerosociety.com/news/eavesdropping-from-space/
Great write up. I would recommend the checking out:
Documentary about the cable landing stations: The Secrets of Cornwall
https://www.youtube.com/watch?v=K_nnUbX7uuQ
Documentary about the cable landing stations: The Secrets of Cornwall
https://www.youtube.com/watch?v=K_nnUbX7uuQ
[deleted]
"It's not just a US problem. The UK has a huge dog in this fight," Snowden told the Guardian. "They [GCHQ] are worse than the US."
I'm not sure if I've got the picture right. Someone more informed than I please help.
First, let us set the scene with a precedent - the famous WWI Zimmermann Telegram of 1917 where Germany and Mexico were concocting a secret deal that wasn't in the interests of the US or UK which was tapped and successfully intercepted: https://en.m.wikipedia.org/wiki/Zimmermann_Telegram.
I only mention this 100-year-plus case as it'd be at the forefront of any planning for any undersea cable, transatlantic otherwise to see such incidents are not repeated. OK, so where are my assumptions wrong here?
1. Cable operator of say US-UK link doesn't want a tap put on cable in mid Atlantic by a third country so takes the necessary steps by encrypting all its data.
2. Cable operator knows both US/NSA and UK/GCHQ will want to tap cable at their respective ends (i. e.: on land). No problem, as the cable operator has no say in the matter anyway.
3. To stop undersea tapping by third party, cable is encrypted at cable stations at either end. Multiple levels of encryption are employed: fibers are encrypted either individually or collectively so only a raw encrypted datastream appears on the undersea section of circuit; that is, the only discernible IP address information on the cables is that necessary for the cable stations at either end to TX/RX data across the Atlantic. Thus an attack in the middle won't reveal who is using the cables nor their IP addresses (as they too will be encrypted as part of the overall encrypted datasteam).
4. Third-party counties, for argument sake, say Mexico and Germany that are also using the cable will similarly encrypt and obfuscate the source and destination IP addresses of all their users in a similar manner using an all-encompassing encrypted datastream. So effectively the NSA and GCHQ can only inspect their own local traffic, which they do on land at their respective cable stations after the undersea section of the link has been decrypted.
5. As, we've made Mexico and Germany the adversaries, we can expect them to not only encrypt data and obfuscate source and destination IP addresses of their users by multiplexing all data into a common encrypted datastream but also obfuscate the amount of traffic they're sending. They will likely achieve this obfuscation by using say an encrypted token ring/FDDI-like system, then the datastream would appear to be a constant quantity irrespective of the actual circuit load.
6. In essence, why do countries still try to tap undersea cables with submarine taps when they'd only pick up encrypted 'garbage'? Alternatively, why do cable users leave themselves vulnerable to tapping when they could employ methods to obfuscate not only their data but also how they are loading (using) said cables?
Right, I've greatly oversimplified the issue but the gist of my point is there.
I'm not sure if I've got the picture right. Someone more informed than I please help.
First, let us set the scene with a precedent - the famous WWI Zimmermann Telegram of 1917 where Germany and Mexico were concocting a secret deal that wasn't in the interests of the US or UK which was tapped and successfully intercepted: https://en.m.wikipedia.org/wiki/Zimmermann_Telegram.
I only mention this 100-year-plus case as it'd be at the forefront of any planning for any undersea cable, transatlantic otherwise to see such incidents are not repeated. OK, so where are my assumptions wrong here?
1. Cable operator of say US-UK link doesn't want a tap put on cable in mid Atlantic by a third country so takes the necessary steps by encrypting all its data.
2. Cable operator knows both US/NSA and UK/GCHQ will want to tap cable at their respective ends (i. e.: on land). No problem, as the cable operator has no say in the matter anyway.
3. To stop undersea tapping by third party, cable is encrypted at cable stations at either end. Multiple levels of encryption are employed: fibers are encrypted either individually or collectively so only a raw encrypted datastream appears on the undersea section of circuit; that is, the only discernible IP address information on the cables is that necessary for the cable stations at either end to TX/RX data across the Atlantic. Thus an attack in the middle won't reveal who is using the cables nor their IP addresses (as they too will be encrypted as part of the overall encrypted datasteam).
4. Third-party counties, for argument sake, say Mexico and Germany that are also using the cable will similarly encrypt and obfuscate the source and destination IP addresses of all their users in a similar manner using an all-encompassing encrypted datastream. So effectively the NSA and GCHQ can only inspect their own local traffic, which they do on land at their respective cable stations after the undersea section of the link has been decrypted.
5. As, we've made Mexico and Germany the adversaries, we can expect them to not only encrypt data and obfuscate source and destination IP addresses of their users by multiplexing all data into a common encrypted datastream but also obfuscate the amount of traffic they're sending. They will likely achieve this obfuscation by using say an encrypted token ring/FDDI-like system, then the datastream would appear to be a constant quantity irrespective of the actual circuit load.
6. In essence, why do countries still try to tap undersea cables with submarine taps when they'd only pick up encrypted 'garbage'? Alternatively, why do cable users leave themselves vulnerable to tapping when they could employ methods to obfuscate not only their data but also how they are loading (using) said cables?
Right, I've greatly oversimplified the issue but the gist of my point is there.
Encryption at these data rates was only recently within the realm of feasibility (wrt cost).
You can always encrypt traffic that needs it at higher layers; most of these sorts of links were not themselves bulk encrypted.
MUSCULAR, for example, allowed the spies to tap WAN links between Google sites, which were at the time unencrypted as it was only Google-internal, even though it went hundreds of miles out of the buildings.
Those links are encrypted now. Google SREs were not happy about being hacked by the NSA.
I was told by SREs that they weren't encrypted before due to the CPU overhead that it would entail, as Google moves a lot of data. Once the threat wasn't theoretical, they were encrypted quickly.
You can always encrypt traffic that needs it at higher layers; most of these sorts of links were not themselves bulk encrypted.
MUSCULAR, for example, allowed the spies to tap WAN links between Google sites, which were at the time unencrypted as it was only Google-internal, even though it went hundreds of miles out of the buildings.
Those links are encrypted now. Google SREs were not happy about being hacked by the NSA.
I was told by SREs that they weren't encrypted before due to the CPU overhead that it would entail, as Google moves a lot of data. Once the threat wasn't theoretical, they were encrypted quickly.
"You can always encrypt traffic that needs it at higher layers; most of these sorts of links were not themselves bulk encrypted."
I'm surprised that encryption wasn't (still isn't) the default for all submarine cables given the very high stakes involed - international espionage, their vulnerability and the long history of undersea cable tapping (which I didn't mention above).
You say "Encryption at these data rates was only recently within the realm of feasibility". Right, but 'recently' has been quite a while now - I'd estimate 10-20 years or so as we've had erbium optical switches, etc., in common use for that length of time.
It's now over 25 years since I was first involved in some high-stakes intergovernmental stuff where authentication and encryption were the normal default thinking (it was inconceivable that we'd transmit data across any link or network that was potentially vulnerable to attack unless the data was encrypted and full authentication was deployed). We used common carrier networks and submarine cables would have to have been involved but we did not administer them - hence our assumption that they were vulnerable to attack.
Whilst I wasn't involved directly with those security services, it was clear to me that at the time they didn't want encrypted circuits. Thus, it seems likely that at least part of the reason for the lack encryption even now would have been pressure from them not to deploy it in common-carrier networks.
I'm surprised that encryption wasn't (still isn't) the default for all submarine cables given the very high stakes involed - international espionage, their vulnerability and the long history of undersea cable tapping (which I didn't mention above).
You say "Encryption at these data rates was only recently within the realm of feasibility". Right, but 'recently' has been quite a while now - I'd estimate 10-20 years or so as we've had erbium optical switches, etc., in common use for that length of time.
It's now over 25 years since I was first involved in some high-stakes intergovernmental stuff where authentication and encryption were the normal default thinking (it was inconceivable that we'd transmit data across any link or network that was potentially vulnerable to attack unless the data was encrypted and full authentication was deployed). We used common carrier networks and submarine cables would have to have been involved but we did not administer them - hence our assumption that they were vulnerable to attack.
Whilst I wasn't involved directly with those security services, it was clear to me that at the time they didn't want encrypted circuits. Thus, it seems likely that at least part of the reason for the lack encryption even now would have been pressure from them not to deploy it in common-carrier networks.
It isn't very high stakes, as all the important stuff is already encrypted at higher layers (TLS, VPNs, or both) before it hits the cable, whether the submarine cable is encrypted or not.
Only private industry was pretending long haul cables were reasonably private, and even they aren't making that mistake anymore.
Only private industry was pretending long haul cables were reasonably private, and even they aren't making that mistake anymore.
Right, as I mentioned important stuff is encrypted before it hits the cable. However, my point was that by encrypting submarine cables we introduce a whiff of steganography into the play. Cables using encrypted data streams sans source/destination/IP addresses info make neutral territory - the ocean bottom - redundant for third parties to snoop. When forced onto land their presence is more likely to be detected and after cable station fanouts/distribution points the common tap points no longer exist thus greatly complicating their spying efforts.
> GCHQ ... only pick up encrypted 'garbage'?
Maybe that's why they chose to be known by an acronym for "Garbage Collection Headquarters"
Maybe that's why they chose to be known by an acronym for "Garbage Collection Headquarters"
GHCQ? The mens fashion magazine is tapping internet cables? Why?
GHQ may have very good reasons to tap cables, especially in stylish cable tapping menswear.
With the proliferation of VPNs in recent years, many people are going to be targeted then, which perhaps is a good thing (the more people that leverage encryption for Internet privacy the better).
NSA & GCHQ must be getting very tired of all this cryptography, which has me thinking they have compromised several VPN companies or setup several VPN honeypot companies for their own purposes.
Another thing: being targeted with exploits because you use Tor must be an interesting thing to happen to you. I use secure endpoints and monitor all my traffic, and I've been using Tor since its inception.
Maybe they just don't want to target me because my systems are so hardened? I remain humble however, as everything can be hacked. Whatever exploits they have targeted me with, must be very good because I haven't spotted anything malicious (yet!).