Aside from the complete failure of scientific notation, you need to take into account that if we suddenly came across a black hole made of pure accessible gold or oil, the prices on said commodity would drop to below nothing.
Leave it to the Republicans to try mining a black hole for resources;)
Give Ted Stevens a break on the "series of tubes" analogy. He was trying to describe saturation of available bandwidth in terms of water going through a pipe. It is a particularly good analogy given that educational metaphor for electrical systems are usually in terms of water in a pipe (or tube). All the snickering about "tubes" makes us look stupid to the community that knows about these things. Among the slashdot community it is just self-degrading. We should know better and attack him with points of merit.
Sorry, the Internet is not a serial communication network. All traffic is sent in packets of roughly the same priority. An email does not wait for a torrent to complete before going through the tubes, pieces of both go through at the same time and the email, being smaller, will get through first. On average, high traffic just slows down the delivery of all packets. At best, he should have just described Internet congestion as a highway with a traffic jam, because that would be so much more appropriate. Maybe it's because Alaska doesn't have traffic jams:)
Flushing an entire cache only to reload it with the same contents moments later is not only slow but it's moronic. However Intel doesn't give you much choice. Architectures implementing caches which tag entries with address space identifiers can avoid global invalidation and allow entries from any combination of processes to age out of cache normally.
That would definitely be useful, but it seems like a much larger cache would be required if there were a different address space for each process and hundreds of processes per system. Basically each page table entry in the cache would need entries for each address space that could access it, or it would need to store an owner id that could be matched against a process id or something similar. Another possibility is a capability based approach where each cache entry has an identifier and each process has a list of capability identifiers that allow it to access cache entries with matching identifiers. I haven't seen any architectures that actually implement a smart cache like you've mentioned, so I'd be interested in knowing which ones you're referring to.
No. Think of user and group IDs in Unix. A setUID program can jump between levels of privilege quickly because this only involves changing an integer or two. This wouldn't be the case if, for instance, privileged access to files were instead implemented by changing permissions on all the files themselves. It's easier to change your credentials than to change everything else.
I think the problem is that it's hard to implement permissions with only a uid and gid. There needs to be an arbitrary number of identifiers (capabilities) that a process can hold, or each page needs an arbitrary number of ACLs for user and group identifiers. I suppose the CPU could support loading a fixed set of identifiers or capabilities for a process at any given time, and the process could securely swap them out as necessary, but this could have a performance impact if a large number of different identities needed to be used. Perhaps I'm missing something about the security model you're talking about, though.
Not only are there two parity drives, but the operating system can perform automatic scanning of the drives to ensure that all data and parity disks are correct and silently correct any errors that occur on only one disk. It only takes a few days to scan 12 TB, and if this is done often enough the probability of a two failed disks plus a previously undetected unrecoverable error on a third disk is quite a bit lower than the failure rate for RAID5. RAID5 volumes can be automatically scanned, but if corruption is detected there's no way to know which of the disks was actually incorrect, barring an actual message from the hard disk. Silent corruption is a much bigger enemy of RAID5 than RAID6.
I don't know why the article focuses on RAID5; RAID1 or RAID10 will have exactly the same issues at a slightly lower frequency than RAID5, but more frequently than RAID6.
Ultimately, the solution is simply more redundancy, or more reliable hardware. RAID with 3 parity disks is not much slower than RAID6, and dedicated hardware or increasing CPU speed will take care of that faster than drive speeds increase.
The extent layer itself would only be concerned with allocating extents of some requested size, and actually storing the data. But this would be enough information to effectively handle mirroring, striping, snapshotting, copy-on-write, etc.
I think the biggest problem is that the filesystem would lose the ability to make intelligent decisions about where to allocate extents from and how to index them, without the scheme devolving into a "allocate one extent the size of the disk and manage it locally" being the best performer. For instance, how should a file system agnostic extent management system allocate and index 100 extents? 1,000,000,000,000 extents? What would the inter-block slack policy be? Intra-block slack? Most of the hard parts of reliably packing extents into a block device are done different ways by different file systems for different reasons. Abstracting that out of the file system layer would probably not help performance or reliability.
ext3 is probably already close enough to what you describe; it has a way of allocating extents and naming them (files) and using them for whatever you want. You could implement RAID on top of independent ext3 file systems pretty easily, but it would be inefficient. In a traditional RAID, block access is a simple calculation based on the stripe size, block size, and number of drives. In a RAID on top of extents, it would be necessary to store a list of extents that each stripe uses in order to locate a block within that stripe.
Not exactly. To effectively change the actual permissions that the permissions rings allow, stacks, segment registers, i/o permission bitmaps, and page tables (among other things) have to be changed. Generally this means reading values from memory into caches, which is slow. Probably the slowest of them all is the page cache. Invalidating the entire page cache is godawful slow, and is necessary if each separate user-space has a truly private address space and not simply a chunk out of the entire virtual address space. Even for operating systems that partition the virtual address space into regions for each user process, the local descriptor (or equivalent) table for segment access needs to be reloaded. This has to happen for every cross-privilege-level call. It is *much* faster to simply call another kernel mode function (push some stuff on the stack, change the instruction register, and you're done) without messing with caches.
In fact, it would be even faster to not separate the kernel and user space processes at all, and instead use formal verification or a virtual machine (which really just means a smaller instruction set that's easier to verify) to prove that no user process could ever mess with the kernel or other processes. Virtual machines for languages are essentially at this stage today; they implement what would constitute a kernel as the run-time level portions of the virtual machine, running the virtualized software in the same address space. There have been some attacks based on virtual machine weaknesses or memory corruption that break the protection model by changing data structures so that they violate the security model. This can happen in OS's that use hardware protection as well, there are just fewer places in memory that random changes can cause problems (just the page tables and other security paraphernalia), making it less likely.
Prenatal tests (amniocentesis), test tube babies, and sperm and egg banks already provide more than enough genetic material to radically change the gene pool. Once we allow commonplace genetic engineering of human offspring, evolution will occur rapidly. Don't assume that human whims not under the control of natural selection; the difference is that the genes that survive will serve humanity more than themselves, since humans can now impose their own fitness functions. All it will do is speed up evolution with a new set of pressures, and with luck let us avoid a little bit of our own genes' selfishness along the way. Hopefully our new basic elements of natural selection will be human comfort and enjoyment and not merely allele frequencies.
CNN has had threearticleswritten by Ron Paul about the tanking economy and election in the last month. Two that I know of were linked from the front page. Barely a peep about him when he was running for President.
Computers can get smarter, or the human interrogators can get stupider. If you stuck most of these chatterbots on AOL/Myspace/Youtube they'd be the most articulate conversationalists around.
Re:DRM Music where 'Managing Server' is Gone
on
DMCA Exemption Time
·
· Score: 1
3. Computer programs protected by dongles that prevent access due to malfunction or damage and which are obsolete. A dongle shall be considered obsolete if it is no longer manufactured or if a replacement or repair is no longer reasonably available in the commercial marketplace.
This is so similar to the case of DRM'd music tracks where the DRM servers have been turned off that it would probably be easy to get an exception for decrypting those tracks. Interestingly, there isn't a known way to do that once those DRM servers are completely unavailable, as far as I know. Isn't the whole point that the media is encrypted with some key, and the DRM server provides the key each time the user wants to play it? That means there is no legal way to store that decryption key BEFORE the DRM server goes belly up, and no way to get the key afterward.
What really needs to get added as an exception is an unconditional fair use exception to allow any person to create at least 1 permanent backup copy in a format of their choice (important) for backup in the event of data loss of any DMCA protected media on a storage device that they own. Data loss should cover not only scratching a DVD but also losing your DRM server permanently. The problem really boils down to ownership, of what, and by whom. When I "buy" a DVD, I expect that I will "own" the physical media and be able to watch the movie on it forever. Not until some company decides to stop making DVD players (it'll happen eventually), or the physical medium gets scratched. The implication of owning a copy of a work is that, with appropriate care, it has an indefinite lifespan. Since it's so bleeding obvious that computers are good at making redundant copies for backup purposes, it's insane to pretend that the works on physical mediums shouldn't have redundant backups. After all, there's already partial redundant backups on the DVD in the form of reed solomon codes, so why not just another copy on a hard disk somewhere? Information theory should drive policy in the information age, not the other way around.
Since the encryption is done at the block device layer, it shouldn't be part of the file system but rather a part of the encryption layer. Except from that detail, I agree with you. However doing it is tricky. When you take a logical sector with 512 bytes of data and put it together with a small IV, it no longer fits in a 512 bytes sector. So you have to come up with a layout on disk that is efficient. And then you have the problem of updating it. Because you cannot write two sectors to disk atomically (with some disks you can't even write one). So you end up having the potential of data loss if an update does not complete because of a power failure. And the data loss is not guaranteed to affect only the logical sector you were writing at the time. I am still thinking about the problem. A raid layer have some similar problems, and I have been considering whether merging those two layers would help solving this problem. A can see a few other advantages you could get from merging a raid layer with an encryption layer.
Basically the IV's themselves would require a journal. To make the file system trusted as well as private, an HMAC for each block should be stored next to its IV, and this helps significantly with a journalling scheme. Reserve enough of the first sectors of the underlying device to store an IV and HMAC for each block, and some more sectors for the journal. I don't have much experience with actual file system journalling, but it seems to be like the simplest scheme is a full block for a header (so that it's an entire sector) with the block number, an HMAC of the journaled IV+HMAC block, and then followed by a complete IV+HMAC block in the next adjacent block. The best part of the scheme is that it's readily apparent whether a given journal block should be applied to the IV+HMAC sectors; just compare every block that the IV+HMAC is for and see if it properly decrypts and validates the block. If it does, write it to the main IV+HMAC location. If not, compare the original IV+HMAC for those blocks and merge them together to recover as much data as possible, write this new block to the journal, and then into the main IV+HMAC area.
Basically, if a device is composed of N blocks of size B, and you're using I-byte IVs and H-byte HMACS, you need N*(B/(I+H)) blocks for the IV+HMAC area at the start of the disk, and the individual IV+HMAC for a block C is stored at byte offset C*(I+H) in that area. Pretty simple mapping, and the journal would just store whole blocks from that area when an update needed to be made. The journaled block would be written first, and then the encrypted block, and finally an update to the main IV+HMAC storage area. That would ensure the most recoverable possibility in the case of data loss at any point. Obviously a write to an encrypted block that fails half way through is completely lost, but that's a problem for the file system at a higher layer to deal with, since that happens with physical devices as well. The journal could just be a simple FIFO written in ascending order and then repeating from the beginning while ensuring that any additions to the journal are actually flushed to the main IV+HMAC area at some point before it's overwritten. The entire journal would be examined every time the file system was mounted to see if anything needed to be replayed or recovered. Since disks don't always order writes properly, it would be good to always check both the normal location for an IV+HMAC as well as what's in the journal for any given block, because the journal may actually be more stale than the normal location.
I've been working on developing a file system based on hash trees as well, which is a pretty similar concept and could support encryption pretty cheaply as an addition of IVs to the entries in the hash tree. There's some advantages to having a disk layout like I described for storing the hash tree, because storing indexes to block locations is not necessary if the hash for any given block is always at a given offset on the disk, with a jour
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.
LRW should fall to the bitmap attack presented in the article, so long as the bitmap is overwritten in place between ciphertexts. Any other weakness in LRW using the same key is minimized unless you are filling your disk with 127th degree polynomials in GF(2) represented as 128-bit vectors, that happen to differ from each other by n*k in GF(2) where n is the sector number they're stored in and k is the LRW tweak key. Most people don't do that. The probability of doing so with normal use is roughly the probability of accidentally guessing the tweak key.
The only real solution for the bitmap problem is modification of the file system to contain secure IVs for each block on the disk. Reusing IVs has *always* been shown to be a bad idea. It's broken more thought-to-be-secure schemes than I can count.
As an aside, once I actually found two files from a Slackware distribution that were detectable inside a truecrypt volume. One problem truecrypt had back then was that they were using 512 byte CBC blocks, while most file systems used larger blocks, so it was trivial to insert a file that would guarantee that the resulting ciphertext would be vulnerable to detection by starting at an even sector boundary and having just simple bit differences. I am guessing that in both cases the files being detected were executables with a large dynamic link section, since that would contain a whole lot of simple offsets that could match up with the sector IV vulnerability.
Multiply however many hours you worked on the project beforehand by $300 or $500 an hour, whatever you think a contractor would charge. Make them pay that up front, since you'll never see the benefit of that labor again if you take the job. That might sweeten the deal for you.
You'll have to decide on your own whether abandoning a hobby you like is worth a lot of money.
Mental poker is the general name for cryptographic protocols that can be used to securely play games of chance and hidden information with no possibility of cheating because of a single trusted server. Obviously collusion between legitimate players in the game can still occur, but I can't believe that anyone would even consider playing online poker (read: giving lots and lots of money to some guy online who promises that he won't steal it) without some sort of assurance that the underlying software wasn't as fair as an actual table with physical cards.
Kicked out from Afghanistan by the US and its allies, Osama could very well have patched up his differences with Saddam, and begin a mutually-useful cooperation.
Saddam hated Osama as much as he hated the Kurds. Osama had as much chance of walking into downtown New York and asking for asylum.
The existence of piracy does not magically give me an extra $200 a year that I could have spent on music or movies. I have the same amount of money I did last year (or less, with the wild inflation), so the MAFIAA would get roughly the same amount of money from me whether or not I could pirate things.
Via piracy I can never view every single movie ever made, or every song ever produced, which means that if I happen to see a few movies this year that I couldn't have afforded otherwise, it will *not* cut into the amount of money I'll spend next year on music and movies.
(X) technical ( ) legislative ( ) market-based ( ) vigilante approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses:
For encryption, PGP keyservers need to support email address lookup, but for signing it should be sufficient to work with the key IDs (hashes) instead. Looking up certificates or PGP public keys by their hash from public key servers turns email address harvesting into a brute force problem for spammers.
() Mailing lists and other legitimate email uses would be affected. ( ) No one will be able to find the guy or collect the money ( ) It is defenseless against brute force attacks
PGP and X.509 certs are secure against cryptographic attacks.
( ) It will stop spam for two weeks and then we'll be stuck with it ( ) Users of email will not put up with it
If people can deal with a green/red bar for their SSL connections, they could deal with color coding for email addresses.
( ) Microsoft will not put up with it ( ) The police will not put up with it ( ) Requires too much cooperation from spammers ( ) Requires immediate total cooperation from everybody at once
Almost. It would require cooperation from at least all the major web mail vendors at once.
( ) Many email users cannot afford to lose business or alienate potential employers
They can still benefit from signed messages while doing traditional spam filtering for unsigned messages. If they sign their own messages, they will contribute to the solution.
( ) Spammers don't care about invalid addresses in their lists ( ) Anyone could anonymously destroy anyone else's career or business
It would be difficult to get enough people to revoke trust in an individual to make a difference, since those revocations would be publicly visible and make retaliation revocation possible.
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it ( ) Lack of centrally controlling authority for email
Partially, although RFCs are the de-facto controlling authority for email, and S/MIME and PGP are already established standards. Simply using them would require some motivation.
( ) Open relays in foreign countries ( ) Ease of searching tiny alphanumeric address space of all email addresses ( ) Asshats ( ) Jurisdictional problems ( ) Unpopularity of weird new taxes ( ) Public reluctance to accept weird new forms of money ( ) Huge existing software investment in SMTP ( ) Susceptibility of protocols other than SMTP to attack ( ) Willingness of users to install OS patches received by email ( ) Armies of worm riddled broadband-connected Windows boxes
It would make getting rooted much more damaging to individuals who had their email identity stolen for spamming. CRLs would fix that address, but make it a pain for individual users. That, hopefully, would be good selection pressure for secure PCs.
( ) Eternal arms race involved in all filtering approaches ( ) Extreme profitability of spam ( ) Joe jobs and/or identity theft
Trojans stealing private keys could make more convincing identity theft. That's a local security problem, not a spam problem.
( ) Technically illiterate politicians ( ) Extreme stupidity on the part of people who do business with spammers ( ) Dishonesty on the part of spammers themselves ( ) Bandwidth costs that are unaffected by client filtering ( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
Obviously the idea has been around for a while. Sometimes it just takes a long time for good ideas to adopted.
The PGP web of trust or a hierarchical PKI solves the spam problem. People will revoke their trust in a key used for spamming, and be much less likely to trust a key from the same person again, and Verisign and other companies will stop issuing certificates to entities that send spam.
Obviously some spam will be generated because it's always necessary for new people to enter the trust network, but ultimately there will form a core group of trust or certificates that never send any spam because they're trusted by people who don't like spam. Getting into that group will require the trust of enough other trusted people as to make spam almost nonexistent.
The problem with the idea is getting enough people into the trusted group to make it effective at both preventing spam and incorporating new legitimate users into the trust group quickly and effectively so they can communicate.
As a libertarian I am reluctantly forced to concede that it can be acceptable to sell ones and zeroes, and to forbid the buyer, as a condition of that sale, from redistributing those ones and zeroes without the seller's permission. This is acceptable because all things that are not forbidden are allowed, no matter how repugnant we might find them, and the only things that are forbidden are those which violate people's rights (namely, initiation of force and/or fraud).
So this is a little off topic, but do human rights really include the right to give up the fundamental right of free speech? If so, then why not give up the right to liberty and allow slavery as well? Or the right to life, and allow people to sign up for soylent green distribution? Because human rights are inalienable, I have trouble with laws that prevent the truth from being known by certain individuals. It is absolutely true that if you take an MPEG2 stream from a DVD and follow a specific series of mathematical operations on the bits, you can display a series of images as a motion picture. I also think it's an affront to the inalienable right of liberty to restrict anyone from performing those same mathematical steps. Copyrights and patents are a form of ownership of people's minds and bodies by hindering their actions beyond what is necessary to respect other people's natural rights; in essence, slavery.
I have no problem with people keeping secrets, but secret algorithms can't be useful for things like distributing compressed media, nor can public algorithms with secrets "hidden" in the media.
Try getting a video card with DVI or HDMI out that connects to your TV. It's much easier to manage a movie library with a big hard disk instead of a shelf of DVDs.
I've bought 5 or 6 DVD players over the years that have subsequently broken. Since I don't get a refund for the perfectly good mathematics that the patent on MPEG2 covers when that player breaks, I feel completely morally justified in continuing to use mplayer to watch DVDs.
Yeah, but unlike traditional old time nations (China, India, etc.) they weren't able to actually occupy and control their own country for any great length of time. I'd think shared ownership and governance with any number of other people whose ancestors have occupied Israel over the centuries would be a bit more fair.
To me, it sounds a lot like giving the U.S. back to native Americans, or giving Australia back to the Aboriginals. Impractical and sure to make a lot of people angry. It's not like genocide wasn't committed against those original occupants either. "Reservations" would be more like giving Israel the Gaza Strip and leaving everything else for the Palestinians.
Slashdot Mirror
Aside from the complete failure of scientific notation, you need to take into account that if we suddenly came across a black hole made of pure accessible gold or oil, the prices on said commodity would drop to below nothing.
Leave it to the Republicans to try mining a black hole for resources ;)
Give Ted Stevens a break on the "series of tubes" analogy. He was trying to describe saturation of available bandwidth in terms of water going through a pipe. It is a particularly good analogy given that educational metaphor for electrical systems are usually in terms of water in a pipe (or tube). All the snickering about "tubes" makes us look stupid to the community that knows about these things. Among the slashdot community it is just self-degrading. We should know better and attack him with points of merit.
Sorry, the Internet is not a serial communication network. All traffic is sent in packets of roughly the same priority. An email does not wait for a torrent to complete before going through the tubes, pieces of both go through at the same time and the email, being smaller, will get through first. On average, high traffic just slows down the delivery of all packets. At best, he should have just described Internet congestion as a highway with a traffic jam, because that would be so much more appropriate. Maybe it's because Alaska doesn't have traffic jams :)
Flushing an entire cache only to reload it with the same contents moments later is not only slow but it's moronic. However Intel doesn't give you much choice. Architectures implementing caches which tag entries with address space identifiers can avoid global invalidation and allow entries from any combination of processes to age out of cache normally.
That would definitely be useful, but it seems like a much larger cache would be required if there were a different address space for each process and hundreds of processes per system. Basically each page table entry in the cache would need entries for each address space that could access it, or it would need to store an owner id that could be matched against a process id or something similar. Another possibility is a capability based approach where each cache entry has an identifier and each process has a list of capability identifiers that allow it to access cache entries with matching identifiers. I haven't seen any architectures that actually implement a smart cache like you've mentioned, so I'd be interested in knowing which ones you're referring to.
No. Think of user and group IDs in Unix. A setUID program can jump between levels of privilege quickly because this only involves changing an integer or two. This wouldn't be the case if, for instance, privileged access to files were instead implemented by changing permissions on all the files themselves. It's easier to change your credentials than to change everything else.
I think the problem is that it's hard to implement permissions with only a uid and gid. There needs to be an arbitrary number of identifiers (capabilities) that a process can hold, or each page needs an arbitrary number of ACLs for user and group identifiers. I suppose the CPU could support loading a fixed set of identifiers or capabilities for a process at any given time, and the process could securely swap them out as necessary, but this could have a performance impact if a large number of different identities needed to be used. Perhaps I'm missing something about the security model you're talking about, though.
Not only are there two parity drives, but the operating system can perform automatic scanning of the drives to ensure that all data and parity disks are correct and silently correct any errors that occur on only one disk. It only takes a few days to scan 12 TB, and if this is done often enough the probability of a two failed disks plus a previously undetected unrecoverable error on a third disk is quite a bit lower than the failure rate for RAID5. RAID5 volumes can be automatically scanned, but if corruption is detected there's no way to know which of the disks was actually incorrect, barring an actual message from the hard disk. Silent corruption is a much bigger enemy of RAID5 than RAID6.
I don't know why the article focuses on RAID5; RAID1 or RAID10 will have exactly the same issues at a slightly lower frequency than RAID5, but more frequently than RAID6.
Ultimately, the solution is simply more redundancy, or more reliable hardware. RAID with 3 parity disks is not much slower than RAID6, and dedicated hardware or increasing CPU speed will take care of that faster than drive speeds increase.
The extent layer itself would only be concerned with allocating extents of some requested size, and actually storing the data. But this would be enough information to effectively handle mirroring, striping, snapshotting, copy-on-write, etc.
I think the biggest problem is that the filesystem would lose the ability to make intelligent decisions about where to allocate extents from and how to index them, without the scheme devolving into a "allocate one extent the size of the disk and manage it locally" being the best performer. For instance, how should a file system agnostic extent management system allocate and index 100 extents? 1,000,000,000,000 extents? What would the inter-block slack policy be? Intra-block slack? Most of the hard parts of reliably packing extents into a block device are done different ways by different file systems for different reasons. Abstracting that out of the file system layer would probably not help performance or reliability.
ext3 is probably already close enough to what you describe; it has a way of allocating extents and naming them (files) and using them for whatever you want. You could implement RAID on top of independent ext3 file systems pretty easily, but it would be inefficient. In a traditional RAID, block access is a simple calculation based on the stripe size, block size, and number of drives. In a RAID on top of extents, it would be necessary to store a list of extents that each stripe uses in order to locate a block within that stripe.
Not exactly. To effectively change the actual permissions that the permissions rings allow, stacks, segment registers, i/o permission bitmaps, and page tables (among other things) have to be changed. Generally this means reading values from memory into caches, which is slow. Probably the slowest of them all is the page cache. Invalidating the entire page cache is godawful slow, and is necessary if each separate user-space has a truly private address space and not simply a chunk out of the entire virtual address space. Even for operating systems that partition the virtual address space into regions for each user process, the local descriptor (or equivalent) table for segment access needs to be reloaded. This has to happen for every cross-privilege-level call. It is *much* faster to simply call another kernel mode function (push some stuff on the stack, change the instruction register, and you're done) without messing with caches.
In fact, it would be even faster to not separate the kernel and user space processes at all, and instead use formal verification or a virtual machine (which really just means a smaller instruction set that's easier to verify) to prove that no user process could ever mess with the kernel or other processes. Virtual machines for languages are essentially at this stage today; they implement what would constitute a kernel as the run-time level portions of the virtual machine, running the virtualized software in the same address space. There have been some attacks based on virtual machine weaknesses or memory corruption that break the protection model by changing data structures so that they violate the security model. This can happen in OS's that use hardware protection as well, there are just fewer places in memory that random changes can cause problems (just the page tables and other security paraphernalia), making it less likely.
Prenatal tests (amniocentesis), test tube babies, and sperm and egg banks already provide more than enough genetic material to radically change the gene pool. Once we allow commonplace genetic engineering of human offspring, evolution will occur rapidly. Don't assume that human whims not under the control of natural selection; the difference is that the genes that survive will serve humanity more than themselves, since humans can now impose their own fitness functions. All it will do is speed up evolution with a new set of pressures, and with luck let us avoid a little bit of our own genes' selfishness along the way. Hopefully our new basic elements of natural selection will be human comfort and enjoyment and not merely allele frequencies.
CNN has had three articles written by Ron Paul about the tanking economy and election in the last month. Two that I know of were linked from the front page. Barely a peep about him when he was running for President.
Computers can get smarter, or the human interrogators can get stupider. If you stuck most of these chatterbots on AOL/Myspace/Youtube they'd be the most articulate conversationalists around.
3. Computer programs protected by dongles that prevent access due to malfunction or damage and which are obsolete. A dongle shall be considered obsolete if it is no longer manufactured or if a replacement or repair is no longer reasonably available in the commercial marketplace.
This is so similar to the case of DRM'd music tracks where the DRM servers have been turned off that it would probably be easy to get an exception for decrypting those tracks. Interestingly, there isn't a known way to do that once those DRM servers are completely unavailable, as far as I know. Isn't the whole point that the media is encrypted with some key, and the DRM server provides the key each time the user wants to play it? That means there is no legal way to store that decryption key BEFORE the DRM server goes belly up, and no way to get the key afterward.
What really needs to get added as an exception is an unconditional fair use exception to allow any person to create at least 1 permanent backup copy in a format of their choice (important) for backup in the event of data loss of any DMCA protected media on a storage device that they own. Data loss should cover not only scratching a DVD but also losing your DRM server permanently. The problem really boils down to ownership, of what, and by whom. When I "buy" a DVD, I expect that I will "own" the physical media and be able to watch the movie on it forever. Not until some company decides to stop making DVD players (it'll happen eventually), or the physical medium gets scratched. The implication of owning a copy of a work is that, with appropriate care, it has an indefinite lifespan. Since it's so bleeding obvious that computers are good at making redundant copies for backup purposes, it's insane to pretend that the works on physical mediums shouldn't have redundant backups. After all, there's already partial redundant backups on the DVD in the form of reed solomon codes, so why not just another copy on a hard disk somewhere? Information theory should drive policy in the information age, not the other way around.
Since the encryption is done at the block device layer, it shouldn't be part of the file system but rather a part of the encryption layer. Except from that detail, I agree with you. However doing it is tricky. When you take a logical sector with 512 bytes of data and put it together with a small IV, it no longer fits in a 512 bytes sector. So you have to come up with a layout on disk that is efficient. And then you have the problem of updating it. Because you cannot write two sectors to disk atomically (with some disks you can't even write one). So you end up having the potential of data loss if an update does not complete because of a power failure. And the data loss is not guaranteed to affect only the logical sector you were writing at the time. I am still thinking about the problem. A raid layer have some similar problems, and I have been considering whether merging those two layers would help solving this problem. A can see a few other advantages you could get from merging a raid layer with an encryption layer.
Basically the IV's themselves would require a journal. To make the file system trusted as well as private, an HMAC for each block should be stored next to its IV, and this helps significantly with a journalling scheme. Reserve enough of the first sectors of the underlying device to store an IV and HMAC for each block, and some more sectors for the journal. I don't have much experience with actual file system journalling, but it seems to be like the simplest scheme is a full block for a header (so that it's an entire sector) with the block number, an HMAC of the journaled IV+HMAC block, and then followed by a complete IV+HMAC block in the next adjacent block. The best part of the scheme is that it's readily apparent whether a given journal block should be applied to the IV+HMAC sectors; just compare every block that the IV+HMAC is for and see if it properly decrypts and validates the block. If it does, write it to the main IV+HMAC location. If not, compare the original IV+HMAC for those blocks and merge them together to recover as much data as possible, write this new block to the journal, and then into the main IV+HMAC area.
Basically, if a device is composed of N blocks of size B, and you're using I-byte IVs and H-byte HMACS, you need N*(B/(I+H)) blocks for the IV+HMAC area at the start of the disk, and the individual IV+HMAC for a block C is stored at byte offset C*(I+H) in that area. Pretty simple mapping, and the journal would just store whole blocks from that area when an update needed to be made. The journaled block would be written first, and then the encrypted block, and finally an update to the main IV+HMAC storage area. That would ensure the most recoverable possibility in the case of data loss at any point. Obviously a write to an encrypted block that fails half way through is completely lost, but that's a problem for the file system at a higher layer to deal with, since that happens with physical devices as well. The journal could just be a simple FIFO written in ascending order and then repeating from the beginning while ensuring that any additions to the journal are actually flushed to the main IV+HMAC area at some point before it's overwritten. The entire journal would be examined every time the file system was mounted to see if anything needed to be replayed or recovered. Since disks don't always order writes properly, it would be good to always check both the normal location for an IV+HMAC as well as what's in the journal for any given block, because the journal may actually be more stale than the normal location.
I've been working on developing a file system based on hash trees as well, which is a pretty similar concept and could support encryption pretty cheaply as an addition of IVs to the entries in the hash tree. There's some advantages to having a disk layout like I described for storing the hash tree, because storing indexes to block locations is not necessary if the hash for any given block is always at a given offset on the disk, with a jour
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.
LRW should fall to the bitmap attack presented in the article, so long as the bitmap is overwritten in place between ciphertexts. Any other weakness in LRW using the same key is minimized unless you are filling your disk with 127th degree polynomials in GF(2) represented as 128-bit vectors, that happen to differ from each other by n*k in GF(2) where n is the sector number they're stored in and k is the LRW tweak key. Most people don't do that. The probability of doing so with normal use is roughly the probability of accidentally guessing the tweak key.
The only real solution for the bitmap problem is modification of the file system to contain secure IVs for each block on the disk. Reusing IVs has *always* been shown to be a bad idea. It's broken more thought-to-be-secure schemes than I can count.
As an aside, once I actually found two files from a Slackware distribution that were detectable inside a truecrypt volume. One problem truecrypt had back then was that they were using 512 byte CBC blocks, while most file systems used larger blocks, so it was trivial to insert a file that would guarantee that the resulting ciphertext would be vulnerable to detection by starting at an even sector boundary and having just simple bit differences. I am guessing that in both cases the files being detected were executables with a large dynamic link section, since that would contain a whole lot of simple offsets that could match up with the sector IV vulnerability.
Multiply however many hours you worked on the project beforehand by $300 or $500 an hour, whatever you think a contractor would charge. Make them pay that up front, since you'll never see the benefit of that labor again if you take the job. That might sweeten the deal for you.
You'll have to decide on your own whether abandoning a hobby you like is worth a lot of money.
Eventually, computers will pass any captcha we can create and thereby pass the turing test. Then we can just put them to work filtering spam for us.
Mental poker is the general name for cryptographic protocols that can be used to securely play games of chance and hidden information with no possibility of cheating because of a single trusted server. Obviously collusion between legitimate players in the game can still occur, but I can't believe that anyone would even consider playing online poker (read: giving lots and lots of money to some guy online who promises that he won't steal it) without some sort of assurance that the underlying software wasn't as fair as an actual table with physical cards.
Kicked out from Afghanistan by the US and its allies, Osama could very well have patched up his differences with Saddam, and begin a mutually-useful cooperation.
Saddam hated Osama as much as he hated the Kurds. Osama had as much chance of walking into downtown New York and asking for asylum.
The existence of piracy does not magically give me an extra $200 a year that I could have spent on music or movies. I have the same amount of money I did last year (or less, with the wild inflation), so the MAFIAA would get roughly the same amount of money from me whether or not I could pirate things.
Via piracy I can never view every single movie ever made, or every song ever produced, which means that if I happen to see a few movies this year that I couldn't have afforded otherwise, it will *not* cut into the amount of money I'll spend next year on music and movies.
(you may find the following useful)
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses:
For encryption, PGP keyservers need to support email address lookup, but for signing it should be sufficient to work with the key IDs (hashes) instead. Looking up certificates or PGP public keys by their hash from public key servers turns email address harvesting into a brute force problem for spammers.
() Mailing lists and other legitimate email uses would be affected.
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
PGP and X.509 certs are secure against cryptographic attacks.
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
If people can deal with a green/red bar for their SSL connections, they could deal with color coding for email addresses.
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
Almost. It would require cooperation from at least all the major web mail vendors at once.
( ) Many email users cannot afford to lose business or alienate potential employers
They can still benefit from signed messages while doing traditional spam filtering for unsigned messages. If they sign their own messages, they will contribute to the solution.
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
It would be difficult to get enough people to revoke trust in an individual to make a difference, since those revocations would be publicly visible and make retaliation revocation possible.
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
Partially, although RFCs are the de-facto controlling authority for email, and S/MIME and PGP are already established standards. Simply using them would require some motivation.
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
It would make getting rooted much more damaging to individuals who had their email identity stolen for spamming. CRLs would fix that address, but make it a pain for individual users. That, hopefully, would be good selection pressure for secure PCs.
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
Trojans stealing private keys could make more convincing identity theft. That's a local security problem, not a spam problem.
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
Obviously the idea has been around for a while. Sometimes it just takes a long time for good ideas to adopted.
The PGP web of trust or a hierarchical PKI solves the spam problem. People will revoke their trust in a key used for spamming, and be much less likely to trust a key from the same person again, and Verisign and other companies will stop issuing certificates to entities that send spam.
Obviously some spam will be generated because it's always necessary for new people to enter the trust network, but ultimately there will form a core group of trust or certificates that never send any spam because they're trusted by people who don't like spam. Getting into that group will require the trust of enough other trusted people as to make spam almost nonexistent.
The problem with the idea is getting enough people into the trusted group to make it effective at both preventing spam and incorporating new legitimate users into the trust group quickly and effectively so they can communicate.
As a libertarian I am reluctantly forced to concede that it can be acceptable to sell ones and zeroes, and to forbid the buyer, as a condition of that sale, from redistributing those ones and zeroes without the seller's permission. This is acceptable because all things that are not forbidden are allowed, no matter how repugnant we might find them, and the only things that are forbidden are those which violate people's rights (namely, initiation of force and/or fraud).
So this is a little off topic, but do human rights really include the right to give up the fundamental right of free speech? If so, then why not give up the right to liberty and allow slavery as well? Or the right to life, and allow people to sign up for soylent green distribution? Because human rights are inalienable, I have trouble with laws that prevent the truth from being known by certain individuals. It is absolutely true that if you take an MPEG2 stream from a DVD and follow a specific series of mathematical operations on the bits, you can display a series of images as a motion picture. I also think it's an affront to the inalienable right of liberty to restrict anyone from performing those same mathematical steps. Copyrights and patents are a form of ownership of people's minds and bodies by hindering their actions beyond what is necessary to respect other people's natural rights; in essence, slavery.
I have no problem with people keeping secrets, but secret algorithms can't be useful for things like distributing compressed media, nor can public algorithms with secrets "hidden" in the media.
Spam?
Try getting a video card with DVI or HDMI out that connects to your TV. It's much easier to manage a movie library with a big hard disk instead of a shelf of DVDs.
I've bought 5 or 6 DVD players over the years that have subsequently broken. Since I don't get a refund for the perfectly good mathematics that the patent on MPEG2 covers when that player breaks, I feel completely morally justified in continuing to use mplayer to watch DVDs.
<Voice>Quiet, you! Now go read all 6 books.</Voice>
Yeah, but unlike traditional old time nations (China, India, etc.) they weren't able to actually occupy and control their own country for any great length of time. I'd think shared ownership and governance with any number of other people whose ancestors have occupied Israel over the centuries would be a bit more fair.
To me, it sounds a lot like giving the U.S. back to native Americans, or giving Australia back to the Aboriginals. Impractical and sure to make a lot of people angry. It's not like genocide wasn't committed against those original occupants either. "Reservations" would be more like giving Israel the Gaza Strip and leaving everything else for the Palestinians.