The summary claims asteroids this size pass this close twice a year, and hit once in five years. That means a lot must have passed this close and not hit. But yet the summary also claims that it has been seen only twice before.
If I hide in the shadows it's rather unfair that other people simply have to turn on the "make everyone extra bright" button and now I'm seen.
They are already spreading their users across many different servers. Maybe they could set up a couple of servers with different settings to make the game more accessible.
It does sound ridiculous at first, but if there is something simple they can do without ruining the game for everyone, why shouldn't they?
99%+ of people have no way of printing that character aside from googling "o with a line through it" and hitting Ctrl+V.
Anybody using a Mac can produce that character by pressing option+o. If you are using X and have a key mapped as compose, then you can produce it by pressing compose o /
The properties are quite similar to the Reed Solomon codes used for RAID-5 and RAID-6. The main difference according to your link is, a tradeoff between storage efficiency and CPU usage. For Reed Solomon adding parity disks causes CPU usage to grow quadratically, but the disk space used remains optimal. Fountain codes on the other hand will use more disk space, but CPU usage grows only linearly. With the one parity disk used for RAID-5, and the two typically used for RAID-6, the CPU usage is not a problem.
A problem with fountain codes is, that you don't know beforehand how many disks you are going to need for recovery. You'll absolutely need a safety margin there, which in itself is going to add more CPU time than you saved from using fountain codes to begin with. You'll probably need arrays with 10s of parity disks before it starts paying off. And at that point the time needed to read and write that many different disks every time you update a sector is going to be performance problem.
Instead of just doing parity between the disks, you could do parity that goes both across disks and within disks. Imagine a slice of say 16 sectors, and eight disks, then instead of 6+2 disks, you could do 104+24 sectors with fountain codes and spread them across the disks. If you lose one complete disk and another one have a bad sector, you have lost just 17 sectors, and the remaining 7 redundant sectors give you a high chance of recovery. And you get slightly better storage efficiency than with RAID-6. However, single sector updates will still be expensive.
In terms of performance and safety, I think the standard RAID-6 Reed Solomon codes sounds better than fountain codes.
Fountain codes sounds much more appropriate for communication over a very lossy link. In that case a 10% chance of needing more data than expected doesn't mean data loss, it just means a 10% chance of the sender needing to compute for a bit longer to keep sending. That's a very reasonable tradeoff for getting the performance benefit from fountain codes.
Does anyone know if there is any practical and non-quantum
ENCRYPTION method that is potentially safe from quantum
cryptanalysis?
There is research going on in that area. I haven't been following it, but I know about one article that touches the subject. I haven't read the article, but if you are interested in that kind of stuff, you could read it and tell us what you think. http://eprint.iacr.org/2009/391.pdf
Are one-time pads (assuming they could be copied around safely)
proof against these techniques?
They are safe against eavesdropping the line. Of course you need to transport and store the pads safely, and correctly destroy them afterwards. Quantum cryptography is a way to exchange the pads safely almost on the fly. You are going to need a little bit of already exchanged pad in order to exchange more using quantum cryptography. If you have a few thousand bits already exchanged, you could use that with quantum cryptography to exchange a few millions of bits. And quantum encryption is more practical than quantum factoring.
I'm pretty sure there was a story like that about four years ago on slashdot as well. I think it was from Australia where the pigeons were carrying pictures home from some three day adventure trips.
In both cases they mention that some of the pigeons get lost, and here also that sometimes they are just too slow. Why not go for redundancy? Wouldn't it make sense to send two pigeons each carrying a copy. I think it would dramatically decrease the failure rate.
Of course to do such redundancy you would have to carry some device that could copy the pictures. Does there exist cameras, which can do it? I can imagine there are plenty of situations, where people would happily pay the extra cost for the data security, it would not only be for pigeons.
The slashdot summary says that. In the actual slides he claim that the PS3 code is about 20 times slower than the people who wrote it said, and that a single graphics card can achieve the same as 20 PS3s.
It was newsworthy in January when it was first presented to the CA's.
What was newsworthy at the time was mostly, that CAs and browsers were still using a flawed algorithm. As far as I know, most browsers will still accept MD5 signatures. There wasn't much news in the attack, it was well known that it would be possible. So really the news was just that the people responsible for the security of the web ignore known flaws until it has publicly been demonstrated that somebody is willing to spend time on actually performing the attack without making a profit from it. Thus the news was about IT security, but it was not news about cryptography.
It's newsworthy now because it's a significant per processor performance increase.
Assuming the factor of 1.14 from the slashdot summary is incorrect, and the factor of 20 from the slides is correct, then the increase is enough to be newsworthy. In that case the news is, that graphics cards hold an enormous amount of unused processing power. That's interesting news, but doesn't really have anything to do with security.
If you had read the article and not interjected your flawed interpretation, that would be obvious.
It's not my interpretation, it is taken directly from the slashdot summary.
The numbers don't add up no matter how I turn them. He claims to be getting 14% more performance from each graphics card than from each PS3. That means he need 12 machines with 24 graphics cards each to match the speed of a 215 node PS3 cluster. So because he get 14% more performance per node, he only need 34% more nodes to achieve the same performance. That does just not make sense to me. The 24 graphics cards in each machine also sounds unlikely. Maybe it was 24 in total, so 2 per machine. In that case 14% more performance per node means he need 89% fewer nodes. That does not make sense either. So, how are the numbers supposed to be interpreted?
I don't understand why anybody still finds it newsworthy when somebody come up with faster collision attacks against MD5. We already know, that collisions can be generated for MD5, and they can be generated fast enough, that we have to worry about it. It no longer matters exactly how fast they can be generated. If somebody managed to come up with a practical second preimage attack against MD5, then it would be newsworthy.
So I suppose it is time to work out a migration plan for whatever uses MD5
The first collision was demonstrated about five years ago. Anything that relied on collision resistance, should have been migrated away from MD5 at least four years ago. The attack in 2004 just wasn't taken serious enough.
The point of the attack is that you can change the file to whatever you want, prefix some ignored garbage, and end up with a file with the same md5.
What you are describing is a second preimage attack. Nobody have achieved that against md5. What has been achieved so far has only been collision attacks. The first collision attack against md5 was demonstrated in 2004. Later some better collision attacks were demonstrated, in which you can choose the prefixes. The chosen prefix attack works in the following way. Attacker chose two different prefixes of the same length. They can be anything, they don't even have to be the same file format. Then use the collision attack to produce some random data to append to the two prefixes about 128-192 bytes are appended to each file. After this the attacker can append anything he wants to both files, but this part has to be the same on both files. The two files will have the same md5 hash. The attack can also be used with a set of more than two files. You have a bunch of prefixes, you then use the attack on the smallest two of them, at which point those two files will be colliding, so you group them together and for the rest of the attack consider them as one. They grew a bit longer, so when you then go ahead and choose the two smallest files again, that could be two different files. Repeat the attack over and over again until there is only one group with all the files. If you started out with prefixes of identical length, you would be pairing the files in a binary tree structure and append a number of bytes that was logarithmic in the number of files.
I've heard of people who have rewired their entire houses to use 200V DC. [...] -- and there's no need for expensive inverters to turn your DC back into AC.
You can use that to drive light bulbs, but that is about it. Most equipment relies on the input being AC in order to transform it down to the voltage it needs. In order to make it work for any electronics more complicated than an old fashioned light bulb, you'd have to replace the power supply for each piece of equipment. It's much easier to just convert the DC power back into AC.
Since there was never any reason for the X server and the clients to need to use the same uid, why move the X server from root to the logged in user? It could as well be moved from root to a uid dedicated to the X server. Then you would get another level of separation, at essentially no price. (There is of course a caveat in case you have multiple X servers running at the same time, but that could be solved by allocating a uid per X server).
Does graphics mode switching inside the kernel mean that we can soon expect switching between VTs to work even if the X server is locked up? Or is the keyboard handling still going to prevent that? (Doing the switching from a remote login would work around the keyboard issue).
On MacOS X, the X server also runs as the logged-in user.
That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens to be implementing X on top of X, but it still doesn't need special privileges since it isn't controlling the hardware itself).
I tried visiting the site. After I had closed the first 100 security warning windows, I closed the tab. As far as I know, most browsers do give warnings whenever you are about to submit a form over an unencrypted connection. And as far as I know, most users disable those warnings. Any user who have those warnings turned on would notice this attack. I have seen some css variant a while back, that didn't produce the same kind of warnings. So to me it looks like this new attack is inferior to what was previously demonstrated. (Somebody suggested that the CPU usage would give away the attack. But if you have multiple tabs opens in is actually very difficult to find out which of them are responsible for the CPU and memory usage of the browser).
Not only that, when this chick reaches the age of consent, she'll be able to write her own check. Think of the line of pervs that will queue up for a piece of that poon-tang! Ever wanted to fuck a little girl? Here's you chance without breaking the law!
What's the age of consent where she lives? There are countries where it's 15, she is already past that age. But she isn't able to speak yet, she may simply not be able to consent, in which case it would be rape. AFAIK rape is illegal in all of the western world. If she was able to consent and take money for it, that would be prostitution, which is illegal in a lot of countries as well.
Even in the fail-stop model you cannot handle one out of two failing unless you also assume synchronous communication.
It sounds like this isn't functionality that Amazon provides, so it is up to the customers which implementation they want to use.
Given the possibility of undetected bitflips and temporary network partitioning, a fail-stop synchronous model seems like asking for trouble.
Customers shouldn't really need to run their own byzantine agreement system though. Amazon could provide such a service for their customers. Then customers could just run two instances of whatever they are running and have those two instances be clients of the byzantine agreement system. Of course if Amazon were to provide it, they would still have to spread the byzantine agreement system across four different locations and ideally use four different machines in each place for a total of 16. That way they could tolerate a total of five simultaneous failures, which would be equivalent to one location gone and one of the remaining 12 machines malfunctioning in some way. But if they only have two data centers, they would need to use third party hosting for some of those.
Is it illegal to support terrorism by remiss? The people who left those default passwords have indirectly supported terrorists, even if it was unintentional. Can they be sentenced for that, should they be? I think they ought to be fined for it, but I don't think they deserve as harsh a punishment as the people who abused the systems for economical gain.
Only one of Amazon's two zones went down so a well designed cloud app shouldn't have failed.
If you want to guarantee data integrity and consistent data between your instances, then you cannot tolerate one out of two going down. Byzantine agreement protocols can tolerate less than one third failures, so you would actually need four to tolerate one failure.
We had heard before that I/O performance and disk performance are the weaknesses of virtualization but we thought we could work around that by putting the job databases on an NFS export from a non virtualized server.
Sounds to me like they heard about some potential performance problem, and without understanding that problem or trying to compare performance of various solutions, they decided NFS was the solution for that performance problem.
Did they ever try using the virtual block devices provided by the virtualization rather than the NFS solution? My guess is that NFS was actually the reason for their performance problems.
I think the intention was to use the full packet. So fill up some packets with entirely encrypted covert channel data and ensure the TCP checksum is bad. Every packet retransmitted that way gives you more than 1400 bytes of actual payload. Of course if it is done that way, it can be distinguished from random corruption. Random corruption is more likely to flip individual bits.
If you just flip single bits, you get around 13 bits of covert payload per corrupted packet, because the offset of the corrupted bit could be encoding your information. It increases to 26 bits if you flip two bits. Flipping two bits can probably be done without anybody figuring out it is a covert channel. The recipient will of course have to compare the good and corrupted message to know which bits were intentionally flipped.
A covert channel done this way would still carry only a small amount of data, and even worse - it would have a huge error rate. The reason it would have a huge error rate is, that any actual bitflips would be misinterpreted as intentional. If however the sender and recipient have agreed beforehand on an algorithm for choosing which packets will carry the covert information, that source of corruption could get almost eliminated. They could share a common seed for a PRNG that choose 1 in 1000 packets to be corrupted. Then the recipient knows, any other corrupted packets are actual corruption. And if they agree on having two bits flipped in the covert packets, the recipient will know if the correct number of bits were flipped. Unfortunately dual bitflips may skew the statistics compared to real corruption, so single bitflips may be required.
The interesting part here is that more details have been released about what the flaw actually was.
But where did those details get released? They are not on the zdnet article in the link. Based on the vague description, I have a guess about what the problem probably is. You take cipher block you want to get decrypted and send it in the position in the stream where the length of a message would be. The server then decrypts it and finds the length. If the length is a 32 bit field but only lengths up to 2^14 are valid, then it would explain the numbers in the description. If the length is invalid, the receiver will immediately break the connection and all you know is, that the 32 bit value was larger than a valid length. If the length is valid, the attacker starts sending garbage one byte at a time to the recipient, until the recipient breaks the connection. Then the attacker knows the 32 bits.
This could be fixed by not breaking the connection immediately. A fix could work like this. First you find out after how many bytes the connection would be broken for the longest valid size of a packet. If you receive a message with invalid length or invalid checksum, you receive more bytes and throw them away until you have received the maximum number of bytes for a message. Only then you report the problem (and make sure not to tell the peer if it was invalid length or invalid checksum). If your peer interrupts the connection before you receive all the additional bytes, you behave exactly as if they had done so before you had enough bytes to verify the checksum.
Seen from the Earth the size of the Moon and the Sun appear roughly the same. In the clip you link to, the diameter of the Moon appears to be just one sixth of the Sun. Doesn't that mean it would have to have been taken about 2 million kilometers from the Moon? Do we actually have satellites in that high orbit? Or is the effect caused by something else?
Slashdot Mirror
The summary claims asteroids this size pass this close twice a year, and hit once in five years. That means a lot must have passed this close and not hit. But yet the summary also claims that it has been seen only twice before.
They are already spreading their users across many different servers. Maybe they could set up a couple of servers with different settings to make the game more accessible.
It does sound ridiculous at first, but if there is something simple they can do without ruining the game for everyone, why shouldn't they?
Anybody using a Mac can produce that character by pressing option+o. If you are using X and have a key mapped as compose, then you can produce it by pressing compose o /
The properties are quite similar to the Reed Solomon codes used for RAID-5 and RAID-6. The main difference according to your link is, a tradeoff between storage efficiency and CPU usage. For Reed Solomon adding parity disks causes CPU usage to grow quadratically, but the disk space used remains optimal. Fountain codes on the other hand will use more disk space, but CPU usage grows only linearly. With the one parity disk used for RAID-5, and the two typically used for RAID-6, the CPU usage is not a problem.
A problem with fountain codes is, that you don't know beforehand how many disks you are going to need for recovery. You'll absolutely need a safety margin there, which in itself is going to add more CPU time than you saved from using fountain codes to begin with. You'll probably need arrays with 10s of parity disks before it starts paying off. And at that point the time needed to read and write that many different disks every time you update a sector is going to be performance problem.
Instead of just doing parity between the disks, you could do parity that goes both across disks and within disks. Imagine a slice of say 16 sectors, and eight disks, then instead of 6+2 disks, you could do 104+24 sectors with fountain codes and spread them across the disks. If you lose one complete disk and another one have a bad sector, you have lost just 17 sectors, and the remaining 7 redundant sectors give you a high chance of recovery. And you get slightly better storage efficiency than with RAID-6. However, single sector updates will still be expensive.
In terms of performance and safety, I think the standard RAID-6 Reed Solomon codes sounds better than fountain codes.
Fountain codes sounds much more appropriate for communication over a very lossy link. In that case a 10% chance of needing more data than expected doesn't mean data loss, it just means a 10% chance of the sender needing to compute for a bit longer to keep sending. That's a very reasonable tradeoff for getting the performance benefit from fountain codes.
There is research going on in that area. I haven't been following it, but I know about one article that touches the subject. I haven't read the article, but if you are interested in that kind of stuff, you could read it and tell us what you think. http://eprint.iacr.org/2009/391.pdf
They are safe against eavesdropping the line. Of course you need to transport and store the pads safely, and correctly destroy them afterwards. Quantum cryptography is a way to exchange the pads safely almost on the fly. You are going to need a little bit of already exchanged pad in order to exchange more using quantum cryptography. If you have a few thousand bits already exchanged, you could use that with quantum cryptography to exchange a few millions of bits. And quantum encryption is more practical than quantum factoring.
That is an option, if you cannot find a smaller device to do the task.
I'm pretty sure there was a story like that about four years ago on slashdot as well. I think it was from Australia where the pigeons were carrying pictures home from some three day adventure trips.
In both cases they mention that some of the pigeons get lost, and here also that sometimes they are just too slow. Why not go for redundancy? Wouldn't it make sense to send two pigeons each carrying a copy. I think it would dramatically decrease the failure rate.
Of course to do such redundancy you would have to carry some device that could copy the pictures. Does there exist cameras, which can do it? I can imagine there are plenty of situations, where people would happily pay the extra cost for the data security, it would not only be for pigeons.
According to wireshark some of those are reserved to actual hardware vendors.
The slashdot summary says that. In the actual slides he claim that the PS3 code is about 20 times slower than the people who wrote it said, and that a single graphics card can achieve the same as 20 PS3s.
What was newsworthy at the time was mostly, that CAs and browsers were still using a flawed algorithm. As far as I know, most browsers will still accept MD5 signatures. There wasn't much news in the attack, it was well known that it would be possible. So really the news was just that the people responsible for the security of the web ignore known flaws until it has publicly been demonstrated that somebody is willing to spend time on actually performing the attack without making a profit from it. Thus the news was about IT security, but it was not news about cryptography.
Assuming the factor of 1.14 from the slashdot summary is incorrect, and the factor of 20 from the slides is correct, then the increase is enough to be newsworthy. In that case the news is, that graphics cards hold an enormous amount of unused processing power. That's interesting news, but doesn't really have anything to do with security.
It's not my interpretation, it is taken directly from the slashdot summary.
The numbers don't add up no matter how I turn them. He claims to be getting 14% more performance from each graphics card than from each PS3. That means he need 12 machines with 24 graphics cards each to match the speed of a 215 node PS3 cluster. So because he get 14% more performance per node, he only need 34% more nodes to achieve the same performance. That does just not make sense to me. The 24 graphics cards in each machine also sounds unlikely. Maybe it was 24 in total, so 2 per machine. In that case 14% more performance per node means he need 89% fewer nodes. That does not make sense either. So, how are the numbers supposed to be interpreted?
I don't understand why anybody still finds it newsworthy when somebody come up with faster collision attacks against MD5. We already know, that collisions can be generated for MD5, and they can be generated fast enough, that we have to worry about it. It no longer matters exactly how fast they can be generated. If somebody managed to come up with a practical second preimage attack against MD5, then it would be newsworthy.
The first collision was demonstrated about five years ago. Anything that relied on collision resistance, should have been migrated away from MD5 at least four years ago. The attack in 2004 just wasn't taken serious enough.
What you are describing is a second preimage attack. Nobody have achieved that against md5. What has been achieved so far has only been collision attacks. The first collision attack against md5 was demonstrated in 2004. Later some better collision attacks were demonstrated, in which you can choose the prefixes. The chosen prefix attack works in the following way. Attacker chose two different prefixes of the same length. They can be anything, they don't even have to be the same file format. Then use the collision attack to produce some random data to append to the two prefixes about 128-192 bytes are appended to each file. After this the attacker can append anything he wants to both files, but this part has to be the same on both files. The two files will have the same md5 hash. The attack can also be used with a set of more than two files. You have a bunch of prefixes, you then use the attack on the smallest two of them, at which point those two files will be colliding, so you group them together and for the rest of the attack consider them as one. They grew a bit longer, so when you then go ahead and choose the two smallest files again, that could be two different files. Repeat the attack over and over again until there is only one group with all the files. If you started out with prefixes of identical length, you would be pairing the files in a binary tree structure and append a number of bytes that was logarithmic in the number of files.
You can use that to drive light bulbs, but that is about it. Most equipment relies on the input being AC in order to transform it down to the voltage it needs. In order to make it work for any electronics more complicated than an old fashioned light bulb, you'd have to replace the power supply for each piece of equipment. It's much easier to just convert the DC power back into AC.
Since there was never any reason for the X server and the clients to need to use the same uid, why move the X server from root to the logged in user? It could as well be moved from root to a uid dedicated to the X server. Then you would get another level of separation, at essentially no price. (There is of course a caveat in case you have multiple X servers running at the same time, but that could be solved by allocating a uid per X server).
Does graphics mode switching inside the kernel mean that we can soon expect switching between VTs to work even if the X server is locked up? Or is the keyboard handling still going to prevent that? (Doing the switching from a remote login would work around the keyboard issue).
That isn't really a valid comparison, since Mac OS X doesn't run X natively. You can run an X server as an application, but that X server doesn't drive any hardware, it is just yet another application using the Mac OS X graphics system (which is otherwise incompatible with all other operating systems known to me). It's just like running an X server on Windows or Xnest on something else (I think Xnest is able to make a few shortcuts because it happens to be implementing X on top of X, but it still doesn't need special privileges since it isn't controlling the hardware itself).
I tried visiting the site. After I had closed the first 100 security warning windows, I closed the tab. As far as I know, most browsers do give warnings whenever you are about to submit a form over an unencrypted connection. And as far as I know, most users disable those warnings. Any user who have those warnings turned on would notice this attack. I have seen some css variant a while back, that didn't produce the same kind of warnings. So to me it looks like this new attack is inferior to what was previously demonstrated. (Somebody suggested that the CPU usage would give away the attack. But if you have multiple tabs opens in is actually very difficult to find out which of them are responsible for the CPU and memory usage of the browser).
What's the age of consent where she lives? There are countries where it's 15, she is already past that age. But she isn't able to speak yet, she may simply not be able to consent, in which case it would be rape. AFAIK rape is illegal in all of the western world. If she was able to consent and take money for it, that would be prostitution, which is illegal in a lot of countries as well.
Customers shouldn't really need to run their own byzantine agreement system though. Amazon could provide such a service for their customers. Then customers could just run two instances of whatever they are running and have those two instances be clients of the byzantine agreement system. Of course if Amazon were to provide it, they would still have to spread the byzantine agreement system across four different locations and ideally use four different machines in each place for a total of 16. That way they could tolerate a total of five simultaneous failures, which would be equivalent to one location gone and one of the remaining 12 machines malfunctioning in some way. But if they only have two data centers, they would need to use third party hosting for some of those.
Is it illegal to support terrorism by remiss? The people who left those default passwords have indirectly supported terrorists, even if it was unintentional. Can they be sentenced for that, should they be? I think they ought to be fined for it, but I don't think they deserve as harsh a punishment as the people who abused the systems for economical gain.
If you want to guarantee data integrity and consistent data between your instances, then you cannot tolerate one out of two going down. Byzantine agreement protocols can tolerate less than one third failures, so you would actually need four to tolerate one failure.
Sounds to me like they heard about some potential performance problem, and without understanding that problem or trying to compare performance of various solutions, they decided NFS was the solution for that performance problem.
Did they ever try using the virtual block devices provided by the virtualization rather than the NFS solution? My guess is that NFS was actually the reason for their performance problems.
I think the intention was to use the full packet. So fill up some packets with entirely encrypted covert channel data and ensure the TCP checksum is bad. Every packet retransmitted that way gives you more than 1400 bytes of actual payload. Of course if it is done that way, it can be distinguished from random corruption. Random corruption is more likely to flip individual bits.
If you just flip single bits, you get around 13 bits of covert payload per corrupted packet, because the offset of the corrupted bit could be encoding your information. It increases to 26 bits if you flip two bits. Flipping two bits can probably be done without anybody figuring out it is a covert channel. The recipient will of course have to compare the good and corrupted message to know which bits were intentionally flipped.
A covert channel done this way would still carry only a small amount of data, and even worse - it would have a huge error rate. The reason it would have a huge error rate is, that any actual bitflips would be misinterpreted as intentional. If however the sender and recipient have agreed beforehand on an algorithm for choosing which packets will carry the covert information, that source of corruption could get almost eliminated. They could share a common seed for a PRNG that choose 1 in 1000 packets to be corrupted. Then the recipient knows, any other corrupted packets are actual corruption. And if they agree on having two bits flipped in the covert packets, the recipient will know if the correct number of bits were flipped. Unfortunately dual bitflips may skew the statistics compared to real corruption, so single bitflips may be required.
Thanks. That was the part I didn't get at first. It all makes sense now.
But where did those details get released? They are not on the zdnet article in the link. Based on the vague description, I have a guess about what the problem probably is. You take cipher block you want to get decrypted and send it in the position in the stream where the length of a message would be. The server then decrypts it and finds the length. If the length is a 32 bit field but only lengths up to 2^14 are valid, then it would explain the numbers in the description. If the length is invalid, the receiver will immediately break the connection and all you know is, that the 32 bit value was larger than a valid length. If the length is valid, the attacker starts sending garbage one byte at a time to the recipient, until the recipient breaks the connection. Then the attacker knows the 32 bits.
This could be fixed by not breaking the connection immediately. A fix could work like this. First you find out after how many bytes the connection would be broken for the longest valid size of a packet. If you receive a message with invalid length or invalid checksum, you receive more bytes and throw them away until you have received the maximum number of bytes for a message. Only then you report the problem (and make sure not to tell the peer if it was invalid length or invalid checksum). If your peer interrupts the connection before you receive all the additional bytes, you behave exactly as if they had done so before you had enough bytes to verify the checksum.
Seen from the Earth the size of the Moon and the Sun appear roughly the same. In the clip you link to, the diameter of the Moon appears to be just one sixth of the Sun. Doesn't that mean it would have to have been taken about 2 million kilometers from the Moon? Do we actually have satellites in that high orbit? Or is the effect caused by something else?