If there was one thing you could go back and change about TCP/IP -- something that is far too entrenched to change now -- what would it be?
I think Vint Cerf has already on multiple occasions mentioned the two things he would have liked to have done differently when designing IPv4 and TCPv4. The two things were the size of the addresses and mobility support. At the time there was discussion about the size of the addresses, some people wanted 32 bits, some people wanted 64 bits (and AFAIR some people wanted variable size). Vint was responsible for ending the discussion and deciding on 32 bits. He has publicly admitted that turned out to be an unfortunate decision.
If IPv4 had been designed with 64 bit addresses, chances are we would never have gotten IPv6 with the additional improvements it offers.
Vint Cerf has explained that leaving out mobility from IPv4 was due to it being considered appropriate for a lower level in the stack. And to some extent mobility can be handled by WIFI or cell phone networks. But it turned out that in some cases that isn't sufficient, and mobility at a higher level in the protocol stack would have been better.
I don't think there is anything wrong with the question, but I think that apart from the above two points, what answers you will get is mostly what got changed between IPv4 and IPv6 anyway. Maybe he would also have wanted something designed differently in TCP to begin with (such as knowledge of mobility). The upgrade from IPv4 to IPv6 didn't really change TCP, so TCP still does carry around some stuff that could have benefited from a redesign.
I seem to recall that Vint Cerf also at some point pointed out authenticity as a point that would have been a good idea to have in the protocol from the start. However at the time when IPv4 was designed public key cryptography was still too young to be properly understood, and any authenticity put into the protocol at the time would likely have turned out to be flawed.
Considering how much I can write from recollection of what Vint Cerf has said about that question in the past, maybe it is worthwhile having him repeat it again in his own words.
But there is another question that I would really like to see answered. It is about the IPv4 to IPv6 transition. If IPv4 had been designed differently to begin with, we might not have had to go through this transition. But you never have the necessary experience to design something right the first time, so that is not really a worthwhile discussion. And I don't think discussing the specific design of IPv4 and IPv6 is really that interesting either. The changes from IPv4 to IPv6 all seem for the better, and with the requirement for larger addresses they couldn't have been made much more compatible anyway, so some transition mechanism would be required.
My question is: What could have been done differently to ease the transition. In other words, if you could go back to the point where the design of the IPv6 protocol as it looks today was available, how would you have designed the transition plan? We all know that there was a transition plan, and nobody executed it fast enough to make it work out. How could the transition mechanisms have been done differently to ensure that the transitioning had happened fast enough to make IPv4 obsolete before the addresses ran out and we had to resort to hacky workarounds like NAT?
What is the technical reason or reasons why you cannot hibernate one OS (suspend it to disk), then restore another previously hibernating OS?
Some people figured out how to use rEFIt do that with Linux and Mac OS X. But too many people used this without understanding what they were doing, and the rEFIt author was annoyed with having to support that, so he fixed rEFIt such that it would no longer permit this.
The main reason it cannot work is the file systems. If you have the same file system mounted read/write in both systems you are going to corrupt it. Read only access would be fine except from two problems.
Some journalling file systems cannot be mounted read only. If you tried to do this with ext3 (that's the journalling file system I have the most experience with), the ext3 driver will not respect the request to mount the file system read only. What will happen is that the first system will leave the file system in a busy state. The next one that was supposed to only mount it read only will see that the file system was not cleanly unmounted and will mount it read/write, then clean up the file system, and then remount it read only.
So, even if you thought you had configured it correctly, the OS instance that was only allowed to read still wrote something. Then you switch back to the one that is allowed to write, and since it doesn't know that something has changed the disk contents behind its back (and it wouldn't have been able to deal with it, even if it had known about it), the next write is potentially going to corrupt the file system.
The other problem is that even if you can mount the file system completely read only, the file system driver still doesn't expect the contents to change underneath it, so once you have been in the OS instance that is allowed to change it, and then switch back, bad things may happen.
To some extent you can get around the problems by unmounting file systems before hibernating and mounting them again when restoring. But if the file system was busy and couldn't be unmounted, you will be in trouble. In particular stuff like/,/usr, and/home are likely to always be busy.
The safest approach would be to not access any file system from both systems. But that makes sharing data between them hard. If you were virtualizing and had both running at the same time, you could use networking file systems. But that isn't going to work when they are not running at the same time since one is always hibernated.
You have a bit of the same problems with USB attached file systems. I guess those are unmounted when the system is hibernated, but I don't know what systems do if the USB stick is busy at hibernation time. You can probably mess up things badly if you put a USB file system into a situation that is almost impossible to handle.
If you have a USB stick with no important data on it, then you can make the following experiment.
Put it in one machine and start a program that will fill up all space on the USB stick by writing a single large file.
Before the program has filled up more than a few percent, hibernate the system.
Move the USB stick to a different machine.
Start filling up the USB stick the same way by writing a single large file to a different directory on the USB stick.
Hibernate the second system.
Move USB stick back to the first system.
Continue in this way by alternating which machine gets to write until the media is full. Notice that at no point do you move the USB stick while the system is running, you only move it while both machines are hibernated. My guess is that you will find that management of free space gets messed up badly, and the two files will be claiming to own the same physical areas of the media.
Removable file systems tend not to be busy all the time and not likely to get into such bad situations unless you put them into challenging situations like I described. But there are file systems that you expect to be mounted and busy all the time while the system is running. On those the risk of such problems is much higher.
It is quite obvious how getting this icon from facebook every time a page is loaded will allow facebook to track it. But why does that mean you have to click twice after this change? Couldn't they just host the icon locally and still let the link do what it used to do on the first click?
HTTP gives plenty of leeway and in fact was designed with caching in mind. So long as the involved parties do not violate the protocol, I'm ok with it.
This initiative is not going to be changing http at all. The client may end up at a different replica of the http service, but each of them is equally valid. The only difference is how fast you get the answer.
The DNS protocol must also be honored to the extent that deviations from same have not been expressly authorized.
The protocol was designed in an extensible way. If the client supports this particular extension it will send the extra information along to the server in a way that the server will simply ignore if it doesn't support the extension. If the server supports the extension and sees this extra information from the client it may pass along extra information to the client. If the client doesn't support it, then the server will never see this extra information from the client and thus not return the extra information to the client either. So if only one of the two support the extension, then everything will work out exactly the way it did before the extension was introduced. I don't know where to find the final version of the spec. I know where to find an expired draft. The protocol probably hasn't changed much since that draft. However in the draft the option code is listed as TBD, has IANA assigned an official option code for this extension?
Even the term TCP/IP in itself is misleading. TCP and IP are two separate protocols. TCP is designed to be run on top of IP, and TCP does have some knowledge of the underlying protocol (a bit too much some would say). IP on the other hand has no knowledge of TCP. The IP header contains an 8 bit protocol field, so you can in principle run 256 different protocols on top of it (some values are reserved, and not all the other values are assigned yet). An implementation of IP does not have to implement all the higher level protocols, in fact only ICMP is mandatory.
A router is supposed to work on the IP layer. A router should not know about TCP, and it shouldn't care what protocols are run over it. In practice routers do tend to have TCP and UDP implementations as well. They have TCP because that is what is typically used to configure the routers, and BGP is run over TCP as well. And in some cases you may want to do DNS lookups, and for that you want UDP.
When you build a router you have to keep the right layering. The low level should do routing and not care about UDP and TCP. The next level can do TCP and UDP, and on high end routers the separation should be to the point where this is even implemented by a different piece of hardware from the one that does the routing. The next level up the stack can handle configuration and routing protocols. This layer can then push updated routing tables to the actual hardware doing the routing. If the different pieces stick to their area of responsibility, things will work out. All of those higher levels could in principle be implemented by a computer next to the router and leave the router to do only routing.
Some routers have features to interpret higher level protocol headers such as UDP and TCP and mangle them. Once it starts doing that, it is no longer a correct implementation of IP according to the original spec. The network is supposed to get the higher level payload from source to destination without mangling it. The network as it looks today fails at that task.
but doesn't every device modify the header of every packet while sending it downstream?
Routers do. They have to decrement the TTL, and in case of IPv4 adjust the header checksum. But most of the other fields in the IP header are read-only for the routers, and the higher level protocol headers such as UDP and TCP are totally off-limits.
This should be my last reply to my own posts. I read a bit more and found concerns that NSEC3 still allows an attacker to send queries that will in effect collect all the hash values, which can then be used in an offline dictionary attack to reveal the hostnames. This is a valid concern, but one that I believe can easily be handled. I didn't find any discussions of solutions for this problem, so I put an article on my website discussing a possible solution, which can be implemented in signing+authoritative server without any changes to the protocol or the resolver code.
Sorry to answer my own post again, but the first page I found was a bit outdated. It turns out the problem was addressed in RFC 5155, which introduced NSEC3 records that chains hashed values of the domains rather than the domains themselves. It also involves salting to counter dictionary attacks. You can still estimate the size of a zone by requesting a bunch of random subdomains and see what the distance between the hashes are, but at least you cannot find out what the exact subdomains are, and the solution is much simpler than one which would hide the size of the zone. If you consider the exact size to be secret, you can always add more hashes to make the zone look bigger than it is.
The simpler solutions would then make it possible to enumerate all domains in the zone, something you might not want
I did a bit of search and found out about the NSEC record (next secure). It is a record that contains information about two existing subdomains and the signature on this record confirms that no records exist in the interval between those two subdomains. If you use this you are in fact allowing enumeration of the complete zone. The alternative is to have the key online (with the key online NSEC records could dynamically be generated for intervals short enough to make an enumeration impossible).
Zone administrators get to choose between two approaches with different security drawbacks, that is either permit enumeration or keep the key online. Or you could opt not to provide signatures on NXDOMAIN in which case you will produce lots of errors instead of valid NXDOMAIN responses. But at least you could keep stats of which subdomains are requested and occasionally produce signatures offline to be able to provide NXDOMAIN responses for those subdomains. None of these solutions are particular desirable. If at least a separate key had been used for authenticating NXDOMAIN responses you could have kept that key online such that leaking that key would only allow DoS attacks by forging NXDOMAIN responses and not allow producing actual forged records.
Short of requiring DNS servers to sign their error messages
Even that wouldn't help the slightest. If you wanted a signature on the error message send by the recursive resolver when it doesn't get an answer from the authoritative DNS server, then that would have to be signed by the recursive resolver. But it is the recursive resolver, which you don't trust, so a signature from the recursive resolver doesn't help. (Such a signature wouldn't fit in the DNSSEC model anyway as keys are tied to domains, not to resolvers.)
When the recursive resolver is unable to communicate with the authoritative DNS server, there is no way for the client to know which of the two or the network in between is responsible. In fact even the recursive resolver can't know who is responsible for the communication failure. It is trivial to provoke a communication failure in order to trigger a legitimate error message.
at least with DNSSEC they can't outright lie to you and claim NXDOMAIN when the domain actually exists.
I don't know enough details about DNSSEC to know if that is true. Obviously you cannot pregenerate signatures on every possible domain for which you would ever want to send an NXDOMAIN. There are other ways to achieve it though. The simpler solutions would then make it possible to enumerate all domains in the zone, something you might not want, and something which wasn't possible with plain old DNS. You can pregenerate a commitment to a database that will allow you to open both existing and nonexisting keys without revealing the size of the database. However that involves cryptography a bit more advanced than what I think was appropriate for DNSSEC.
Dynamically generating signatures on NXDOMAIN answers would require the key to be online, which would make the system less secure as you are removing one layer of defence. If you were to put the key online, a security vulnerability in the DNS server could allow an attack to get a copy of the keys. If the key was offline, an attacker could only get a copy of all the valid signed records.
stop abusing relative domain references when the full domain is known.
When was the last time you saw a URL with a trailing dot in the hostname? Using relative names with the expectation of them being treated as a full domain name is in fact the norm. But I agree it might be something we should try to change.
The browser can also help by always showing the full domain name returned by the resolver, and not just the portion entered by the user.
Agreed.
It wouldn't hurt to make "server failed" messages more painful, either—for example, whenever a server reports an internal failure of that sort, the resolver could refuse to use it for the next five minutes or so
That would hurt. Lets say you type in http://example.com/ in your browser, but the DNS server responsible for example.com is down. Thus the recursive resolver will never get the reply it needs and will time out and send a server error message back to the browser. If the browser stops using the recursive resolver in that case it will quickly run out of recursive resolvers and will thus be unable to resolve any domain name.
In effect you have made a system that is trivial to perform a DoS attack against.
I'm not saying a DNS filter is a good idea. Just that the DNSSEC argument isn't the real problem with it. Frankly I'd rather see DNS filters made illegal as it is interception of private communication between two parties that have not accepted such measures.
Probably for historical reasons. For a computer that connects to networks not under your own control, there is little benefit from using those networks' DNS paths. Though a few common names do tend to make sense to look up under the search path. For example www and news are names that tend to be meaningful. But in most cases the search path isn't helpful. In particular for https it is pointless as you'll just end up with a certificate warning due to a mismatch between the short and the long names.
Technically it doesn't have to conflict with DNSSEC.
First of all ISPs have to stop lying about the A record when you look up a filtered domain (Seems like an oversight if that practice is even legal). Instead they need to send an error response back to the user. I'd suggest a server error message (since "your government don't want you to see this" wasn't included as an error code when DNS was designed).
What the client will do when getting this error is to use the DNS search path provided by the DHCP server along with the DNS server IP. Since the ISP controls the search path, they can ensure it is a domain under which they can provide valid DNSSEC protected domains. Then they make it so that every filtered domain exists as a subdomain under the DNS search path and other domains don't exist there.
This story reminds me of a quote from one of Tanenbaum's books.
In theory, after fully understanding this chapter, the reader should be able to go out and buy a large bag full of transistors and build this subset of the JVM machine. Students who successfully accomplish this task will be given extra credit (and a complete psychiatric examination).
I'm not sure if the guy from this article qualifies, but it sounds like he is close.
Their homepage says the expected launch day is Thursday. Even the source cited for the launch happening on Friday says it is planned to happen on Thursday. So, where did the summary get Friday from?
But the distances keep them apart until they are sufficiently advanced to overcome those distances
I suppose the average distance between planets with life is pretty large. But that doesn't mean there are cases where the distance is much less than average. Take the number of stars in the universe, and take the number of those stars that have a planet with life. If the number of planets with life is just around the square root of the number of stars in the universe, it is reasonably likely that somewhere in the universe there is a solar system with two planets on which life developed independently.
One question I have been wondering about is if we were to find life somewhere else in the universe, and if it was biological life similar to on Earth, maybe even with DNA, what is the probability that the molecular structures are going to be mirror images? A reasonable guess is 50/50. But I can think of a couple of reasons it could be less likely. Maybe there are laws of physics that would prevent life from working the same if all the molecules were mirrored. And if it is true that life came from space, then maybe life on multiple planets could have originated from one source.
Another question is how you would find out if it was actually mirrored. Imagine we somehow got a radio link with another civilisation, and imagine that we somehow managed to make some intelligible communication with them. How could we find out by communicating if they are mirrored or not? You could ask a similar question with regards to matter and antimatter. Though the experts say there can't be galaxies or solar systems with antimatter, because if there were there would be regions of space where matter and antimatter meet and produce much more gamma background radiation than what we actually see.
Even in recent years, they haven't used an odd number in the second component for any stable release. But with 3.x.y they intend to do so. The first stable kernel with an odd number for the second component will be 3.1, and it will probably be released before the end of this year.
Symmetric ciphers like AES are believed to be safe.
Actually, symmetric ciphers would be reduced in security roughly equivalent to halving the number of bits. So AES128 would be reduced to roughly 64 bits of security. That would still take a long time to break, and I am not sure a quantum computer could remain coherent for long enough to do it. And you don't get the same speedup from buying multiple quantum computers to let them work in parallel on the problem as you would with classical algorithms. If you were to run four in parallel you would reduce the keyspace you have to search from 128 to 126, that means the time time each quantum computer takes is equivalent to brute forcing 63 bits. In other words four quantum computers in parallel will only be twice as fast as one working on the problem on its own.
In other words AES128 would become easier to brute force, but it still looks like it is not completely feasible yet. AES192 and AES256 are known to have weaknesses, that could potentially make them easier to break on a classical computer than AES128, but I have no idea if you can take advantage of those weaknesses using a quantum computer. If they really managed to make a 128 bit quantum computer work, I think it is time to standardize a block cipher with 256 bit block sizes and 256 bit keys.
I would expect asymmetric encryption to remain secure for now since it generally uses keys much larger than would fit in these 128 bits. Is there any way a quantum computer can be used to break a key that you can't even fit in the computer?
Do you recommend that people learn to do without in mass numbers?
No. I only recommend that people should find out beforehand what guarantee they get with there purchase and decide if it is worth the money they are going to pay for it. If they think it is not worth it, I recommend that they don't buy it instead of buying it and then mutter about it. If enough people care and stop buying games that could stop working just like that, then the vendors will notice.
If so, the publishers will probably blame piracy.
Since those particular games cannot be used without the server, and since the vendor know exactly how many people are using the server, they will know this isn't so. In other words, they would be wilfully lying when blaming privacy. I don't know if such blame games is going to help their income in any way. But I guess there would be at least one vendor with a clue who can figure out what the customers want and get some market shares.
All of this is of course based on the assumption that the original author's rant is representative for the users, and that they will actually use their power as consumers. My guess is, that it really isn't so. I think more likely the majority don't give a damn and just keep playing whatever is currently available.
Online games make it harder to use illegitimate copies. That makes it very much in the vendors' interest. Yes, there is the risk that the vendor may decide to discontinue the service. If that concerns you, then don't buy the game. As long as there are enough people that will buy games like that, they will continue to be available. You have to find out for how long you are guaranteed to be able to play, and ask yourself if it is worth the price you will be paying.
Some might argue that if the vendor discontinue the service rendering the game you bought useless, they should be forced to pay back the original purchase price of the game. However, I have been told that some of these vendors don't even charge for the game, they just charge a monthly fee for access to the server. In that case you got what you paid for.
I think that if the vendor discontinue the service, the users who are still subscribing should be entitled to download a version of the server that they can use to play with their friends. But this is not important enough that I would think it warrants regulation. You should look at the contract at see if the vendor can cancel the service without providing another way to play the game, and if so, don't buy it.
Don't expect vendors to act in the interest of the customers. Expect them to act in their own interest. It's the customers' responsibility to make it the interest of the vendors interest to act in the interest of their customers. The way the customers can do this, is by choosing which vendor to buy from. Of course if a vendor has made a promise to the customers and don't live up to it, then that is a case for regulation and lawsuits.
This is about as secure as ECB, but that's still better than what you get from incorrect use of CTR that degenerates to multiple use of a one-time-pad. What you want is a tweakable block cipher. Just use the block using i as tweak. That is how LRW mode works, with a specific construction for the tweakable block cipher.
One of the constructions for the tweakable block cipher is encrypt(t ^ encrypt(plaintext)), a more efficient construction (but requires a larger key) is (t*k2)^encrypt((t*k2)^plaintext). In this construction * is multiplication in a finite field. * is a bit expensive, but still less than the cipher itself. And, * can be optimized if you are doing multiple operations where the different values of t are related.
You should take a look on the paper that introduced tweakable block ciphers. It explains the constructions much better than I could do.
as far as I know having a well known IV in, say, CBC is not a vulnerability.
It is, but only a minor weakness. With early disk encryptions, that simply used sector number as IV, it was possible to construct a file that when written to that file system would produce an easily recognizable pattern in the encrypted data. I have an example of such a file here http://kasperd.net/ivtest.txt
There might also be some magic in reading the whole block (since we are talking about block level devices) and having, say, a CBC over the block with an IV calculated with encrypt(IV ^ i) but I think that goes out of scope of my question.
The best way I know to produce an IV is to do a calculation over the plaintext of the entire sector except from the first block of the sector. You could say hash the complete sector with first block replaced by sector number and then encrypt the hash value. The advantage of such a construction is that any change anywhere in the sector will affect every block of the encrypted sector.
However since most storage encryptions cheat and use an IV that is the same every time you write to the same logical sector, the CTR mode will actually turn into a pseudorandom one-time-pad. This means if you ever write to the same logical sector number twice, you are potentially leaking data. In the case of ecryptfs it is probably only a problem if you overwrite sectors in an existing file as the design of ecryptfs would make it easy to use a new IV per file, but not per sector.
If you want an encryption that is highly parallelizable and doesn't lose a lot of security when you cut corners and use a fixed IV, I think LRW is your best bet. (I don't like the name LRW as I find it an offence against the inventors of tweakable block ciphers, but I am not aware of any other name for that mode, and I don't even know who invented it.)
Slashdot Mirror
I think Vint Cerf has already on multiple occasions mentioned the two things he would have liked to have done differently when designing IPv4 and TCPv4. The two things were the size of the addresses and mobility support. At the time there was discussion about the size of the addresses, some people wanted 32 bits, some people wanted 64 bits (and AFAIR some people wanted variable size). Vint was responsible for ending the discussion and deciding on 32 bits. He has publicly admitted that turned out to be an unfortunate decision.
If IPv4 had been designed with 64 bit addresses, chances are we would never have gotten IPv6 with the additional improvements it offers.
Vint Cerf has explained that leaving out mobility from IPv4 was due to it being considered appropriate for a lower level in the stack. And to some extent mobility can be handled by WIFI or cell phone networks. But it turned out that in some cases that isn't sufficient, and mobility at a higher level in the protocol stack would have been better.
I don't think there is anything wrong with the question, but I think that apart from the above two points, what answers you will get is mostly what got changed between IPv4 and IPv6 anyway. Maybe he would also have wanted something designed differently in TCP to begin with (such as knowledge of mobility). The upgrade from IPv4 to IPv6 didn't really change TCP, so TCP still does carry around some stuff that could have benefited from a redesign.
I seem to recall that Vint Cerf also at some point pointed out authenticity as a point that would have been a good idea to have in the protocol from the start. However at the time when IPv4 was designed public key cryptography was still too young to be properly understood, and any authenticity put into the protocol at the time would likely have turned out to be flawed.
Considering how much I can write from recollection of what Vint Cerf has said about that question in the past, maybe it is worthwhile having him repeat it again in his own words.
But there is another question that I would really like to see answered. It is about the IPv4 to IPv6 transition. If IPv4 had been designed differently to begin with, we might not have had to go through this transition. But you never have the necessary experience to design something right the first time, so that is not really a worthwhile discussion. And I don't think discussing the specific design of IPv4 and IPv6 is really that interesting either. The changes from IPv4 to IPv6 all seem for the better, and with the requirement for larger addresses they couldn't have been made much more compatible anyway, so some transition mechanism would be required.
My question is: What could have been done differently to ease the transition. In other words, if you could go back to the point where the design of the IPv6 protocol as it looks today was available, how would you have designed the transition plan? We all know that there was a transition plan, and nobody executed it fast enough to make it work out. How could the transition mechanisms have been done differently to ensure that the transitioning had happened fast enough to make IPv4 obsolete before the addresses ran out and we had to resort to hacky workarounds like NAT?
Some people figured out how to use rEFIt do that with Linux and Mac OS X. But too many people used this without understanding what they were doing, and the rEFIt author was annoyed with having to support that, so he fixed rEFIt such that it would no longer permit this.
/, /usr, and /home are likely to always be busy.
The main reason it cannot work is the file systems. If you have the same file system mounted read/write in both systems you are going to corrupt it. Read only access would be fine except from two problems.
Some journalling file systems cannot be mounted read only. If you tried to do this with ext3 (that's the journalling file system I have the most experience with), the ext3 driver will not respect the request to mount the file system read only. What will happen is that the first system will leave the file system in a busy state. The next one that was supposed to only mount it read only will see that the file system was not cleanly unmounted and will mount it read/write, then clean up the file system, and then remount it read only.
So, even if you thought you had configured it correctly, the OS instance that was only allowed to read still wrote something. Then you switch back to the one that is allowed to write, and since it doesn't know that something has changed the disk contents behind its back (and it wouldn't have been able to deal with it, even if it had known about it), the next write is potentially going to corrupt the file system.
The other problem is that even if you can mount the file system completely read only, the file system driver still doesn't expect the contents to change underneath it, so once you have been in the OS instance that is allowed to change it, and then switch back, bad things may happen.
To some extent you can get around the problems by unmounting file systems before hibernating and mounting them again when restoring. But if the file system was busy and couldn't be unmounted, you will be in trouble. In particular stuff like
The safest approach would be to not access any file system from both systems. But that makes sharing data between them hard. If you were virtualizing and had both running at the same time, you could use networking file systems. But that isn't going to work when they are not running at the same time since one is always hibernated.
You have a bit of the same problems with USB attached file systems. I guess those are unmounted when the system is hibernated, but I don't know what systems do if the USB stick is busy at hibernation time. You can probably mess up things badly if you put a USB file system into a situation that is almost impossible to handle.
If you have a USB stick with no important data on it, then you can make the following experiment.
Continue in this way by alternating which machine gets to write until the media is full. Notice that at no point do you move the USB stick while the system is running, you only move it while both machines are hibernated. My guess is that you will find that management of free space gets messed up badly, and the two files will be claiming to own the same physical areas of the media.
Removable file systems tend not to be busy all the time and not likely to get into such bad situations unless you put them into challenging situations like I described. But there are file systems that you expect to be mounted and busy all the time while the system is running. On those the risk of such problems is much higher.
It is quite obvious how getting this icon from facebook every time a page is loaded will allow facebook to track it. But why does that mean you have to click twice after this change? Couldn't they just host the icon locally and still let the link do what it used to do on the first click?
This initiative is not going to be changing http at all. The client may end up at a different replica of the http service, but each of them is equally valid. The only difference is how fast you get the answer.
The protocol was designed in an extensible way. If the client supports this particular extension it will send the extra information along to the server in a way that the server will simply ignore if it doesn't support the extension. If the server supports the extension and sees this extra information from the client it may pass along extra information to the client. If the client doesn't support it, then the server will never see this extra information from the client and thus not return the extra information to the client either. So if only one of the two support the extension, then everything will work out exactly the way it did before the extension was introduced. I don't know where to find the final version of the spec. I know where to find an expired draft. The protocol probably hasn't changed much since that draft. However in the draft the option code is listed as TBD, has IANA assigned an official option code for this extension?
Even the term TCP/IP in itself is misleading. TCP and IP are two separate protocols. TCP is designed to be run on top of IP, and TCP does have some knowledge of the underlying protocol (a bit too much some would say). IP on the other hand has no knowledge of TCP. The IP header contains an 8 bit protocol field, so you can in principle run 256 different protocols on top of it (some values are reserved, and not all the other values are assigned yet). An implementation of IP does not have to implement all the higher level protocols, in fact only ICMP is mandatory.
A router is supposed to work on the IP layer. A router should not know about TCP, and it shouldn't care what protocols are run over it. In practice routers do tend to have TCP and UDP implementations as well. They have TCP because that is what is typically used to configure the routers, and BGP is run over TCP as well. And in some cases you may want to do DNS lookups, and for that you want UDP.
When you build a router you have to keep the right layering. The low level should do routing and not care about UDP and TCP. The next level can do TCP and UDP, and on high end routers the separation should be to the point where this is even implemented by a different piece of hardware from the one that does the routing. The next level up the stack can handle configuration and routing protocols. This layer can then push updated routing tables to the actual hardware doing the routing. If the different pieces stick to their area of responsibility, things will work out. All of those higher levels could in principle be implemented by a computer next to the router and leave the router to do only routing.
Some routers have features to interpret higher level protocol headers such as UDP and TCP and mangle them. Once it starts doing that, it is no longer a correct implementation of IP according to the original spec. The network is supposed to get the higher level payload from source to destination without mangling it. The network as it looks today fails at that task.
Routers do. They have to decrement the TTL, and in case of IPv4 adjust the header checksum. But most of the other fields in the IP header are read-only for the routers, and the higher level protocol headers such as UDP and TCP are totally off-limits.
This should be my last reply to my own posts. I read a bit more and found concerns that NSEC3 still allows an attacker to send queries that will in effect collect all the hash values, which can then be used in an offline dictionary attack to reveal the hostnames. This is a valid concern, but one that I believe can easily be handled. I didn't find any discussions of solutions for this problem, so I put an article on my website discussing a possible solution, which can be implemented in signing+authoritative server without any changes to the protocol or the resolver code.
Sorry to answer my own post again, but the first page I found was a bit outdated. It turns out the problem was addressed in RFC 5155, which introduced NSEC3 records that chains hashed values of the domains rather than the domains themselves. It also involves salting to counter dictionary attacks. You can still estimate the size of a zone by requesting a bunch of random subdomains and see what the distance between the hashes are, but at least you cannot find out what the exact subdomains are, and the solution is much simpler than one which would hide the size of the zone. If you consider the exact size to be secret, you can always add more hashes to make the zone look bigger than it is.
I did a bit of search and found out about the NSEC record (next secure). It is a record that contains information about two existing subdomains and the signature on this record confirms that no records exist in the interval between those two subdomains. If you use this you are in fact allowing enumeration of the complete zone. The alternative is to have the key online (with the key online NSEC records could dynamically be generated for intervals short enough to make an enumeration impossible).
Zone administrators get to choose between two approaches with different security drawbacks, that is either permit enumeration or keep the key online. Or you could opt not to provide signatures on NXDOMAIN in which case you will produce lots of errors instead of valid NXDOMAIN responses. But at least you could keep stats of which subdomains are requested and occasionally produce signatures offline to be able to provide NXDOMAIN responses for those subdomains. None of these solutions are particular desirable. If at least a separate key had been used for authenticating NXDOMAIN responses you could have kept that key online such that leaking that key would only allow DoS attacks by forging NXDOMAIN responses and not allow producing actual forged records.
Even that wouldn't help the slightest. If you wanted a signature on the error message send by the recursive resolver when it doesn't get an answer from the authoritative DNS server, then that would have to be signed by the recursive resolver. But it is the recursive resolver, which you don't trust, so a signature from the recursive resolver doesn't help. (Such a signature wouldn't fit in the DNSSEC model anyway as keys are tied to domains, not to resolvers.)
When the recursive resolver is unable to communicate with the authoritative DNS server, there is no way for the client to know which of the two or the network in between is responsible. In fact even the recursive resolver can't know who is responsible for the communication failure. It is trivial to provoke a communication failure in order to trigger a legitimate error message.
I don't know enough details about DNSSEC to know if that is true. Obviously you cannot pregenerate signatures on every possible domain for which you would ever want to send an NXDOMAIN. There are other ways to achieve it though. The simpler solutions would then make it possible to enumerate all domains in the zone, something you might not want, and something which wasn't possible with plain old DNS. You can pregenerate a commitment to a database that will allow you to open both existing and nonexisting keys without revealing the size of the database. However that involves cryptography a bit more advanced than what I think was appropriate for DNSSEC.
Dynamically generating signatures on NXDOMAIN answers would require the key to be online, which would make the system less secure as you are removing one layer of defence. If you were to put the key online, a security vulnerability in the DNS server could allow an attack to get a copy of the keys. If the key was offline, an attacker could only get a copy of all the valid signed records.
When was the last time you saw a URL with a trailing dot in the hostname? Using relative names with the expectation of them being treated as a full domain name is in fact the norm. But I agree it might be something we should try to change.
Agreed.
That would hurt. Lets say you type in http://example.com/ in your browser, but the DNS server responsible for example.com is down. Thus the recursive resolver will never get the reply it needs and will time out and send a server error message back to the browser. If the browser stops using the recursive resolver in that case it will quickly run out of recursive resolvers and will thus be unable to resolve any domain name.
In effect you have made a system that is trivial to perform a DoS attack against.
I'm not saying a DNS filter is a good idea. Just that the DNSSEC argument isn't the real problem with it. Frankly I'd rather see DNS filters made illegal as it is interception of private communication between two parties that have not accepted such measures.
Probably for historical reasons. For a computer that connects to networks not under your own control, there is little benefit from using those networks' DNS paths. Though a few common names do tend to make sense to look up under the search path. For example www and news are names that tend to be meaningful. But in most cases the search path isn't helpful. In particular for https it is pointless as you'll just end up with a certificate warning due to a mismatch between the short and the long names.
Technically it doesn't have to conflict with DNSSEC.
First of all ISPs have to stop lying about the A record when you look up a filtered domain (Seems like an oversight if that practice is even legal). Instead they need to send an error response back to the user. I'd suggest a server error message (since "your government don't want you to see this" wasn't included as an error code when DNS was designed).
What the client will do when getting this error is to use the DNS search path provided by the DHCP server along with the DNS server IP. Since the ISP controls the search path, they can ensure it is a domain under which they can provide valid DNSSEC protected domains. Then they make it so that every filtered domain exists as a subdomain under the DNS search path and other domains don't exist there.
I'm not sure if the guy from this article qualifies, but it sounds like he is close.
Their homepage says the expected launch day is Thursday. Even the source cited for the launch happening on Friday says it is planned to happen on Thursday. So, where did the summary get Friday from?
I suppose the average distance between planets with life is pretty large. But that doesn't mean there are cases where the distance is much less than average. Take the number of stars in the universe, and take the number of those stars that have a planet with life. If the number of planets with life is just around the square root of the number of stars in the universe, it is reasonably likely that somewhere in the universe there is a solar system with two planets on which life developed independently.
One question I have been wondering about is if we were to find life somewhere else in the universe, and if it was biological life similar to on Earth, maybe even with DNA, what is the probability that the molecular structures are going to be mirror images? A reasonable guess is 50/50. But I can think of a couple of reasons it could be less likely. Maybe there are laws of physics that would prevent life from working the same if all the molecules were mirrored. And if it is true that life came from space, then maybe life on multiple planets could have originated from one source.
Another question is how you would find out if it was actually mirrored. Imagine we somehow got a radio link with another civilisation, and imagine that we somehow managed to make some intelligible communication with them. How could we find out by communicating if they are mirrored or not? You could ask a similar question with regards to matter and antimatter. Though the experts say there can't be galaxies or solar systems with antimatter, because if there were there would be regions of space where matter and antimatter meet and produce much more gamma background radiation than what we actually see.
Even in recent years, they haven't used an odd number in the second component for any stable release. But with 3.x.y they intend to do so. The first stable kernel with an odd number for the second component will be 3.1, and it will probably be released before the end of this year.
That system has been abandoned, which is in fact the major change from 2.6.39 to 3.0.0.
The last two components in the version number are 8 bit integers. So if you actually compute the difference, the result would be 0.249.216.
Actually, symmetric ciphers would be reduced in security roughly equivalent to halving the number of bits. So AES128 would be reduced to roughly 64 bits of security. That would still take a long time to break, and I am not sure a quantum computer could remain coherent for long enough to do it. And you don't get the same speedup from buying multiple quantum computers to let them work in parallel on the problem as you would with classical algorithms. If you were to run four in parallel you would reduce the keyspace you have to search from 128 to 126, that means the time time each quantum computer takes is equivalent to brute forcing 63 bits. In other words four quantum computers in parallel will only be twice as fast as one working on the problem on its own.
In other words AES128 would become easier to brute force, but it still looks like it is not completely feasible yet. AES192 and AES256 are known to have weaknesses, that could potentially make them easier to break on a classical computer than AES128, but I have no idea if you can take advantage of those weaknesses using a quantum computer. If they really managed to make a 128 bit quantum computer work, I think it is time to standardize a block cipher with 256 bit block sizes and 256 bit keys.
I would expect asymmetric encryption to remain secure for now since it generally uses keys much larger than would fit in these 128 bits. Is there any way a quantum computer can be used to break a key that you can't even fit in the computer?
That is not an issue. xargs will run the command multiple times if necessary.
No. I only recommend that people should find out beforehand what guarantee they get with there purchase and decide if it is worth the money they are going to pay for it. If they think it is not worth it, I recommend that they don't buy it instead of buying it and then mutter about it. If enough people care and stop buying games that could stop working just like that, then the vendors will notice.
Since those particular games cannot be used without the server, and since the vendor know exactly how many people are using the server, they will know this isn't so. In other words, they would be wilfully lying when blaming privacy. I don't know if such blame games is going to help their income in any way. But I guess there would be at least one vendor with a clue who can figure out what the customers want and get some market shares.
All of this is of course based on the assumption that the original author's rant is representative for the users, and that they will actually use their power as consumers. My guess is, that it really isn't so. I think more likely the majority don't give a damn and just keep playing whatever is currently available.
Online games make it harder to use illegitimate copies. That makes it very much in the vendors' interest. Yes, there is the risk that the vendor may decide to discontinue the service. If that concerns you, then don't buy the game. As long as there are enough people that will buy games like that, they will continue to be available. You have to find out for how long you are guaranteed to be able to play, and ask yourself if it is worth the price you will be paying.
Some might argue that if the vendor discontinue the service rendering the game you bought useless, they should be forced to pay back the original purchase price of the game. However, I have been told that some of these vendors don't even charge for the game, they just charge a monthly fee for access to the server. In that case you got what you paid for.
I think that if the vendor discontinue the service, the users who are still subscribing should be entitled to download a version of the server that they can use to play with their friends. But this is not important enough that I would think it warrants regulation. You should look at the contract at see if the vendor can cancel the service without providing another way to play the game, and if so, don't buy it.
Don't expect vendors to act in the interest of the customers. Expect them to act in their own interest. It's the customers' responsibility to make it the interest of the vendors interest to act in the interest of their customers. The way the customers can do this, is by choosing which vendor to buy from. Of course if a vendor has made a promise to the customers and don't live up to it, then that is a case for regulation and lawsuits.
This is about as secure as ECB, but that's still better than what you get from incorrect use of CTR that degenerates to multiple use of a one-time-pad. What you want is a tweakable block cipher. Just use the block using i as tweak. That is how LRW mode works, with a specific construction for the tweakable block cipher.
One of the constructions for the tweakable block cipher is encrypt(t ^ encrypt(plaintext)), a more efficient construction (but requires a larger key) is (t*k2)^encrypt((t*k2)^plaintext). In this construction * is multiplication in a finite field. * is a bit expensive, but still less than the cipher itself. And, * can be optimized if you are doing multiple operations where the different values of t are related.
You should take a look on the paper that introduced tweakable block ciphers. It explains the constructions much better than I could do.
It is, but only a minor weakness. With early disk encryptions, that simply used sector number as IV, it was possible to construct a file that when written to that file system would produce an easily recognizable pattern in the encrypted data. I have an example of such a file here http://kasperd.net/ivtest.txt
The best way I know to produce an IV is to do a calculation over the plaintext of the entire sector except from the first block of the sector. You could say hash the complete sector with first block replaced by sector number and then encrypt the hash value. The advantage of such a construction is that any change anywhere in the sector will affect every block of the encrypted sector.
That's not how CTR works. Rather it works like
CTR(block(i)) = encrypt(IV || i) xor block(i)
However since most storage encryptions cheat and use an IV that is the same every time you write to the same logical sector, the CTR mode will actually turn into a pseudorandom one-time-pad. This means if you ever write to the same logical sector number twice, you are potentially leaking data. In the case of ecryptfs it is probably only a problem if you overwrite sectors in an existing file as the design of ecryptfs would make it easy to use a new IV per file, but not per sector.
If you want an encryption that is highly parallelizable and doesn't lose a lot of security when you cut corners and use a fixed IV, I think LRW is your best bet. (I don't like the name LRW as I find it an offence against the inventors of tweakable block ciphers, but I am not aware of any other name for that mode, and I don't even know who invented it.)