A one-time pad is also unbreakable. What makes quantum cryptography any better?
In some ways QC is worse than OTP because quantum crypto still requires classical basis of trust to authenticate communication partners.
What makes QC useful is it allows production of new OTP material from a provably private well completely "disconnected" from the classical communication channel.
There are a number of methods for re-keying without QC but they are based on deterministic algorithms where if you were to get your hands on the "previous" state you would stand some chance of being able to derive subsequent states... with QC that chain is broken.
Quite frankly I doubt it really provides much in the way of any real world benefit because a system is only as good as its weakest link and you still have to bind the quantum system using classical cryptographic methods subject to the same attacks we're all quite familiar with already. Keep a massive OTP codebook secret or keep a smaller secret and use QC... same problem either way.
To see the problem, imagine 2 wormholes, A and B, each with widely separated endpoints. In my reference frame, the endpoints A1 and A2 are stationary - I'm standing by A1 and can send a message instantly to A2. The endpoints B1 and B2 are stationary relative to one another, but are moving close to c relative to A. In B's reference frame, my message goes back in time.
Sounds like adding vectors while neglecting Lorentz. When you travel thru such a wormhole you gain only incidental mass and potential energy as observed by an external frame stationary to wormhole, you don't see the universe contracting to a point, your observers don't see your mass increasing or your clock slowing. No observer ever gets to see your mass/energy dwarfing the rest of the universes and there isn't any backwards time travel. You can't add or subtract the apparent external velocity of messages thru wormhole with the differential velocity of another wormhole whizzing by.
A simpler example: you can get a straightforward time machine simply by accelerating one end of a wormhole up to relativistic speed for a few years, and then bringing it back, parking it at rest near the other end. Like the twin who visits a distant star and returns, one end will be "younger" than the other. Now the wormhole moves you back (or forward) in time by a few years when you traverse it.
I agree that one end will be younger but later after they are parked traveling through it won't send you backward in time and you'll only go as forward in time as it actually takes the travel through.
To violate ordering of cause and effect you need to actually exceed C not just *appear* to exceed it.
If I were to magically snap my fingers and magically materialize between "earth" and "earth2" 100 light years away without having propagated thru space I am free to make whatever measurements I want between either planets and leak all the information I can find and at no point will any observer in any frame be able to detect an inversion of cause and effect.
OK, I tried to read your first sentence 3 times, and I still can't parse it, so I'm not sure what you're saying. Naturally, slower-than-light state transfer doesn't introduce paradox. FTL state transfer does allow inversion of cause and effect - the clear examples of this involve two pairs of wormholes, moving quickly relative to one another, which allows you go send a signal out through one pair and back through the other, and get the signal before you sent it.
The only thing that matters is propagation. Lets say I can only go 10 spaces in 10 ticks.
- - - - - - - - - - 1.................10
Now lets try covering the same external distance through a wormhole:
- - - 1.................3
Well I went 3 spaces in 3 ticks... but the rest of the universe thinks I went 10 spaces...silly fools.
You just think FTL propagation because your losing track of the configuration of space through which the propagation is being done. Your assuming the result matters when what really matters is HOW you got there.
Wormholes can connect two arbitrary points in spacetime - this allows FTL travel,
but that means time travel, with raises all sorts of paradoxes.
Instantaneous state transfers which don't operate by means of propagation or the taking of shortcuts traveling less than FTL locally thru said mystical shortcut raise no paradox of any kind in any frame of reference. There is no grandfather paradox or inversion of cause and effect.
You implicitly assume that sites get most of their traffic from any search engine. Plenty of sites don't.
Because most do.
Plenty of sites don't.
Given number of sites out there "plenty" can be used to describe anything.
Intranet sites obviously don't rely on public search engines.
Pencils don't rely on public search engines either.
Of the commercial projects I currently work on -- and there are several, because I do freelance/consultancy work -- I don't think any gets the majority of its visitors from search engines, and in some cases if Google disappeared tomorrow you'd hardly notice on the bottom line.
Google pulls in tens of billion a year in paid revenue a year. Obviously someone cares a whole lot.
He's saying that if your visitors are primarily coming from search engines, then your site can ignore what search engines want without harm because being downranked by them won't hurt you.
??? If you get most of your traffic from search engines then you can ignore search engines and it won't matter? Say what?
Plenty of sites get most of their visitors from regular readers rather than from search engines.
Plenty more don't.
Sites are able to choose not to use Google, by the way. It just takes a small edit to your robots.txt file to get Google to completely ignore your site.
The site discovery process is dominated by the use of Google. What site owners chose to put in their robots.txt file has nothing to do with this reality.
don't think google is a monopoly -- there are lots of other search engines who drive reasonable amounts of traffic. But they are certainly the Big Dog.
We live in completely separate universes. The stats I care about show Bing in second place behind Google with a whopping 2% of Google's traffic. Followed by Yahoo at 31% of Bings pathetic 2%.
Nonetheless, there is a three-way symbiotic relationship here. If Google pushes so hard that sites stop caring about their google rankings, then Google's relevance will fall.
I think if sites stopped caring about their Google rankings then Google's relevance would increase since people would be more likely to find what their actually interested in vs dealing with aftermath of billions locked up in efforts to p0wn google search results.
The way it fails is when Google algorithms make bad decisions based on largely irrelevant criteria.
If enough people find Google to suck more than the alternatives, the Google's relevance will fall.
I'd be the first to agree that Google shouldn't get to dictate how the Web works and that sometimes Google or at least some its
They shouldn't get to dictate how the web works but then you basically say don't like it don't use Google... I'm confused... are sites able to chose not to use Google? What sites gets most of their traffic from a different search engine?
However, if you're relying on Google's service for most/all of your visitors to find your site at all, you have to play by their rules if you want the best treatment from them. This is the basic principle of SEO, and it's as old as search engines themselves.
What happens when those rules begin to stray from principals fewer people agree with? Google is more or less a monopoly.
You can always count on the Internet to implement good concepts poorly and parade the result as cutting edge technological innovation.
One thing I've always liked about HTML was from very early days before even CSS or Google the "promise" of targeting vast arrays of client form factors with the same information. This sounded great but proved in to be mostly unnecessary and divorced from reality.
Rise of "Responsive" sites more often than not translate back into frustrated desktop, laptop and tablet users with sites resembling pre-tables era childish web layouts boasting comically large fonts and painfully low information density. Paradoxically these "features" persist even when viewed from my mobile phone with the same display resolution as a large HD TV or desktop monitor. Very few appear to actually be capable of designing single scalable sites that don't suck.
There was a time when mobile sites were necessary. Given the proliferation of display sizes, LTE, multi-core multi-ghz processors with GBs of RAM.. that time has came and gone. Google is trying to catch up to a need that for the most part was already solved by hardware and software innovation and no longer exists.
If your going to punish sites for not as judged by a naive non-human algorithm offering something that is not "appealing" to a human using a client of a specific form factor or capability then do so across the board without bias. When I do a Google search from my desktop penalize all search results that consist of mobile handset optimized sites with comically large fonts and childish layouts.
What determines the worth of a website to me has never been layout it has been content and lack of annoying BS. All "looks over brains" does is give legions of spam trap link-baiting sites an even greater advantage.
Stupid all around to say nothing of negative implications of people waking up to the dangers of Aggregation of power into the hands of so few.
I quite like vastly increased difficulty of scanning the whole IPv6 Internet. As soon as Comcast fixes their business class remote access via IPv4 is going bye bye. Sick of looking at all this crap in my logs. If random fools want to spam me they are going to have to work for it.
And WaffleMonster just wants to bash Google for his/her own benefit (i.e. paid by MS).
Was in the room for delivery of one-sided Google presentations touting benefits of aggressive congestion schemes and ICW settings during TCPM meetings. I honestly fear ease at which clients and servers can cheat and tinker for competitive advantage with completely user land stacks embedded in applications.
Wording was probably a little unfair and oversimplified yet I believe in the general theme. I don't work for a large corporation and have little interest in this space other than promotion of an open decentralized Internet.
I disagree. To me there's at least one really compelling reason: To push universal encryption.
Too bad the goal was not pushing universal security instead.
One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.
What we need are systems that are actually secure not ones that pretend to be. Hard to get excited about a "feature" that is worthless against most threats.
True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least.
Is there a technical barrier with respect to TCP and or TLS that makes addressing issues unrealistic? Linux kernel has had TFO support for years and it didn't take decades for SYN cookies or SACKs to hit all but the long tail. There must be at least a dozen or two TLS extensions by now. How hard can it be from a technical perspective to tweak session tickets or whatever vs throwing everything out and reinventing wheels?
QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself.
Not sure retrofitting IP stacks into applications qualifies as a feature. More of the same thing duplicated everywhere usually means a bigger headache for all.
Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.
These are political not technical arguments. Heads of state routinely whine about not being "king" yet there are advantages to not so easily having your way.
I totally understand why Google is doing what their doing. If you own the net stack and the browser and the servers and are a big enough player this is a completely understandable and logical approach to accomplish your goal.
As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value.
I'll assume it can cost nothing in terms of CPU, I/O or Time.
A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful.
Not everyone has the same problems or constraints. Caution against mapping your experiences onto the rest of the world and drawing conclusions from it.
I may need to use a specialized security layer.
I may care about the ability for agents to passively monitor a telemetry stream.
I may care only about integrity of a message.
I may be prohibited by law or corporate rules from encrypting data.
I may have a mission critical system where any use of encryption is an unnecessary potential for failure.
Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.
Yes at a minimum any TCP + TLS solution would require minimum 2 separate unavoidable round trips - one for TCP and a second for TLS regardless of construction if state / cookies / tickets / whatever were not available for TCP and or TLS. So what?
Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack). A feature QUIC does not provide.
Managing transport and encryption in a single protocol makes the resulting system more brittle and complex. Improvements to TCP helps everything layered on top of it. Improvements to TLS helps everything layered on top of it.
Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.
QUIC integrates a TLS layer into it, in a way that avoids a lot of connection setup time.
TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.
I have yet to hear a coherent architectural justification for QUIC that makes sense... The reason Google pushes it is entirely *POLITICAL* this is the path of least resistance granting them full access to the TCP stack and congestion algorithms without having to work to build consensus with any other stakeholder.
or do you just stand against genetic engineering as we currently practice because you have an ignorant fear of what you don't understand?
I fear the properties of roundup ready GMO crops are being leveraged to optimized labor costs during production increasing loads of roundup leeching into the food supply.
People say roundup is safe yet nobody has been able to square this with warning labels and handling instructions printed on bottles purchased from home depot. They also chose to ignore the fact Glyphosate has been labeled a group 2A carcinogen.
But more than anything I fear the ignorance of people engaged in some forms of genetic engineering. Worth keeping in mind it was difficult to see cancer signal attributable to atomic blasts during WWII. I have no confidence if there was a problem that did not present immediately or dramatically to a significant percentage of people the cause would have any prayer of being seen or traceable. A common trick is to say there is no statistically significant basis for an assumption... which in and of itself is fair until you begin to understand the range of problems that could possibly exist under that same banner. Given numerous classic historical examples of active industry successful efforts to increase uncertainty and downplay risks.. I am not predisposed to be trusting of corporations whose objective function is not aligned with my own best interests.
To anyone who has a shred of fear of flying, the game of "screwing with the pilots for laughs" is not fucking funny.
Your fears are your problem and do not constitute an excuse for irrational response.
Twitter comments were not known to anyone on the flight. Those who would have normally followed his comments would be his hax0r buddies who understand context and are familiar with issues.
So he's scaring people and breaking/threatening-to-break his word, and they're being dicks to him. This may not be statutory justice, but it's poetic.
Being a dick to LEA who is threatening you to back off when they are in the wrong... Sorry I don't see the issue.
All they are doing is discouraging research and attention making the industry less safe and more likely to allow Manufacturers and Airlines to make riskier design choices in the absence of pressure to do otherwise.
But if his frustration with Boeing and Airbus is going to drive him to be a fear-mongering troll, then any inconvenience caused him by the FBI seems utterly fair.
The media, politicians and security industrial complex are fear mongering trolls. They routinely and intentionally stoke fear for financial gain and self promotion while being fully aware of their deceptions.
A researcher who honestly believes something to be true is not a troll. You may disagree with his conclusions or characterizations but disagreement alone does not make someone a troll.
The idea that harassment by LEA is somehow deserved even for crazy anti-social fear mongering trolls is disappointing. Freedom cannot exist in the absence of tolerance. Being a professional LEA is fundamentally incompatible with in-kind reaction to someone doing something to get you mad.
How is scientology any less of a religion than christianity or islam or mormons or any other belief system?
The purpose of Scientology as openly admitted by its founder was "to make money"... If anyone is allowed to start their own religion with the express intent of making money then granting tax exempt status based on assertion of "religious" status alone makes for some pretty ridiculous and nonsensical policy.
NTLMv2 isn't broken, but it definitely isn't as good which is why Windows uses Kerberos by default.
Both NTLMv2 and Kerberos are broken because an attacker is able to conduct offline brute force attacks against credentials simply by observing challenge/response communication between client and server.
This constitutes an unacceptable risk because the vast majority of users do not use passwords with sufficient entropy to withstand an offline as attack conducted by modern, distributed and specialized hardware. In the end your looking at an easy >90% success rate against most targets vs guaranteed 100% rate with NTLMv1.
I wish MS would finally get off its ass and switch to a zero knowledge key agreement protocol.
Brings back old memories of web servers losing their marbles after seeing post requests with maliciously selected content-length headers. Guess some never learn.
Only Windows Server 2003 and below will accept LM/NTLMv1 by default, which means as far as supported systems only 2003, and it is EOL July 14, 2015. You'd have to be desperate to still be running any 2003, and if you were you can disable LM/NTLMv1 via GPO. Vista/2008 and above will only accept NTLMv2 responses.
The article states "the encryption method used was devised in 1998 and is weak by todayâ(TM)s standards... Microsoft has yet to release a patch to fix the Redirect to SMB vulnerability" as if Microsoft must remove the feature in order for Cylance to consider this resolved. Instead a number of improvements have been made to SMB since 1998 include support for HMAC-SHA256 (v2.0) and AES-CMAC (v3.0) hashing.
When faced with claims of security it is necessary to fully understand the underlying basis of trust without which security is a mirage.
What is the mechanism by which one system or user authenticates the identity of another system or user and why is this process trustworthy?
Without secure authentication and proper binding encryption by itself is useless.
You are going need a little more than "$3000 worth of GPUs" to forward brute force the AES-CMAC hashed passwords.
How are the key parameters to AES and HMACs derived? If an attacker can figure that out then a whopping $0 worth of GPUs will suffice.
So how about it... where does this magical session key for admittedly very substantial and well engineered SMB3 encryption come from?
The answer is NTLMv2 or Kerberos. This is a "bad deal". NTLMv2 credentials can be stolen and replayed with impunity by launching offline brute force attacks against captured challenge response. Ditto for Kerberos. Game over.
Do you have an opinion of a relatively common method that is better? My issue with many is that it jusst sends the password to the server for verification, trusting that TLS will protect it. Given that it's exceedingly common for clients to not verify the certs, this is also fraught with risk.
Recommend looking into a PAKE algorithm. The advantage they are able to provide mutual proof of possession of a common secret without leaking knowledge that may be used to determine what that secret is. These systems are not vulnerable to offline attack and provide keying to encrypt the network session such that you can carry on a secure conversation post authentication.
TLS-SRP is currently my favorite option. Currently shipping with many commonly used SSL toolkits. Supported by Apache and CURL but still quite sparse in terms of application support.
Anything you can put a TLS wrapper around you can probably hack to support TLS-SRP authentication without a terrible amount of effort.
Slashdot Mirror
A one-time pad is also unbreakable. What makes quantum cryptography any better?
In some ways QC is worse than OTP because quantum crypto still requires classical basis of trust to authenticate communication partners.
What makes QC useful is it allows production of new OTP material from a provably private well completely "disconnected" from the classical communication channel.
There are a number of methods for re-keying without QC but they are based on deterministic algorithms where if you were to get your hands on the "previous" state you would stand some chance of being able to derive subsequent states... with QC that chain is broken.
Quite frankly I doubt it really provides much in the way of any real world benefit because a system is only as good as its weakest link and you still have to bind the quantum system using classical cryptographic methods subject to the same attacks we're all quite familiar with already. Keep a massive OTP codebook secret or keep a smaller secret and use QC... same problem either way.
Only if it took 100 years for you to make the trip. Otherwise you will be moving backward in time for some possible observers.
Superluminal propagation of the light cone is needed to invert cause and effect and that did not occur in my scenario.
The information I took with me simply took a more efficient path. The consequences of that never propagated superluminally.
To see the problem, imagine 2 wormholes, A and B, each with widely separated endpoints. In my reference frame, the endpoints A1 and A2 are stationary - I'm standing by A1 and can send a message instantly to A2. The endpoints B1 and B2 are stationary relative to one another, but are moving close to c relative to A. In B's reference frame, my message goes back in time.
Sounds like adding vectors while neglecting Lorentz. When you travel thru such a wormhole you gain only incidental mass and potential energy as observed by an external frame stationary to wormhole, you don't see the universe contracting to a point, your observers don't see your mass increasing or your clock slowing. No observer ever gets to see your mass/energy dwarfing the rest of the universes and there isn't any backwards time travel. You can't add or subtract the apparent external velocity of messages thru wormhole with the differential velocity of another wormhole whizzing by.
A simpler example: you can get a straightforward time machine simply by accelerating one end of a wormhole up to relativistic speed for a few years, and then bringing it back, parking it at rest near the other end. Like the twin who visits a distant star and returns, one end will be "younger" than the other. Now the wormhole moves you back (or forward) in time by a few years when you traverse it.
I agree that one end will be younger but later after they are parked traveling through it won't send you backward in time and you'll only go as forward in time as it actually takes the travel through.
To violate ordering of cause and effect you need to actually exceed C not just *appear* to exceed it.
If I were to magically snap my fingers and magically materialize between "earth" and "earth2" 100 light years away without having propagated thru space I am free to make whatever measurements I want between either planets and leak all the information I can find and at no point will any observer in any frame be able to detect an inversion of cause and effect.
OK, I tried to read your first sentence 3 times, and I still can't parse it, so I'm not sure what you're saying. Naturally, slower-than-light state transfer doesn't introduce paradox. FTL state transfer does allow inversion of cause and effect - the clear examples of this involve two pairs of wormholes, moving quickly relative to one another, which allows you go send a signal out through one pair and back through the other, and get the signal before you sent it.
The only thing that matters is propagation. Lets say I can only go 10 spaces in 10 ticks.
- - - - - - - - - -
1.................10
Now lets try covering the same external distance through a wormhole:
- - -
1.................3
Well I went 3 spaces in 3 ticks... but the rest of the universe thinks I went 10 spaces...silly fools.
You just think FTL propagation because your losing track of the configuration of space through which the propagation is being done. Your assuming the result matters when what really matters is HOW you got there.
Wormholes can connect two arbitrary points in spacetime - this allows FTL travel,
but that means time travel, with raises all sorts of paradoxes.
Instantaneous state transfers which don't operate by means of propagation or the taking of shortcuts traveling less than FTL locally thru said mystical shortcut raise no paradox of any kind in any frame of reference. There is no grandfather paradox or inversion of cause and effect.
You implicitly assume that sites get most of their traffic from any search engine. Plenty of sites don't.
Because most do.
Plenty of sites don't.
Given number of sites out there "plenty" can be used to describe anything.
Intranet sites obviously don't rely on public search engines.
Pencils don't rely on public search engines either.
Of the commercial projects I currently work on -- and there are several, because I do freelance/consultancy work -- I don't think any gets the majority of its visitors from search engines, and in some cases if Google disappeared tomorrow you'd hardly notice on the bottom line.
Google pulls in tens of billion a year in paid revenue a year. Obviously someone cares a whole lot.
He's saying that if your visitors are primarily coming from search engines, then your site can ignore what search engines want without harm because being downranked by them won't hurt you.
??? If you get most of your traffic from search engines then you can ignore search engines and it won't matter? Say what?
Plenty of sites get most of their visitors from regular readers rather than from search engines.
Plenty more don't.
Sites are able to choose not to use Google, by the way. It just takes a small edit to your robots.txt file to get Google to completely ignore your site.
The site discovery process is dominated by the use of Google. What site owners chose to put in their robots.txt file has nothing to do with this reality.
don't think google is a monopoly -- there are lots of other search engines who drive reasonable amounts of traffic. But they are certainly the Big Dog.
We live in completely separate universes. The stats I care about show Bing in second place behind Google with a whopping 2% of Google's traffic. Followed by Yahoo at 31% of Bings pathetic 2%.
Nonetheless, there is a three-way symbiotic relationship here. If Google pushes so hard that sites stop caring about their google rankings, then Google's relevance will fall.
I think if sites stopped caring about their Google rankings then Google's relevance would increase since people would be more likely to find what their actually interested in vs dealing with aftermath of billions locked up in efforts to p0wn google search results.
The way it fails is when Google algorithms make bad decisions based on largely irrelevant criteria.
If enough people find Google to suck more than the alternatives, the Google's relevance will fall.
This I agree with.
I'd be the first to agree that Google shouldn't get to dictate how the Web works and that sometimes Google or at least some its
They shouldn't get to dictate how the web works but then you basically say don't like it don't use Google... I'm confused... are sites able to chose not to use Google? What sites gets most of their traffic from a different search engine?
However, if you're relying on Google's service for most/all of your visitors to find your site at all, you have to play by their rules if you want the best treatment from them. This is the basic principle of SEO, and it's as old as search engines themselves.
What happens when those rules begin to stray from principals fewer people agree with? Google is more or less a monopoly.
You can always count on the Internet to implement good concepts poorly and parade the result as cutting edge technological innovation.
One thing I've always liked about HTML was from very early days before even CSS or Google the "promise" of targeting vast arrays of client form factors with the same information. This sounded great but proved in to be mostly unnecessary and divorced from reality.
Rise of "Responsive" sites more often than not translate back into frustrated desktop, laptop and tablet users with sites resembling pre-tables era childish web layouts boasting comically large fonts and painfully low information density. Paradoxically these "features" persist even when viewed from my mobile phone with the same display resolution as a large HD TV or desktop monitor. Very few appear to actually be capable of designing single scalable sites that don't suck.
There was a time when mobile sites were necessary. Given the proliferation of display sizes, LTE, multi-core multi-ghz processors with GBs of RAM.. that time has came and gone. Google is trying to catch up to a need that for the most part was already solved by hardware and software innovation and no longer exists.
If your going to punish sites for not as judged by a naive non-human algorithm offering something that is not "appealing" to a human using a client of a specific form factor or capability then do so across the board without bias. When I do a Google search from my desktop penalize all search results that consist of mobile handset optimized sites with comically large fonts and childish layouts.
What determines the worth of a website to me has never been layout it has been content and lack of annoying BS. All "looks over brains" does is give legions of spam trap link-baiting sites an even greater advantage.
Stupid all around to say nothing of negative implications of people waking up to the dangers of Aggregation of power into the hands of so few.
I quite like vastly increased difficulty of scanning the whole IPv6 Internet. As soon as Comcast fixes their business class remote access via IPv4 is going bye bye. Sick of looking at all this crap in my logs. If random fools want to spam me they are going to have to work for it.
And WaffleMonster just wants to bash Google for his/her own benefit (i.e. paid by MS).
Was in the room for delivery of one-sided Google presentations touting benefits of aggressive congestion schemes and ICW settings during TCPM meetings. I honestly fear ease at which clients and servers can cheat and tinker for competitive advantage with completely user land stacks embedded in applications.
Wording was probably a little unfair and oversimplified yet I believe in the general theme. I don't work for a large corporation and have little interest in this space other than promotion of an open decentralized Internet.
I disagree. To me there's at least one really compelling reason: To push universal encryption.
Too bad the goal was not pushing universal security instead.
One of my favorite features of QUIC is that encryption is baked so deeply into it that it cannot really be removed. Google tried to eliminate unencrypted connections with SPDY, but the IETF insisted on allowing unencrypted operation for HTTP2. I don't think that will happen with QUIC.
What we need are systems that are actually secure not ones that pretend to be. Hard to get excited about a "feature" that is worthless against most threats.
True, but TCP is very hard to change. Even with wholehearted support from all of the major OS vendors, we'd have lots of TCP stacks without the new features for a decade, at least.
Is there a technical barrier with respect to TCP and or TLS that makes addressing issues unrealistic? Linux kernel has had TFO support for years and it didn't take decades for SYN cookies or SACKs to hit all but the long tail. There must be at least a dozen or two TLS extensions by now. How hard can it be from a technical perspective to tweak session tickets or whatever vs throwing everything out and reinventing wheels?
QUIC, on the other hand, will be rolled out in applications, and it doesn't have to be backward compatible with anything other than previous versions of itself.
Not sure retrofitting IP stacks into applications qualifies as a feature. More of the same thing duplicated everywhere usually means a bigger headache for all.
Then you can figure out how to integrate your new ideas carefully into the old protocols without breaking compatibility, and then you can fight your way through the standards bodies, closely scrutinized by every player that has an existing TLS or TCP implementation. To make this possible, you'll need to keep your changes small and incremental, and well-justified at every increment. Oh, but they'll also have to be compelling enough to get implementers to bother. With hard work you can succeed at this, but your timescale will be measured in decades.
These are political not technical arguments. Heads of state routinely whine about not being "king" yet there are advantages to not so easily having your way.
I totally understand why Google is doing what their doing. If you own the net stack and the browser and the servers and are a big enough player this is a completely understandable and logical approach to accomplish your goal.
As for using TCP without encryption so you don't have to pay for something you don't need, I think you're both overestimating the cost of encryption and underestimating its value.
I'll assume it can cost nothing in terms of CPU, I/O or Time.
A decision that a particular data stream doesn't have enough value to warrant encryption it is guaranteed to be wrong if your application/protocol is successful.
Not everyone has the same problems or constraints. Caution against mapping your experiences onto the rest of the world and drawing conclusions from it.
I may need to use a specialized security layer.
I may care about the ability for agents to passively monitor a telemetry stream.
I may care only about integrity of a message.
I may be prohibited by law or corporate rules from encrypting data.
I may have a mission critical system where any use of encryption is an unnecessary potential for failure.
Only for restarts. For new connections you still have all the TCP three-way handshake overhead, followed by all of the TLS session establishment. QUIC does it in one round trip, in the worst case, and zero in most cases.
Yes at a minimum any TCP + TLS solution would require minimum 2 separate unavoidable round trips - one for TCP and a second for TLS regardless of construction if state / cookies / tickets / whatever were not available for TCP and or TLS. So what?
SCTP, for one, doesn't have any encryption.
Good, there is no reason to bind encryption to transport layer except to improve reliability of the channel in the face of active denial (e.g. TCP RST attack). A feature QUIC does not provide.
Managing transport and encryption in a single protocol makes the resulting system more brittle and complex. Improvements to TCP helps everything layered on top of it. Improvements to TLS helps everything layered on top of it.
Not having stupid unnecessary dependencies means I can benefit from TLS improvements even if I elect to use something other than IP to provide an ordered stream or I can use TCP without encryption and not have to pay for something I don't need.
QUIC integrates a TLS layer into it, in a way that avoids a lot of connection setup time.
TCP+TFO + TLS extensions provide the same zero RTT opportunity as QUIC without reinventing wheels.
I have yet to hear a coherent architectural justification for QUIC that makes sense... The reason Google pushes it is entirely *POLITICAL* this is the path of least resistance granting them full access to the TCP stack and congestion algorithms without having to work to build consensus with any other stakeholder.
Google just wants dominion over congestion algorithms for their own benefit.
All I see is the rise of Mob rule and lack of mutual respect and tolerance.
Force is the least effective means of promoting "good" behavior and Mob rule is an ineffective means of governance.
I am increasingly worried about the role Media whoring for attention and profit is having on society.
or do you just stand against genetic engineering as we currently practice because you have an ignorant fear of what you don't understand?
I fear the properties of roundup ready GMO crops are being leveraged to optimized labor costs during production increasing loads of roundup leeching into the food supply.
People say roundup is safe yet nobody has been able to square this with warning labels and handling instructions printed on bottles purchased from home depot. They also chose to ignore the fact Glyphosate has been labeled a group 2A carcinogen.
But more than anything I fear the ignorance of people engaged in some forms of genetic engineering. Worth keeping in mind it was difficult to see cancer signal attributable to atomic blasts during WWII. I have no confidence if there was a problem that did not present immediately or dramatically to a significant percentage of people the cause would have any prayer of being seen or traceable. A common trick is to say there is no statistically significant basis for an assumption... which in and of itself is fair until you begin to understand the range of problems that could possibly exist under that same banner. Given numerous classic historical examples of active industry successful efforts to increase uncertainty and downplay risks .. I am not predisposed to be trusting of corporations whose objective function is not aligned with my own best interests.
there is everything wrong with questiong GMO, the science
This is an oxymoron.
To anyone who has a shred of fear of flying, the game of "screwing with the pilots for laughs" is not fucking funny.
Your fears are your problem and do not constitute an excuse for irrational response.
Twitter comments were not known to anyone on the flight. Those who would have normally followed his comments would be his hax0r buddies who understand context and are familiar with issues.
So he's scaring people and breaking/threatening-to-break his word, and they're being dicks to him. This may not be statutory justice, but it's poetic.
Being a dick to LEA who is threatening you to back off when they are in the wrong... Sorry I don't see the issue.
All they are doing is discouraging research and attention making the industry less safe and more likely to allow Manufacturers and Airlines to make riskier design choices in the absence of pressure to do otherwise.
But if his frustration with Boeing and Airbus is going to drive him to be a fear-mongering troll, then any inconvenience caused him by the FBI seems utterly fair.
The media, politicians and security industrial complex are fear mongering trolls. They routinely and intentionally stoke fear for financial gain and self promotion while being fully aware of their deceptions.
A researcher who honestly believes something to be true is not a troll. You may disagree with his conclusions or characterizations but disagreement alone does not make someone a troll.
The idea that harassment by LEA is somehow deserved even for crazy anti-social fear mongering trolls is disappointing. Freedom cannot exist in the absence of tolerance. Being a professional LEA is fundamentally incompatible with in-kind reaction to someone doing something to get you mad.
How is scientology any less of a religion than christianity or islam or mormons or any other belief system?
The purpose of Scientology as openly admitted by its founder was "to make money" ... If anyone is allowed to start their own religion with the express intent of making money then granting tax exempt status based on assertion of "religious" status alone makes for some pretty ridiculous and nonsensical policy.
NTLMv2 isn't broken, but it definitely isn't as good which is why Windows uses Kerberos by default.
Both NTLMv2 and Kerberos are broken because an attacker is able to conduct offline brute force attacks against credentials simply by observing challenge/response communication between client and server.
This constitutes an unacceptable risk because the vast majority of users do not use passwords with sufficient entropy to withstand an offline as attack conducted by modern, distributed and specialized hardware. In the end your looking at an easy >90% success rate against most targets vs guaranteed 100% rate with NTLMv1.
I wish MS would finally get off its ass and switch to a zero knowledge key agreement protocol.
char request1[] = "GET / HTTP/1.1\r\nHost: stuff\r\nRange: bytes=0-18446744073709551615\r\n\r\n";
Brings back old memories of web servers losing their marbles after seeing post requests with maliciously selected content-length headers. Guess some never learn.
Only Windows Server 2003 and below will accept LM/NTLMv1 by default, which means as far as supported systems only 2003, and it is EOL July 14, 2015. You'd have to be desperate to still be running any 2003, and if you were you can disable LM/NTLMv1 via GPO. Vista/2008 and above will only accept NTLMv2 responses.
NTLMv2 is broke too.
The article states "the encryption method used was devised in 1998 and is weak by todayâ(TM)s standards ... Microsoft has yet to release a patch to fix the Redirect to SMB vulnerability" as if Microsoft must remove the feature in order for Cylance to consider this resolved. Instead a number of improvements have been made to SMB since 1998 include support for HMAC-SHA256 (v2.0) and AES-CMAC (v3.0) hashing.
When faced with claims of security it is necessary to fully understand the underlying basis of trust without which security is a mirage.
What is the mechanism by which one system or user authenticates the identity of another system or user and why is this process trustworthy?
Without secure authentication and proper binding encryption by itself is useless.
You are going need a little more than "$3000 worth of GPUs" to forward brute force the AES-CMAC hashed passwords.
How are the key parameters to AES and HMACs derived? If an attacker can figure that out then a whopping $0 worth of GPUs will suffice.
So how about it... where does this magical session key for admittedly very substantial and well engineered SMB3 encryption come from?
The answer is NTLMv2 or Kerberos. This is a "bad deal". NTLMv2 credentials can be stolen and replayed with impunity by launching offline brute force attacks against captured challenge response. Ditto for Kerberos. Game over.
Do you have an opinion of a relatively common method that is better? My issue with many is that it jusst sends the password to the server for verification, trusting that TLS will protect it. Given that it's exceedingly common for clients to not verify the certs, this is also fraught with risk.
Recommend looking into a PAKE algorithm. The advantage they are able to provide mutual proof of possession of a common secret without leaking knowledge that may be used to determine what that secret is. These systems are not vulnerable to offline attack and provide keying to encrypt the network session such that you can carry on a secure conversation post authentication.
TLS-SRP is currently my favorite option. Currently shipping with many commonly used SSL toolkits. Supported by Apache and CURL but still quite sparse in terms of application support.
Anything you can put a TLS wrapper around you can probably hack to support TLS-SRP authentication without a terrible amount of effort.
Why do you lump Kerberos in there? Kerberos afaik is fine security wise.
Kerberos client authentication is subject to offline dictionary attack.