Is this the beginning of a new anti-encryption push? First, we have a new phrase, "extreme end to end encryption". That's new, and it's an attempt to reframe the discussion. There are new legal theories.
Who's writing this? Who is "Anthony Rutkowski, Principal, Netmagic Associates LLC"? Hoovers has some basic company information.[1] The company address is a tract house in Auburn, VA. There's a self-provided bio available:
(Anthony Rutkowski) has over 45 years of experience in Industry and regulatory affairs with focus on global cybersecurity, lawful interception, retained data, identity management and network forensics. Anthony has held key positions at VeriSign, SAIC, General Magic. Sprint International and GE. Additionally, he has held important posts and positions at FCC, ITU, ETSI, and OASIS.[2] So this is a guy from the wiretapping (er, "lawful intercept") industry.
But that organizational identification is deceptive. Yaana lists him as their "Executive VP of Standards & Regulatory Affairs". What's Yaana? Outsourced Big Brother. "Yaana is a leading global provider of a wide range of intelligent compliance solutions including lawful interception, accurate data retention, big-data search & disclosure, advanced security and application specific analytics."[3]
"Middlebox Security Protocol" is also a new phrase. That's listed as a work item at the European Telecommunications Standards Institute. (Not the IETF).[3] The proposer is listed as "RUTKOWSK". Hmm. No version is available for download. The summary is "Specify protocols to enable trusted, secure communication sessions between network endpoints and one or more middleboxes between them using encryption."
This seems to be plugging something called mcTLS.[4] Here's the actual paper.[5] It's a halfway reasonable idea for allowing middleboxes to work with encrypted streams, without giving them full access to the content. But it has built-in back doors, for "performance". See section 3.6 of[5]. It's also really complicated, and if done wrong, breaks end to end security. That may be Rutkowski's plan.
With minor edits, this could pass for a generation-old article advocating to regulate PGP and standardize on encryption with the Clipper chip. The main innovation is calling secure end-to-end encryption "extreme" end-to-end encryption.
Other than the fact that the author clearly views any means by which people can communicate electronically in total privacy as a form of "extremism" he does highlight some scary stuff. It really is only a matter of time before some judge allows someone to sue some company for end-to-end encryption because that person may have had a conversation which resulted in a bad deed. That's more scary than anything else I've read in a long time.
I think the real danger is that if the government starts regulating end-to-end encryption we're going to end up in a Kafka-esque situation like we have with radio encryption - i.e. the technology is freely available off the shelf, but any attempt to actually use it without the right license or on the wrong frequency, etc., can suddenly turn into a federal felony.
This is not scary. People communicate in secret all the time. It can be done with a piece of paper in a lockbox at a bank.
It's one thing if the bank refuses to let the FBI into one of the lockboxes they use. It's another thing entirely if the bank says, "We don't have a key. Nothing we can do to help you." The latter is E2E encryption.
To pick a nit, if there is one type that can be legitimately called "extreme" encryption it would be one-time-pads that were generated from truly random sources and distributed out of band.
With other types of encryption the math works (to various degrees) towards making brute-force decryption so time consuming that either the message would be worthless once it is decrypted, or the time horizon is otherwise beyond what is feasible. However, what math gives, math can also take away. Advances in cryptanalysis algorithms or sideband attacks could expose the message at any given point in the future. There may even be known attacks by three-letter agencies or other adversaries.
However, with a one time pad, given that the pad was truly randomly generated, was not exposed during distribution and is destroyed on each side upon encryption/decryption, the plaintext can NEVER be known.
Without an attacker with a time machine, the procedure is 100% airtight.
Exactly. As a thought experiment, it's fairly trivial to set up an OTP communications scheme - like doing one from scratch in less time than it takes to order a pizza. It's traditionally been low-bandwidth, but as storage shrinks, sneakernetting enough material for high bandwidth use becomes much simpler. I can only imagine that practical OTP will be the penultimate step in the crypto wars. As far as brute-force for E2E, logjam is a great example, but I'm guessing there's a new state of the art.
Extreme End to End Encryption isn't good enough anymore. Me and all my zealot friends have decided, in our sole and unreviewable discretion as ultimate authorities in determining the righteousness of our actions, to standardize and mandate the use of Ultra Extreme End to End Encryption (UEE2EE)
Not only will we deny others access to our secret content, we will render the metadata we create useless for any investigative purpose.
Looking at his bio and other columns, this guy seems to be hailing from the old school telephone world, itu-t have long worked with governments and and treaties to prevent confidentiality in voice/SMS comms.
oops, he lost control of his carefully crafted narrative:
>However, this balance seems unsatisfactory to encryption zealots who are hellbent on leading an extremist vanguard toward some nirvana of ultimate e2e encryption.
1. A lame attempt at reframing the language of communications security as "extreme." Would he call a collision avoidance system in a car "extreme safety?"
2. Utter blindness to the danger of making numbers and algorithms into contraband. As in despotic regimes, we would then have government chasing down users of prohibited software and ultimately the possessors of prohibited knowledge.
The government can always compromise the safety of your car, unless you manage to make one that is bulletproof, can pass through barriers, and is immune to being crashed into. But I think such a car would be called a tank, and you'd be in even more trouble.
I was just sitting here having some extreme private thoughts, by employing extreme military grade unlicenced privacy techniques based on extreme not speaking.
One thought I'll responsibly disclose to official authorities though, so network managers can efficiently manage on their networks, is: "Was this dude about to cry?"
It’s extremely important that we overcome the rage (after those fully justified 5 minutes) and take coordinated and reasoned action, because this kind of attacks on encryption, depicting it as immoral or unpatriotic or irresponsible, is only starting, and it is a coordinated, well funded and professionally run campaign. This is just one of many aspects (fake grassroots, astroturfing), I expect many many more to come, more or less coincidentally, all in a rather short amount of time, conveniently accompanied by “shock-factor” news articles where the inability to break proper encryption results in kids or puppies getting killed and captured on camera, or some terrorist carrying out an attack - see the San Bernardino iPhone case.
All the while lawmakers constantly try to slip shit into regulations and trade treaties.
It’s very important we collect and organize and maintain a massive list of counter-evidence and counter-arguments because these attacks won’t stop.
Evidence in the hand of smart, eloquent people, at the right moment (e.g. when asked on camera or in some official proceeding) can be immensely effective, at least in functioning democracies, which I believe America still is.
Do we have an infinite, free supply of perfect moments and of smart, eloquent people?
hell no.
Thus we better have evidence at hand for when the stars align and we get those circumstances, lest they go wasted.
Who's writing this? Who is "Anthony Rutkowski, Principal, Netmagic Associates LLC"? Hoovers has some basic company information.[1] The company address is a tract house in Auburn, VA. There's a self-provided bio available:
(Anthony Rutkowski) has over 45 years of experience in Industry and regulatory affairs with focus on global cybersecurity, lawful interception, retained data, identity management and network forensics. Anthony has held key positions at VeriSign, SAIC, General Magic. Sprint International and GE. Additionally, he has held important posts and positions at FCC, ITU, ETSI, and OASIS.[2] So this is a guy from the wiretapping (er, "lawful intercept") industry.
But that organizational identification is deceptive. Yaana lists him as their "Executive VP of Standards & Regulatory Affairs". What's Yaana? Outsourced Big Brother. "Yaana is a leading global provider of a wide range of intelligent compliance solutions including lawful interception, accurate data retention, big-data search & disclosure, advanced security and application specific analytics."[3]
"Middlebox Security Protocol" is also a new phrase. That's listed as a work item at the European Telecommunications Standards Institute. (Not the IETF).[3] The proposer is listed as "RUTKOWSK". Hmm. No version is available for download. The summary is "Specify protocols to enable trusted, secure communication sessions between network endpoints and one or more middleboxes between them using encryption."
This seems to be plugging something called mcTLS.[4] Here's the actual paper.[5] It's a halfway reasonable idea for allowing middleboxes to work with encrypted streams, without giving them full access to the content. But it has built-in back doors, for "performance". See section 3.6 of[5]. It's also really complicated, and if done wrong, breaks end to end security. That may be Rutkowski's plan.
[1] http://www.hoovers.com/company-information/cs/company-profil...
[2] https://www.yaanatech.com/author/tony/
[3] https://www.yaanatech.com/about-us/
[4] https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.a...
[5] https://www.mctls.org/
[6] https://davidtnaylor.com/mcTLS.pdf