I disagree with the assement that there is something wrong with the IA-32 opcode map. True, it's complex, it doesn't provide a lot of register flexibility; but compilers and internal register renaming make up for a lot of that.
What is truely brilliant about the IA-32 instruction set is that it compresses very nicely. Try to write a useful function in 64 bytes on any RISC architecture, and you'll see why.
Although it wasn't designed for this at the time, this has a very positive effect on performance - if we can squeeze more instructions into a smaller space, we have a smaller i-cache footprint, which definitely speeds things up, considering the memory bus bandwidth is the limiting factor, not the CPU.
I understand his lack of appreciation for all the stack references, but I don't think this is the proper solution. The d-cache already catches stack reads - if there were a way to map a page as non-cache writeback, and the OS mapped the stack pages appropriately, flushing with a writeback only before a context switch, I think you'd see memory bandwidth increase significantly . True, this may break a number of things, but those problems can be worked around. This would help a large class of stack-intensive applications - and many applications and servers written for performance are already stack intensive because of the d-cache read benefit and easy allocation of buffer pools (malloc() is usually expensive).
Course I don't have any of my architecture books on me right now, but I wouldn't be too terribly surprised if there is already a way to do this.
So I've read the patents, and they seem like a bunch of silly horse-puckey to me. The whole point is that "protected content" doesn't stay in memory when unsigned code is being executed. If a debugger gets run on the system, it renounces it's private keys that allow it to decode protected content.
What is to stop the entire system from running in a debugger, or an emulator for that matter? Sure, you might need a Palladium enabled CPU to proxy the authentication back to the Palladium OS - a classic man in the middle attack.
Until I hear about some way to stop that, I'm going to continue laughing at this entire scheme, since it will fall flat on it's face. Geez, I fire up VMware with a couple of tweaks, run the Palladium OS in that, and proxy the credentials from my real Palladium CPU, and obtain a scheme level break... how can these people continue to delude themselves?
It's been tried before, and done. The real problem is that an ideal stereoscopic projection is different for each viewer - it depends on the distance between the eyes. It's also difficult for an individual to judge when a stereoscopic projection is properly calibrated to their vision.
And if it's not properly calibrated, within half an hour, you have a real killer headache. Combine that with the fact that we are already really good at picking up 3-d visual information from 2-d projections, and I don't see this going much of anywhere in the near future. Especially at $10k.
Especially if you own stock in any of several large corporate entites currently pushing SAN data centers. And of course, since this will have to be government subsidized (ISPs balk at the cost), they can lock in contracts with only "government approved" vendors.
This is not a story about rights or law enforcement. Do you seriously think that volume of data can actually be useful? Oh, such and such person sent an e-mail around the beginning of January, maybe after bouncing through a SSH tunnel. Oh, and the e-mail was encrypted with 2048-bit RSA encryption.
If you can't solve that problem, this "exploitation" of privacy is nothing more than writing some giants check to several government members and corporate bigwigs. Folks, this is why the stock market was invented!
If a patent doesn't specifically mention a process in the list of claims, but the process is described in the patent, does the patent cover that process?
The "JPEG patent" doesn't list the JPEG method, nor does it list a technical description of the method in the list of claims. It does describe the JPEG algorithm in the body of the patent. Does the patent cover the JPEG algorithm?
You are 100% correct. They obtain an intermediate image between (delta between two different frames after motion compensation). Then, the DCT is applied to this delta, quantized, and the coefficients are encoded.
The steps applied to the delta are the core of the JPEG compression. However, they are not mentioned in the list of claims in the patent! Further, the patent itself points out prior art on the use of DCT quantization.
Basically, there is no way for this claim to stand, especially when it affects far too many people with deep pockets (possibly more important than the technical points).
From the patent it is obvious that this is a video (frame to frame) compression technique designed to maintain a near-constant bandwidth by varying the quality. The quality is changed by discarding DCT coefficients from a motion compensated delta between two frames of video. This is in effect the core of the JPEG algorithm when applied to a single frame; however, this is not claimed in the patent, and this same technique is mentioned in the prior art (background of the invention), suggesting it is not new.
Applicable part of the patent:
Cosine Transform
The coefficient differences between the input pixels from the present frame on lines 5 and the estimations from the previously reconstructed frame on lines 3 are formed by the difference circuit 10 on lines 23 and are expressed as follows:
e.sub.n (j,k)=f.sub.n (j,k)-.rho.(j,k)f.sub.N-1 (j+.DELTA.j,k+.DELTA.k) Eq. (4)
where.DELTA.j and.DELTA.k represent the vector values for the best match determined by the motion detector and where.rho.(j,k) represents the estimation. These differences within a N.times.N block are cosine transformed in transformer 11 to form the coefficient differences on lines 24. The cosine transform is defined as follows: ##EQU3## where w=u or v where (j,k) and (u,v) represent indices in the horizontal and vertical directions for the pixel difference and coefficient difference blocks, respectively, and where C(w) represents C(u) or C(v). The cosine transform restructures the spatial domain data into the coefficient domain such that it will be beneficial to the subsequent coding and redundancy removal processes.
Normalization
The coefficient differences, E.sub.n (u,v), are scaled according to a feedback normalization factor, D, on lines 25, from the output rate buffer 15 according to the relation,
I.sub.n (u,v)=E.sub.n (u,v)/D Eq. (6)
The scaling process adjusts the range of the coefficient differences such that a desired number of code bits can be used during the coding process.
Quantization
The quantization process in unit 13 is any conventional linear or non-linear quantization. The quantization process will set some of the differences to zeros and leave a limited number of significant other differences to be coded. The quantized coefficient differences on lines 28 are represented as follows:
I.sub.n (u,v)=Q[I.sub.n (u,v)] Eq. (7)
where Q[ ] is a quantization function.
It should be noted that a lower bound is determined for the normalization factor in order to introduce meaningful coefficient differences to the coder. Generally speaking, setting the minimum value of D to one is sufficient for a low rate compression applications involving transform blocks of 16 by 16 pixels. In this case the worst mean square quantization error is less than 0.083. This mean square error corresponds to a peak signal-to-quantization-noise ratio of 40.86 db which is relatively insignificant for low rate applications.
What is wrong with you? You doesn't not even spell "gramer" right. The correct speling was "grahmer", like the crackers you probably doesn't not eat too.
Magically changin checksums
on
Pet Bugs?
·
· Score: 2, Interesting
When doing an rcp from source machine to target machine, if sum is run on the rcp source machine, the value would sometimes be incorrect. After the rcp finishes, the value is correct, there is no data corruption, and the file was transfered correctly to the target machine. If ftp was used, the problem did not occur.
It took over 6 months and 12 people to find the problem. The hardware was a uniprocessor MIPS R10k with non-coherent cache. The processor is capable of doing speculative execution which can dirty cache lines. The processor doesn't back out dirty bits when the speculative path falls back. So you can have a piece of code like:
if (foo)
*bar = 1;
Even if foo is false, the speculative execution can cause the cachline containing bar to get marked dirty. Normally this doesn't cause a problem. However, if bar is used as a loop variable, and happens to point just past the end of a memory page, a cacheline for a subsequent page can be dirtied. If this page has an active DMA transfer in progress, then the first cacheline on that page can be overwritten with the dirty cacheline, corrupting the DMA data.
This was not a problem for userspace, since active DMA write pages were not mapped into userspace, but flipped in on completion of the DMA. In the kernel, the problem exists. The solution chosen at the time was to put a compiler workaround, which put a speculation stopping instruction at each conditional branch target. Since this compile switch was only used for the kernel, user binaries remained ABI compliant.
However, in "volatile" assembler portions of the kernel code (no compiler reordering permitted), this workaround had to be handcoded. After pouring through all the assembler by hand, no bugs were found. Finally a perl script was written which would check for store instructions lacking a speculation stopper. Some were found, and all discounted as harmless.
The problem turned out to be that the MIPS prefetch instruction allows you to pass a cache hint. There was a piece of checksum code that passed a write hint in a prefetch instruction. The fix turned out to be a 1 bit change: change the 7 prefetch code to a 3.
How would you propose to stop forged DDOS from netblock 0/0? Since this is how most DDOS tools operate, and one would assume that any credible attacker was able to send forged packets onto the net, I'd be very interested to know this. You can't solve the problem with upstream blocking unless you are willing to cut off a possibly very large portion of the net.
My proposal would be a giant lookup hash by IP, storing the number of active sessions between the protected network and the IP (or a CAM, but that may be kind of expensive). On receiving a SYN packet in "attack" mode, look up the IP address.
Now, if the number of sessions exceeds attack parameter, drop it and mark the IP as "attacking". Time out the IPs after a while to stop the hash from being huge.
If the number of sessions is zero, send a SYN-ACK, and mark the IP as "possible client". If the client responds with appropriate sequence numbers, proxy the tcp session to the target, forward the new packet, and increment the number of active sessions. If the client retransmits early, flag the IP as an attacker.
Now that is not perfect, but it will stop same IP-multiple session attacks, as well as making it harder on DDOS tools (must retransmit, but not too fast, limited to receivable IP addresses), which increases memory load, but most importantly means you can't forge addresses, so netblock blocks will work.
I don't think it's possible to come up with a generally acceptable definition for "malicious code". Prove me wrong.
Counterexamples:
Internet Explorer and Netscape both trying to become the default system browser, with or without user knowledge. Are these pieces of code being malicious to each other?
A trojan horse which requires willfull (but not knowing) participation from the user to install.
A piece of software which serves a controversial, but generally beneficial purpose. For example, a spam bot trap, or news cancellers.
A script kiddie proof buffer overflow exploit (even if it does just change/bin/sh to " bin sh". In hex though.)
Anti-virus software which could produce false positives and stop software packages from running.
A background ad-server which gets installed automatically, and unknowningly, by ISP or P2P client software. (Yes, I would like that to be considered malicious).
An auto update server which gets installed automatically, and unknowningly, by the OS, which transparently downloads new software components and security fixes as they are available. (That does serve a useful function, for some people).
I think it's quite funny that the codename "longhorn" refers to the beetle family, cerambycidae, well known pests of forests and ornamental plants. The larvae consist of worms that bore into the host, making it more susceptible to future infestation and disease.
The analogy between this and the Windows operating system invasion of the corporate desktop is quite amusing.
We know all PRNGs are periodic, and this is probably based on some variation of a LFSR. Given known methods to attack LFSRs and discover the internal state require a large enough sample size, we know
1. This is totally insecure for transfers larger than the PRNG period (XOR differential attack)
2. For data with known N-bit patterns, (like headers/trailers) we can remove the pattern and gain access to N-bits of the LFSR output.
3. CBC-mode encryption will not provide any more security, since the pad computation is an easily computable group operation (XOR is a group - DES is not, which is why 3-des and CBC work well). It does mean we can't extract trailer patterns unless the packet is short and redundant, however.
4. Since we most likely extract several dozen sequential bits of the LFSR, determining the LFSR internal state becomes much easier, especially as packet length increases. If an entire HTTP session uses a single key exchange, I'd say there is probably enough redundant data to crack the LFSR.
That said, with some simple enhancements, these obvious flaws are no longer present -
1) As part of the negotiated exchange, a random squawking size is agreed upon. Each packet is prefaced by a truly random squawk. The squawk size is computed to lie within bounds such that it can sufficiently mask bit patterns in the data.
2) The squawk + packet is compressed before applying the pad. Now the known patterns are effectively masked.
However, at this point, we've destroyed the usefullness of the algorithm, which was the fact that it required very little CPU power.
I'd guess that even with squawking, finding the pattern data is going to be too easy until compression, unless the squawk is so large that it dwarves the packet size, in which case the wire transmission is horribly inefficient.
So in all, a novel idea, which given more work could perhaps be useful, but in the form described right now, totally useless. And I can't see how it would take more than 4 hours to code and debug, let alone 4 years.
Actually, no. You have specified exactly how manual http proxies are supposed to work. What is broken in the practice of doing this transparently. The ISP is clearly doing this because they can't afford a better uplink and think customers are too dumb to enter proxy settings. Time to switch ISP.
You could request http://ipaddress, but that breaks multihosted web sites that switch on the request URL.
Didn't you realize that this is a conspiracy by the open source movement to put legal pressure on closed source companies? Only GPL'd software will be free of legal consequences, and as a result, the GNU software suite will flourish and take over the world. Look just below this story and you'll find the HURD announcement - it's already beginning.
Actually this will have no effect on Free OSes. The DRM data model can use individually keyed content, require online registration, and have DRM aware hooks in the OS to prevent exporting the real content keys. This is how Microsoft's DRM model works. I believe this is what Valenti is talking about when he talks about required DRM features. An OS that is completely unaware of DRM is still DRM compliant under this.
Some people are freaking out, thinking this will effectively ban any free-OS that allows unrestricted copying as a "circumvention device". This is simply not the case. This would make all existing computers circumvention devices, which is never going to happen. They do have substantial non-infringing uses, and have industry heavies to back them (IBM,HP,et al).
Copying the DRM-encrypted content has no effect, since it still can't be accessed. A DRM decoder could be implemented as a binary only module for Linux that enforced all the restrictions. As such, it could not be regarded as a circumvention device.
Distribution of the DRM decoder source would probably be prohibited by license agreements and copyrights with the DRM software authors.
The real issue is getting the DRM authors to produce or license a DRM codec that runs on free OS's.
DMCA makes reverse-engineering and distribution of software that can bypass DRM restrictions illegal. However, reverse-engineering and distribution of source code that accesses content and respects DRM restrictions would be technically legal. SSCA is an attempt to force any such software to prevent exposure of the private keys protecting the DRM content or the raw unencrypted data.
An interesting side note, it should still be legal to reverse-engineer and write software to access the DRM contenet, protecting all the data, and fulfulling all the DRM requirements. And since any such software would be perfectly legal, distributing it as source would be equally legal. It would be a trivial modification for most programmers to not respect the DRM requirements, or to expose the raw data.
Under higher temperate, gas will expand. So the atmosphere will expand, increasing in radius.
Since the earth has a very non-uniform density from center to outer atmospheric shell, the standard equation for moment of intertia does not apply, but if you consider the atmosphere a spherical shell, the midpoint of it's rotational mass has moved further from the center of the earth.
Thus, as the earth heats up, it spins slower.
It's the same effect you saw in the ice-skating in the Olympics - put out you arms and you spin slower.
Of course, this doesn't consider the fact that the expansion of the atmosphere reduces the density of the atmosphere, which may in fact slow or stop the heating of the earth. So it may be a chaotic cyclical process.
This pimp daddy is springing for DRC Echezeaux 1991 for the main course, and 1995 Yquem for desert. I haven't decided on the champagne yet, though... maybe Pol Roger?
Wouldn't you need more prey than predators to obtain a viable population? This would be much cooler as well if both predators and prey could mate with their own species, i.e exchange randomization factors for their strategies. Then the best would survive, and the dead (drained) could be recycled as offspring.
Slashdot Mirror
I disagree with the assement that there is something wrong with the IA-32 opcode map. True, it's complex, it doesn't provide a lot of register flexibility; but compilers and internal register renaming make up for a lot of that.
What is truely brilliant about the IA-32 instruction set is that it compresses very nicely. Try to write a useful function in 64 bytes on any RISC architecture, and you'll see why.
Although it wasn't designed for this at the time, this has a very positive effect on performance - if we can squeeze more instructions into a smaller space, we have a smaller i-cache footprint, which definitely speeds things up, considering the memory bus bandwidth is the limiting factor, not the CPU.
I understand his lack of appreciation for all the stack references, but I don't think this is the proper solution. The d-cache already catches stack reads - if there were a way to map a page as non-cache writeback, and the OS mapped the stack pages appropriately, flushing with a writeback only before a context switch, I think you'd see memory bandwidth increase significantly . True, this may break a number of things, but those problems can be worked around. This would help a large class of stack-intensive applications - and many applications and servers written for performance are already stack intensive because of the d-cache read benefit and easy allocation of buffer pools (malloc() is usually expensive).
Course I don't have any of my architecture books on me right now, but I wouldn't be too terribly surprised if there is already a way to do this.
So I've read the patents, and they seem like a bunch of silly horse-puckey to me. The whole point is that "protected content" doesn't stay in memory when unsigned code is being executed. If a debugger gets run on the system, it renounces it's private keys that allow it to decode protected content.
What is to stop the entire system from running in a debugger, or an emulator for that matter? Sure, you might need a Palladium enabled CPU to proxy the authentication back to the Palladium OS - a classic man in the middle attack.
Until I hear about some way to stop that, I'm going to continue laughing at this entire scheme, since it will fall flat on it's face. Geez, I fire up VMware with a couple of tweaks, run the Palladium OS in that, and proxy the credentials from my real Palladium CPU, and obtain a scheme level break... how can these people continue to delude themselves?
It's been tried before, and done. The real problem is that an ideal stereoscopic projection is different for each viewer - it depends on the distance between the eyes. It's also difficult for an individual to judge when a stereoscopic projection is properly calibrated to their vision.
And if it's not properly calibrated, within half an hour, you have a real killer headache. Combine that with the fact that we are already really good at picking up 3-d visual information from 2-d projections, and I don't see this going much of anywhere in the near future. Especially at $10k.
So does it support transparency, anti-aliased logos and gradient shading now... that's a pretty fancy hat.
Especially if you own stock in any of several large corporate entites currently pushing SAN data centers. And of course, since this will have to be government subsidized (ISPs balk at the cost), they can lock in contracts with only "government approved" vendors.
This is not a story about rights or law enforcement. Do you seriously think that volume of data can actually be useful? Oh, such and such person sent an e-mail around the beginning of January, maybe after bouncing through a SSH tunnel. Oh, and the e-mail was encrypted with 2048-bit RSA encryption.
If you can't solve that problem, this "exploitation" of privacy is nothing more than writing some giants check to several government members and corporate bigwigs. Folks, this is why the stock market was invented!
Can you answer this?
If a patent doesn't specifically mention a process in the list of claims, but the process is described in the patent, does the patent cover that process?
The "JPEG patent" doesn't list the JPEG method, nor does it list a technical description of the method in the list of claims. It does describe the JPEG algorithm in the body of the patent. Does the patent cover the JPEG algorithm?
You are 100% correct. They obtain an intermediate image between (delta between two different frames after motion compensation). Then, the DCT is applied to this delta, quantized, and the coefficients are encoded.
The steps applied to the delta are the core of the JPEG compression. However, they are not mentioned in the list of claims in the patent! Further, the patent itself points out prior art on the use of DCT quantization.
Basically, there is no way for this claim to stand, especially when it affects far too many people with deep pockets (possibly more important than the technical points).
From the patent it is obvious that this is a video (frame to frame) compression technique designed to maintain a near-constant bandwidth by varying the quality. The quality is changed by discarding DCT coefficients from a motion compensated delta between two frames of video. This is in effect the core of the JPEG algorithm when applied to a single frame; however, this is not claimed in the patent, and this same technique is mentioned in the prior art (background of the invention), suggesting it is not new. Applicable part of the patent: Cosine Transform The coefficient differences between the input pixels from the present frame on lines 5 and the estimations from the previously reconstructed frame on lines 3 are formed by the difference circuit 10 on lines 23 and are expressed as follows: e.sub.n (j,k)=f.sub.n (j,k)-.rho.(j,k)f.sub.N-1 (j+.DELTA.j,k+.DELTA.k) Eq. (4) where .DELTA.j and .DELTA.k represent the vector values for the best match determined by the motion detector and where .rho.(j,k) represents the estimation. These differences within a N.times.N block are cosine transformed in transformer 11 to form the coefficient differences on lines 24. The cosine transform is defined as follows: ##EQU3## where w=u or v where (j,k) and (u,v) represent indices in the horizontal and vertical directions for the pixel difference and coefficient difference blocks, respectively, and where C(w) represents C(u) or C(v). The cosine transform restructures the spatial domain data into the coefficient domain such that it will be beneficial to the subsequent coding and redundancy removal processes.
Normalization
The coefficient differences, E.sub.n (u,v), are scaled according to a feedback normalization factor, D, on lines 25, from the output rate buffer 15 according to the relation,
I.sub.n (u,v)=E.sub.n (u,v)/D Eq. (6)
The scaling process adjusts the range of the coefficient differences such that a desired number of code bits can be used during the coding process.
Quantization
The quantization process in unit 13 is any conventional linear or non-linear quantization. The quantization process will set some of the differences to zeros and leave a limited number of significant other differences to be coded. The quantized coefficient differences on lines 28 are represented as follows:
I.sub.n (u,v)=Q[I.sub.n (u,v)] Eq. (7)
where Q[ ] is a quantization function.
It should be noted that a lower bound is determined for the normalization factor in order to introduce meaningful coefficient differences to the coder. Generally speaking, setting the minimum value of D to one is sufficient for a low rate compression applications involving transform blocks of 16 by 16 pixels. In this case the worst mean square quantization error is less than 0.083. This mean square error corresponds to a peak signal-to-quantization-noise ratio of 40.86 db which is relatively insignificant for low rate applications.
What is wrong with you? You doesn't not even spell "gramer" right. The correct speling was "grahmer", like the crackers you probably doesn't not eat too.
http://slashdot.org/comments.pl?sid=34867&cid=3774 509
When doing an rcp from source machine to target machine, if sum is run on the rcp source machine, the value would sometimes be incorrect. After the rcp finishes, the value is correct, there is no data corruption, and the file was transfered correctly to the target machine. If ftp was used, the problem did not occur.
It took over 6 months and 12 people to find the problem. The hardware was a uniprocessor MIPS R10k with non-coherent cache. The processor is capable of doing speculative execution which can dirty cache lines. The processor doesn't back out dirty bits when the speculative path falls back. So you can have a piece of code like:
if (foo) *bar = 1;
Even if foo is false, the speculative execution can cause the cachline containing bar to get marked dirty. Normally this doesn't cause a problem. However, if bar is used as a loop variable, and happens to point just past the end of a memory page, a cacheline for a subsequent page can be dirtied. If this page has an active DMA transfer in progress, then the first cacheline on that page can be overwritten with the dirty cacheline, corrupting the DMA data.
This was not a problem for userspace, since active DMA write pages were not mapped into userspace, but flipped in on completion of the DMA. In the kernel, the problem exists. The solution chosen at the time was to put a compiler workaround, which put a speculation stopping instruction at each conditional branch target. Since this compile switch was only used for the kernel, user binaries remained ABI compliant.
However, in "volatile" assembler portions of the kernel code (no compiler reordering permitted), this workaround had to be handcoded. After pouring through all the assembler by hand, no bugs were found. Finally a perl script was written which would check for store instructions lacking a speculation stopper. Some were found, and all discounted as harmless.
The problem turned out to be that the MIPS prefetch instruction allows you to pass a cache hint. There was a piece of checksum code that passed a write hint in a prefetch instruction. The fix turned out to be a 1 bit change: change the 7 prefetch code to a 3.
There were 1 billion CD-Rs sold last year. Logically, all but 50 million are being used for piracy.
How would you propose to stop forged DDOS from netblock 0/0? Since this is how most DDOS tools operate, and one would assume that any credible attacker was able to send forged packets onto the net, I'd be very interested to know this. You can't solve the problem with upstream blocking unless you are willing to cut off a possibly very large portion of the net.
My proposal would be a giant lookup hash by IP, storing the number of active sessions between the protected network and the IP (or a CAM, but that may be kind of expensive). On receiving a SYN packet in "attack" mode, look up the IP address.
Now, if the number of sessions exceeds attack parameter, drop it and mark the IP as "attacking". Time out the IPs after a while to stop the hash from being huge.
If the number of sessions is zero, send a SYN-ACK, and mark the IP as "possible client". If the client responds with appropriate sequence numbers, proxy the tcp session to the target, forward the new packet, and increment the number of active sessions. If the client retransmits early, flag the IP as an attacker.
Now that is not perfect, but it will stop same IP-multiple session attacks, as well as making it harder on DDOS tools (must retransmit, but not too fast, limited to receivable IP addresses), which increases memory load, but most importantly means you can't forge addresses, so netblock blocks will work.
I don't think it's possible to come up with a generally acceptable definition for "malicious code". Prove me wrong.
/bin/sh to " bin sh". In hex though.)
Counterexamples:
Internet Explorer and Netscape both trying to become the default system browser, with or without user knowledge. Are these pieces of code being malicious to each other?
A trojan horse which requires willfull (but not knowing) participation from the user to install.
A piece of software which serves a controversial, but generally beneficial purpose. For example, a spam bot trap, or news cancellers.
A script kiddie proof buffer overflow exploit (even if it does just change
Anti-virus software which could produce false positives and stop software packages from running.
A background ad-server which gets installed automatically, and unknowningly, by ISP or P2P client software. (Yes, I would like that to be considered malicious).
An auto update server which gets installed automatically, and unknowningly, by the OS, which transparently downloads new software components and security fixes as they are available. (That does serve a useful function, for some people).
I think it's quite funny that the codename "longhorn" refers to the beetle family, cerambycidae, well known pests of forests and ornamental plants. The larvae consist of worms that bore into the host, making it more susceptible to future infestation and disease.
The analogy between this and the Windows operating system invasion of the corporate desktop is quite amusing.
We know all PRNGs are periodic, and this is probably based on some variation of a LFSR. Given known methods to attack LFSRs and discover the internal state require a large enough sample size, we know
1. This is totally insecure for transfers larger than the PRNG period (XOR differential attack)
2. For data with known N-bit patterns, (like headers/trailers) we can remove the pattern and gain access to N-bits of the LFSR output.
3. CBC-mode encryption will not provide any more security, since the pad computation is an easily computable group operation (XOR is a group - DES is not, which is why 3-des and CBC work well). It does mean we can't extract trailer patterns unless the packet is short and redundant, however.
4. Since we most likely extract several dozen sequential bits of the LFSR, determining the LFSR internal state becomes much easier, especially as packet length increases. If an entire HTTP session uses a single key exchange, I'd say there is probably enough redundant data to crack the LFSR.
That said, with some simple enhancements, these obvious flaws are no longer present -
1) As part of the negotiated exchange, a random squawking size is agreed upon. Each packet is prefaced by a truly random squawk. The squawk size is computed to lie within bounds such that it can sufficiently mask bit patterns in the data.
2) The squawk + packet is compressed before applying the pad. Now the known patterns are effectively masked.
However, at this point, we've destroyed the usefullness of the algorithm, which was the fact that it required very little CPU power.
I'd guess that even with squawking, finding the pattern data is going to be too easy until compression, unless the squawk is so large that it dwarves the packet size, in which case the wire transmission is horribly inefficient.
So in all, a novel idea, which given more work could perhaps be useful, but in the form described right now, totally useless. And I can't see how it would take more than 4 hours to code and debug, let alone 4 years.
Actually, no. You have specified exactly how manual http proxies are supposed to work. What is broken in the practice of doing this transparently. The ISP is clearly doing this because they can't afford a better uplink and think customers are too dumb to enter proxy settings. Time to switch ISP.
You could request http://ipaddress, but that breaks multihosted web sites that switch on the request URL.
Didn't you realize that this is a conspiracy by the open source movement to put legal pressure on closed source companies? Only GPL'd software will be free of legal consequences, and as a result, the GNU software suite will flourish and take over the world. Look just below this story and you'll find the HURD announcement - it's already beginning.
Sorry, I just had to
Actually this will have no effect on Free OSes. The DRM data model can use individually keyed content, require online registration, and have DRM aware hooks in the OS to prevent exporting the real content keys. This is how Microsoft's DRM model works. I believe this is what Valenti is talking about when he talks about required DRM features. An OS that is completely unaware of DRM is still DRM compliant under this.
Some people are freaking out, thinking this will effectively ban any free-OS that allows unrestricted copying as a "circumvention device". This is simply not the case. This would make all existing computers circumvention devices, which is never going to happen. They do have substantial non-infringing uses, and have industry heavies to back them (IBM,HP,et al).
Copying the DRM-encrypted content has no effect, since it still can't be accessed. A DRM decoder could be implemented as a binary only module for Linux that enforced all the restrictions. As such, it could not be regarded as a circumvention device.
Distribution of the DRM decoder source would probably be prohibited by license agreements and copyrights with the DRM software authors.
The real issue is getting the DRM authors to produce or license a DRM codec that runs on free OS's.
DMCA makes reverse-engineering and distribution of software that can bypass DRM restrictions illegal. However, reverse-engineering and distribution of source code that accesses content and respects DRM restrictions would be technically legal. SSCA is an attempt to force any such software to prevent exposure of the private keys protecting the DRM content or the raw unencrypted data.
An interesting side note, it should still be legal to reverse-engineer and write software to access the DRM contenet, protecting all the data, and fulfulling all the DRM requirements. And since any such software would be perfectly legal, distributing it as source would be equally legal. It would be a trivial modification for most programmers to not respect the DRM requirements, or to expose the raw data.
Under higher temperate, gas will expand. So the atmosphere will expand, increasing in radius.
Since the earth has a very non-uniform density from center to outer atmospheric shell, the standard equation for moment of intertia does not apply, but if you consider the atmosphere a spherical shell, the midpoint of it's rotational mass has moved further from the center of the earth.
Thus, as the earth heats up, it spins slower.
It's the same effect you saw in the ice-skating in the Olympics - put out you arms and you spin slower.
Of course, this doesn't consider the fact that the expansion of the atmosphere reduces the density of the atmosphere, which may in fact slow or stop the heating of the earth. So it may be a chaotic cyclical process.
sqrt((r2-r1)*(r2-r1)*a+(g2-g1)*(g2-g1)*b+(b2-b1)*( b2-b1)*c)
.9025, c = .0081
Try a = 1, b =
This is based on the tri-stimulus cone model, I used a,b,c (a normalized) based on the fraction on light received by the human eye.
Mango software already does this. The file part anyways.
This pimp daddy is springing for DRC Echezeaux 1991 for the main course, and 1995 Yquem for desert. I haven't decided on the champagne yet, though... maybe Pol Roger?
Wouldn't you need more prey than predators to obtain a viable population? This would be much cooler as well if both predators and prey could mate with their own species, i.e exchange randomization factors for their strategies. Then the best would survive, and the dead (drained) could be recycled as offspring.
Hmm. Isn't this constant derived from the speed of light? Very convenient, yes?