I used to have a Toshiba DVD drive that I spent quite a while playing with regions on (More than 2 years ago now.) There was no hacked firmware for it. Then I got VLC, and *poof*, it just worked. Now I have a different laptop and I use VLC, mplayer, and xine with material in different regions. No problem and no firmware changes.
Re:DVD Firmware upgrade?
on
High Density CDs
·
· Score: 2, Informative
You don't need to play with firmware to be able to ignore regions. Just use a DVD player that forgets to ask the drive for the keys, and instead guesses them itself. All Linux players are like that, and I would presume you can find some for Windows too. A DVD drive will let you read the files off any region discs, but they will only give you the keys to decrypt one region.
I understand what you are saying, you just happen to be wrong. I have repeatedly pointed out why you are wrong. And I already have read enough good books on cryptography.
If f can be attacked by applying g, like in the previous example, then an adversary can attack it by applying g. In your example, providing the output of f or the output of h to the adversary makes no difference; the adversary breaks both cases.
Your example is also flawed because you are using a fixed key and reusing the same key for f and g. Systems with fixed keys are uninteresting since it is usually assumed that the attacker has access to the encryption algorithm but not to the key. Therefore fixed-key systems are all trivially breakable.
You can look at "f encrypted with g" as a new algorithm "h" which is possibly weaker than f or g alone.
h can be weaker than g, but never weaker than f (assuming independent keys).
Assume h is weaker than f. Then f can be attacked by the adversary applying g to f, producing h. Therefore it clearly does not matter whether the output of f or the output of h is provided to the adversary, and therefore h is not weaker than f. Contradiction.
The same does not apply to g, h may very well be weaker than g.
Even when using multiple different algorithms there is a chance of weaking the whole thing. Depends on which algorithms you're using and how you're using them.
Assume that you have a message, M. You encrypt with with algorithm f using key kf into M'. Then you encrypt it with algorithm g using key kg into M''. If an adversary is able to decrypt M', he may or may not be able to decrypt M''. Let us look at the possibilities for the adversary:
The adversary can decrypt every message encrypted with f: In this case encrypting it with g too can only increase security, since security is entirely broken.
The adversary can decrypt every message encrypted with g. This leaves the adversary with M'. If encrypting with g somehow helped break f, the adversary could just use that as a strategy for decrypting f (if someone sends a message encrypted with g, the adversary encrypts it with g and breaks the result.) Therefore we are again no worse off than with just f.
The adversary can decrypt messages encrypted with g, but only if the messages are produced by encrypting something with f. In this case we are just as badly off as with just plain f, whereas it would have been better to forget about f and use g. Still, no worse than just f.
This shows that if you use encryption within encryption you should use what you believe to be strongest at first. Hopefully a really strong f does not leave patterns that can be used to attack g. It is also important that the keys for f and g are entirely independent; the reason should be obvious. Whether it is worth it to add g is debatable, but it cannot hurt security.
The looting continued for days. It was even broadcast live from the museum at the end.
Nothing was looted from the Oil Ministry. But then again, that contained valuable electronic maps of the Iraqi underground instead of 4000 year old baubles.
Fscking hard drives is so last millenium. Journaling filesystems have taken over. Filesystems don't get borked either, unless you hit a hardware problem. In which case you just reinstall / and keep your user directories that are on the other partition/drive/logical volume. What does a full RedHat reinstall take on a modern machine, half an hour perhaps?
Having a gazillion volumes is annoying even when LVM is in use, and without LVM it is a world of pain.
There is an EU directive forcing all EU members to implement some kind of levy (notice that this is/not/ a tax; taxes go to the government). So far Germany has chosen to keep theirs very low, so that is where I get my CD-R's. It is legal to import CD-R's for personal use to other member countries without paying any extra tax; EU guarantees the free movement of goods within Fortress Europa. There are many webbased shops in Germany that will gladly send all over the EU.
As long as just one member country maintains a low levy, it will be possible to get cheap CD-R's. If all of them raise the levy, we are screwed. It is highly likely that a similar levy will be introduced on hard drives and printers. DVD-R's are a sure target, there/will/ be a levy on them if there is not already one.
And on a similar note, I definitly agree with the authors idea of changing default directory names to be more user friendly (it wasn't up until 2 years ago that I found out that/usr didn't mean USER but rather Unix System Resources. WTF?)
Unix System Resources is a backronym. Back in the good old days, binaries lived in/bin, sysadmin-only binaries in/sbin, libraries in/lib, changing stuff in/var, and the rest (mostly configuration files) in/etc. The users, of course, went in/usr.
Eventually Unix grew, and it became hard to fit both Unix and all applications on a single drive (this was way before Logical Volume Management and all that stuff). People started storing programs in their home directories. Eventually some sysadmin decided to make a bin user to hold all these programs; the home directory being/usr/bin of course. This useless bin user can be found on many systems even today./usr/lib and so on followed naturally. The neat thing about this was that on advanced systems with network filesystems, just sharing/usr suddenly also gave access to the programs in/usr/bin.
After a while it became obvious that having real home directories sitting among the proliferating system directories in/usr was quite a bit messy. So sysadmins started moving the users elsewhere. Some picked/home, some picked/users, some picked other places. Of course the name/usr stopped making sense at that point. It seems the ever-logical people at SCO could not stand such a discrepancy; the first sightings of "Unix System Resources" appear to be in SCO manuals. (I prefer to blame SCO anyway; and the history is hazy enough that noone has managed to refute me so far.)
These days with multigigabyte disks, we really should go back to the root and ditch/usr. It serves no useful purpose. Moving the home directories back where they belong is probably not going to happen, but I can wish.
You want to move a file in the real work.. you grab it and put it in another folder. You dont say "move this file to there".
You are just not used to having servants doing the work for you. Why should I bother with having to drag files around, when I can just tell someone else to do it? "Move this file to here" seems entirely intuitive to me.
Web sites can try to detect spiders. Spiders can try to hide that they are spiders. This leads to an arms race. Robots.txt was an attempt at a social contract: Spiders would not be stopped by the web site, as long as the spiders upheld their end of the contract.
If it becomes commonplace that spiders break the social contract, then web sites will have to get better weapons. This means development time spent on something that ultimately benefits noone. Some of the measures that could be used would in fact harm innocent bystanders. Take the 2-second delay as an example. Now implement it on a big web site, and imagine what happens when a big proxy tries to access several times a second. Perhaps you just cut yourself off from AOL. So more wasted development time to fix that problem...
At the same time the legitimate spiders that upheld the social contract before may have to try to masquerade as normal users. Where do we end up? "In order to access this site, type the letters that appear in the picture below."
Plants do, in fact, react to harm in much the same way animals do. The levels of various chemicals is increased. If they are repeatedly harmed, so those chemical levels are kept high, they start to express stress symptoms.
Compressing to hard drive takes substantial CPU horsepower. Even a fast processor cannot compress and write to a drive at line rate. With enterprise tape drives, the compression is built into the drive.
Crappy compression, such as that done on tape drives with only a 2:1 average can easily be done at line rate on a decent processor. Which is why it can be done on the tape drive at all. There have even been people trying to get a performance improvement from compressed swap, but the primary cost of swapping is the seek time, and compression does not help significantly there.
Anyway, if you are using a $4000 processor it may well be cheaper to move as many cycles elsewhere as possible in order to avoid having to by more of those $4000 processors. With x86-based servers CPU cycles are dirt cheap.
Mirroring is not backup. If you want to do backup with disks, treat them like tape. Tar up the files, put them on the disks. Reuse disks over time, just like tapes. For backup, the only difference between a disk and a tape is that with a disk it can be really fast to skip to a specific file or archive.
The perfect solution to backups would be notebook SATA disks, which should hopefully appear soon. Hotpluggable, no bulkier than an LTO or DLT tape, screaming fast compared to LTO and DLT, and very hard to damage when powered down. Capacities are about the same. Unlike tapes, I can rescue data off of a disk without needing an expensive and fragile drive.
"Therefore a wise prince will seek means by which his subjects will always and in every possible condition of things have need of his government, and then they will always be faithful to him."
--Niccolo Machiavelli, The Prince
A strong government is obviously necessary to fight terrorism.
Yeah, so really, there are OS's that can not only address, but use (and efficiently too!) that much memory...
You are comparing Solaris on a 64-bit CPU to Linux on a 32-bit CPU. Handling large memory on 32-bit is difficult. Linus Torvalds once stated that Linux would never support more than 4GB on x86 - I believe he said something to the effect of "Buy an Alpha". 64-bit architectures have been slow in becoming mainstream, so concessions had to be made.
If you want 64GB in Linux, just run it on a 64-bit architecture. Get an IA64-box, or use that old E10k...
Re:The legacy part that bothers me...
on
Legacy-Free PCs
·
· Score: 1
On x86-CPUs with builtin floating point Linux uses a math exception instead of the IRQ. Try cat/proc/interrupts, and you will notice the absence of IRQ 13.
It also tells the world what type of system you're running (router, Mac, x86 box, SPARC, etc)
Right, I browse the WWW from my router all the time. Sun has a MAC range, but the addresses are easily changeable. Whether Apple has one or uses it I do not know, but plug any random PCI ethernet NIC into it, and suddenly your Mac becomes a PC.
It hands out the MAC to anyone on the Internet, which can be nice for MAC-related attacks if a hacker can compromise a nearby system...
If the hacker can compromise a nearby system, he can just hang around on it until he sees an arp request fly by. Or, with IPv4, simply scan whatever pitiful subnet the two machines are on.
As a non-privacy-related but nasty issue, my IP changes if my Ethernet card breaks and I get a new one. People running a server will love that (and "IP numbers unassociated with MACs" become a premium item to sell to business accounts).
Finally, I can *get* a new IP number if I want one today. If my ISP has a policy (and has routers that depend on) my IP ending in my MAC, I'm stuck with it.
You seem to be holding on to this notion of "my IP". "My IP" only applies to end user devices, like when you bring your laptop to work and it gets an IPv6 address. Whenever you are actually connecting to an ISP and not just borrowing someones network, you get your very own/48. If you prefer to allocate addresses the RFC 2322 way, feel free.
You can't do that on any card that I'm familiar with, though I'm sure there are some that you can finagle into pulling that off on. The Linux approach of "changing the MAC" just kicks the card into promisc mode and then does software filtering when listening for frames with the right MAC. It wastes CPU time.
I have no idea what makes you think that Linux cannot do hardware filtering of MACs for software assigned addresses. A reference for that claim would be nice. Not that hardware filtering makes any sense these days - when did your NIC last receive a packet that was not addressed to you or a broadcast packet?
Anyway, many drivers for Windows allow you to change the MAC address. If yours does not, try this
Slashdot Mirror
tune2fs -c 0 -i 0 /dev/whatever. RedHat does that automatically when you install.
RedHat has up2date. It will even let you push updates to all the company computers, if you set them up for that. It costs money though.
I used to have a Toshiba DVD drive that I spent quite a while playing with regions on (More than 2 years ago now.) There was no hacked firmware for it. Then I got VLC, and *poof*, it just worked. Now I have a different laptop and I use VLC, mplayer, and xine with material in different regions. No problem and no firmware changes.
You don't need to play with firmware to be able to ignore regions. Just use a DVD player that forgets to ask the drive for the keys, and instead guesses them itself. All Linux players are like that, and I would presume you can find some for Windows too. A DVD drive will let you read the files off any region discs, but they will only give you the keys to decrypt one region.
I understand what you are saying, you just happen to be wrong. I have repeatedly pointed out why you are wrong. And I already have read enough good books on cryptography.
Your example is also flawed because you are using a fixed key and reusing the same key for f and g. Systems with fixed keys are uninteresting since it is usually assumed that the attacker has access to the encryption algorithm but not to the key. Therefore fixed-key systems are all trivially breakable.
h can be weaker than g, but never weaker than f (assuming independent keys).
Assume h is weaker than f. Then f can be attacked by the adversary applying g to f, producing h. Therefore it clearly does not matter whether the output of f or the output of h is provided to the adversary, and therefore h is not weaker than f. Contradiction.
The same does not apply to g, h may very well be weaker than g.
Assume that you have a message, M. You encrypt with with algorithm f using key kf into M'. Then you encrypt it with algorithm g using key kg into M''. If an adversary is able to decrypt M', he may or may not be able to decrypt M''. Let us look at the possibilities for the adversary:
- The adversary can decrypt every message encrypted with f: In this case encrypting it with g too can only increase security, since security is entirely broken.
- The adversary can decrypt every message encrypted with g. This leaves the adversary with M'. If encrypting with g somehow helped break f, the adversary could just use that as a strategy for decrypting f (if someone sends a message encrypted with g, the adversary encrypts it with g and breaks the result.) Therefore we are again no worse off than with just f.
- The adversary can decrypt messages encrypted with g, but only if the messages are produced by encrypting something with f. In this case we are just as badly off as with just plain f, whereas it would have been better to forget about f and use g. Still, no worse than just f.
This shows that if you use encryption within encryption you should use what you believe to be strongest at first. Hopefully a really strong f does not leave patterns that can be used to attack g. It is also important that the keys for f and g are entirely independent; the reason should be obvious. Whether it is worth it to add g is debatable, but it cannot hurt security.Nothing was looted from the Oil Ministry. But then again, that contained valuable electronic maps of the Iraqi underground instead of 4000 year old baubles.
Having a gazillion volumes is annoying even when LVM is in use, and without LVM it is a world of pain.
As long as just one member country maintains a low levy, it will be possible to get cheap CD-R's. If all of them raise the levy, we are screwed. It is highly likely that a similar levy will be introduced on hard drives and printers. DVD-R's are a sure target, there /will/ be a levy on them if there is not already one.
Unix System Resources is a backronym. Back in the good old days, binaries lived in /bin, sysadmin-only binaries in /sbin, libraries in /lib, changing stuff in /var, and the rest (mostly configuration files) in /etc. The users, of course, went in /usr.
Eventually Unix grew, and it became hard to fit both Unix and all applications on a single drive (this was way before Logical Volume Management and all that stuff). People started storing programs in their home directories. Eventually some sysadmin decided to make a bin user to hold all these programs; the home directory being /usr/bin of course. This useless bin user can be found on many systems even today. /usr/lib and so on followed naturally. The neat thing about this was that on advanced systems with network filesystems, just sharing /usr suddenly also gave access to the programs in /usr/bin.
After a while it became obvious that having real home directories sitting among the proliferating system directories in /usr was quite a bit messy. So sysadmins started moving the users elsewhere. Some picked /home, some picked /users, some picked other places. Of course the name /usr stopped making sense at that point. It seems the ever-logical people at SCO could not stand such a discrepancy; the first sightings of "Unix System Resources" appear to be in SCO manuals. (I prefer to blame SCO anyway; and the history is hazy enough that noone has managed to refute me so far.)
These days with multigigabyte disks, we really should go back to the root and ditch /usr. It serves no useful purpose. Moving the home directories back where they belong is probably not going to happen, but I can wish.
Go learn about thermodynamics.
You are just not used to having servants doing the work for you. Why should I bother with having to drag files around, when I can just tell someone else to do it? "Move this file to here" seems entirely intuitive to me.
If it becomes commonplace that spiders break the social contract, then web sites will have to get better weapons. This means development time spent on something that ultimately benefits noone. Some of the measures that could be used would in fact harm innocent bystanders. Take the 2-second delay as an example. Now implement it on a big web site, and imagine what happens when a big proxy tries to access several times a second. Perhaps you just cut yourself off from AOL. So more wasted development time to fix that problem...
At the same time the legitimate spiders that upheld the social contract before may have to try to masquerade as normal users. Where do we end up? "In order to access this site, type the letters that appear in the picture below."
Plants do, in fact, react to harm in much the same way animals do. The levels of various chemicals is increased. If they are repeatedly harmed, so those chemical levels are kept high, they start to express stress symptoms.
Crappy compression, such as that done on tape drives with only a 2:1 average can easily be done at line rate on a decent processor. Which is why it can be done on the tape drive at all. There have even been people trying to get a performance improvement from compressed swap, but the primary cost of swapping is the seek time, and compression does not help significantly there.
Anyway, if you are using a $4000 processor it may well be cheaper to move as many cycles elsewhere as possible in order to avoid having to by more of those $4000 processors. With x86-based servers CPU cycles are dirt cheap.
The perfect solution to backups would be notebook SATA disks, which should hopefully appear soon. Hotpluggable, no bulkier than an LTO or DLT tape, screaming fast compared to LTO and DLT, and very hard to damage when powered down. Capacities are about the same. Unlike tapes, I can rescue data off of a disk without needing an expensive and fragile drive.
The subject of this article is not within walking distance for me, no matter how much time I have.
1 microsecond (assuming US billions).
--Niccolo Machiavelli, The Prince
A strong government is obviously necessary to fight terrorism.
You are comparing Solaris on a 64-bit CPU to Linux on a 32-bit CPU. Handling large memory on 32-bit is difficult. Linus Torvalds once stated that Linux would never support more than 4GB on x86 - I believe he said something to the effect of "Buy an Alpha". 64-bit architectures have been slow in becoming mainstream, so concessions had to be made.
If you want 64GB in Linux, just run it on a 64-bit architecture. Get an IA64-box, or use that old E10k...
An unused line is infinitely fast
On x86-CPUs with builtin floating point Linux uses a math exception instead of the IRQ. Try cat /proc/interrupts, and you will notice the absence of IRQ 13.
Right, I browse the WWW from my router all the time. Sun has a MAC range, but the addresses are easily changeable. Whether Apple has one or uses it I do not know, but plug any random PCI ethernet NIC into it, and suddenly your Mac becomes a PC.
It hands out the MAC to anyone on the Internet, which can be nice for MAC-related attacks if a hacker can compromise a nearby system...
If the hacker can compromise a nearby system, he can just hang around on it until he sees an arp request fly by. Or, with IPv4, simply scan whatever pitiful subnet the two machines are on.
As a non-privacy-related but nasty issue, my IP changes if my Ethernet card breaks and I get a new one. People running a server will love that (and "IP numbers unassociated with MACs" become a premium item to sell to business accounts).
Finally, I can *get* a new IP number if I want one today. If my ISP has a policy (and has routers that depend on) my IP ending in my MAC, I'm stuck with it.
You seem to be holding on to this notion of "my IP". "My IP" only applies to end user devices, like when you bring your laptop to work and it gets an IPv6 address. Whenever you are actually connecting to an ISP and not just borrowing someones network, you get your very own /48. If you prefer to allocate addresses the RFC 2322 way, feel free.
You can't do that on any card that I'm familiar with, though I'm sure there are some that you can finagle into pulling that off on. The Linux approach of "changing the MAC" just kicks the card into promisc mode and then does software filtering when listening for frames with the right MAC. It wastes CPU time.
I have no idea what makes you think that Linux cannot do hardware filtering of MACs for software assigned addresses. A reference for that claim would be nice. Not that hardware filtering makes any sense these days - when did your NIC last receive a packet that was not addressed to you or a broadcast packet?
Anyway, many drivers for Windows allow you to change the MAC address. If yours does not, try this