Slashdot Mirror

The appealing thing about carrier grade NAT is most consumers won't even notice.

Some people might claim that ipv6 could be done transparent to the end user, but personally I think that's a load of BS, and I suspect so do ISPs.

Either approach will cause problems for the end users. In both cases the users will have no clue what is the root cause of the problem, and they will believe whatever bullshit their ISP tells them. My ISP ran out of IPv4 addresses, thus some of my devices got no reply from the DHCP server. The ISP tried to convince me that it was due to a defective network interface on my end.

How to transition from ipv4 to ipv6 would to me seem the most important consideration when designing ipv6, but form appearances it seems like it was an afterthought, which is probably why we'll have ipv4 for quite some time.

That is true. I saw this coming more than a decade ago, unfortunately I was not in a position to do anything about it. Why didn't any of the people who were in a position to do something about it see it coming?

Last year I did some calculations on how fast the transition should have been going to complete on time (i.e. before IPv4 addresses ran out). For the past year the transitioning has been going at the speed, which I calculated. Meaning at the start of 2013 we were 13 years behind schedule and at the start of 2014 we were still 13 years behind schedule. I'd say my calculations would have been realistic, if only people had started soon enough rather than waiting.

The core problem was the lack of incentive to get started. A good incentive would have been rationing of IPv4 addresses much earlier. Instead of handing out 98% of the addresses before rationing IPv4 addresses, it might have been a good idea to only hand out 50% and then start rationing. The rule could then have been that you could get more IPv4 addresses if you were rolling out native dual stack. With such a rule the amount of IPv4 only deployments could have been kept static while dual stack was growing. By the time IPv4 ran out, we would have had 50% dual stack already.

But looking back and pointing out what should have been done 15 years ago isn't going to solve the problem we have today. And IPv6 deployment is still not large enough for market forces alone to give incentive to upgrade. There are ISPs rolling out CGN solutions with no plan about deploying native IPv6. How do we give those ISPs a strong incentive to start upgrading?

I have been trying to produce some incentive to move in the right direction. I am open to more ideas on what I personally can do to give ISPs the right incentive.

Does anyone have a link to the leak? You know, I want to check if my password was leaked.

I don't want to take part in distributing the plaintext version, so what I did instead was as follows.

1. I found the plaintext version and downloaded it
2. I computed a new version of the file where everything was salted and hashed
3. I created a torrent of the protected version

So if you just want to check if your password was leaked, you can download my version and check. If you want to use the list for something else, such as statistics on used passwords or attacking affected users, then you'll need to keep looking for the plaintext version.

You should use netcat or socat, since those are designed to allow you to fire text at a remote port and display the result. Telnet isn't, it only works "by accident" because the protocol is similar enough to plain text to work sometimes.

That is not exactly correct. If you use netcat newlines are not send in the correct way. The nc command will receive character number 10 from the terminal and write character number 10 on the socket. However text based protocols don't use character number 10 for newlines, they use character number 13 followed by character number 10.

That means if you use the nc command to connect to a server with just about any text based protocol, you will be sending malformed commands. However many servers will accept what you send anyway and simply do the exact same thing when they see a character number 10 as they would have done if they had seen character number 13 followed by character number 10.

OTOH using the telnet command to connect to a server with a text based protocol will do the right thing. The telnet command will send the proper 13 followed by 10 sequence when you press enter.

It is true that what telnet does in this case is nothing like the telnet protocol. As a matter of fact, the telnet protocol is not a text based protocol. The telnet client will recognize the difference because a real telnet server will send some binary data immediately when a connections is established.

So to talk a text based protocol using the telnet client is a better choice. If you are going to be using a binary protocol, nc is more suitable (but of course then stdin and stdout should of course not be a terminal). One problem that nc still has is that it doesn't properly handle half open connections correctly, not that I think telnet is any better, it is just that when pushing raw data over a TCP socket, nc is my usual choice, and in those cases half open connections matter.

Speaking of ssh tricks, I wrote this tool a few years back to allow the ssh client to choose from multiple alternative ways to connect to an ssh server.

CXR(block(i)) = encrypt(IV ^ i ^ block(i))

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.

The problem is an IV is used to "start" the CBC chain, and this IV is static as the underlying plaintext changes. So new changes on the same point of the HD get encrypted with the same IV.

It actually makes me happy to see that some people are starting to get the point. I have been pointing out these weaknesses for years.

Some of them are actually even worse. If the IV is just the sector number, then the difference between two neighbor sectors is known, and you can construct a file that will cancel out that difference and the two sectors get the same cipher text. I constructed a file some years ago, that demonstrated the problem. At that time Truecrypt was vulnerable to this attack. Truecrypt did apply some whitening after the encryption, but that didn't really make the pattern much worse. Put the file I mentioned on a Truecrypt volume encrypted in CBC mode, and somewhere in the encrypted image there will be two neighbor sectors that can be XORed together and will cancel out all the data leaving only the whitening pattern, which is easily recognizable because it repeats over many times through the sector.

Encrypting the IV is better, but still vulnerable to the problem you describe. In fact the problem you describe applies one way or another to almost every single disk encryption in existence. All the encryptions need some nonce or randomness, and since it doesn't fit in the sector, they cut a corner and use the sector number, which doesn't change when the sector is overwritten. (I have seen one that used extra space by mapping 32 logical sectors to 33 physical sectors, but that encryption had other problems including a weak pseudo random number generator, and potential data loss caused by the need to update two sectors which isn't done atomically).

Recent Truecrypt versions are no longer vulnerable to the attack I described above. They now use tweakable block ciphers. But just like CBC needs a unique IV for each time you encrypt, tweakable block ciphers need a unique tweak. Truecrypt use the sector number for tweak, so if a sector is overwritten, you have the same problem again. In fact it is even worse because there is no longer any chaining, just a tweak for each 16 byte block, which means changing a byte in a sector would keep changes in the cipher text within the 16 byte block. I didn't verify this in practice, I just read the specification. I mentioned this problem to the authors a long time ago, but they didn't consider it a problem.

Try here.

That is exactly why my prefered solution for on-the-fly hard disk encryption is TrueCrypt.

TrueCrypt is vulnerable to watermarking attacks. Some time ago I created a watermarked file to demonstrate this weakness. If you put this file on a file system encrypted with TrueCrypt, some easily recognizable patterns will show up in the encrypted container. You simply take each pair of neighbor sectors in the encryption and XOR them with each other. When you reach the place where this file is located, the result is easily distinguishable from random.