Reveal the secret key to this obviously encrypted file, or face contempt of court and an automatic prison sentence.
You can encrypt two (or more generally N) messages with different keys into the same encrypted file. If confronted with the above ultimatum, reveal just one key and keep the very important information secret just as before.
Of course, many messages encrypted into the same file would draw suspition from cryptanalysts, but those experts are in rare supply and regular police would generally stop bothering you if they can see one mildly incriminating decrypted message (surely, it has to be a a nice bait).
Steganography comes into play if you want to hide the secondary secret messages in the multi-message encrypted file...
Wrong. There are no ISO documents specifiying a "Windows" standard. It is not even a de-facto standard, as there are no RFC, POSIX, whatever open recommendations specifying its interfaces. Windows is just a widely used OS, with proprietary interfaces, sold by a unique company. This hardly qualifies it as a worldwide standard.
How many simultaneous different TCP connections could a Linux or *BSD host keep open? There's a certain amount of state per connection involved. How much will that be? Would a few gigs of RAM and a big swap space be enough?
If a host should keep, say, 100 tcp connections from every host in the IP address space open simultaneously, how big would the required resources be?
It's actually amazing. We're living in democracies, and have the right to kill the best initiative our governments are about to take w.r.t. the space program. Meanwhile dictatorial China is stepping forward and is on its best way of becoming the leading nation in this area.
Heck, we're even dependant upon the russians to keep contact with the ISS! Meanwhile, at home, the political bickering happily goes on and on. What a shame!
But when the police or employers can do it as a matter of course, then it fundamentally changes the kind of society we have.
That's true. As soon as it becomes socially acceptable to be tracked, anyone who refuses to be, automatically becomes suspicious. This is a similar argument to encryption used by PGP activists a while ago: if everyone used encryption, that would be fine. If only a few used it, then they must have something to hide...
It won't be long before people without cellphones, or those who don't always carry them along, will show up on Ashcroft's radar.
The MAC address goes no further than the first router
Yes, but the AOL closed-source client application could get this MAC address from the OS, and transmit it to AOL's servers (covert channel). After all, we don't know what this AOL client does.
Attacking Google is like attacking the Press. It is always a mistake. But Google is more powerful than the Press (at least as long as they are the favorite search engine)! Their results are considered authoritative by most casual surfers, and CEOs, investors and the Press surf the web too.
Linux likes to have hard disks but again, you run a loop device if you want.
With a little help from BIOS, Flash can emulate a harddisk. There's nothing that would prevent linux from, say, mounting flash read-only on/usr, and mount modifiable stuff on a RAM-disk. Or am I completely wrong here?
That's an excellent idea! A system with a multi-purpose BIOS, a Flash "disk" for the OS (you could choose Linux, BSD, or even *yuck* Windows), and plenty of memory for a scratch RAM disk. Et voila, a self-sufficient, diskless system, that can be upgraded anytime you want, by simply reinstalling your favorite OS on the Flash disk!
Is it possible to put a complete OS like Linux, BSD, Windows, etc... in the BIOS? Or, more precisely, in Flash RAM?
Many PCs are mostly ran as single-purpose OS, e.g. as firewalls, file servers, etc. Sometimes, hard disks aren't even necessary.
A typical setup would involve a BIOS which boots any OS from Flash RAM, and uses that 1GB+ DRAM to hold both a RAM disk and run normal processes.
Such a system would be energy efficient, would have much higher MTBF, and would be much more stable against tampering. Modifications to Flash memory would only be possible through the BIOS in a controlled manner and it would be always possible to reboot the machine to its previous stage.
It would be somewhat like Cisco routers: A very small Firmware ROM, and plenty of Flash RAM space for OS images that could be downloaded per TFTP/whatever. The only difference is in size: Flash would need to be MUCH bigger to accomodate even moderate OS partitions.
This kind of BIOS would be most welcome, not that DRM-crippled crap that Phoenix seems to be pushing now.
There's already rudimentary IP support in many NICs that can boot off the network.
That's a good point! A DHCP client is very useful in this situation. And since NICs are now most often part of the motherboard, it is increasingly difficult to add a boot EEPROM to them. DHCP at BIOS level is here a Good Thing(tm).
But do you need more than this bootstrapping capability, which could be easily provided by a OS image? Mounting remote disks involves at least NFS and SMB shares, and you need a basic root filesystem as well. This looks very OS-dependant. More importantly, it's error prone. We can expect bug reports on bugtrag soon...
The vision of an open and modular, OS-less system, is still very interesting. But what happens is simply that parts of the OS(es) is being burnt into firmware, and can't be changed or fixed easily later. Is that worth it? Perhaps, perhaps not. As long as the customer is able to configure things both ways, that would be okay.
TCP/IP in the BIOS is a most silly idea. Unless you can easily update this BIOS every now and then to include the latest bug-fixes...
A TCP/IP stack is also quite memory intensive application (not only ROM, but also RAM). A TCP/IP in the BIOS may probably be suitable to small desktop systems, but you'll have to buy extra expensive "Enterprise-Level" updates to support thousands of connections on production servers.
Ah, you want firewall rules? pf? Let's hope it's in the BIOS. Oh, they "forgot" it? Your problem.
Oh yes, one more thing: I'd never use this
proprietary TCP/IP stack for anything security-related like building firewalls. Who knows how many backdoors Phoenix put in?!
will anyone stay 'rogue' and avoid DRM, or will everyone conform
Nobody is forced to buy Phoenix DRM-crippled BIOSes. There are plenty of manufacturers abroad (China, Taiwan, Eastern Europe, hell, even Old Europe!) that will be more than happy to sell you unencumbered BIOSes. Not everyone cowers before US laws and the DRM cartell (unless you come and invade those countries too).
It's not about trusting software, open sourced or not, it's about trusting the people who are actually doing the counting and certifying the results.
In most countries in the world, simple paper ballots, where you can put an X in a circle, work perfectly well. They are counted locally in every voting district, and the results are reported back up the hierarchy. Results are available 1-5 hours after closing time. Think of a distributed counting algorithm with human CPUs.
Some districts may experiment with eVoting too, but at the end of the day, it's still a commission of appointed/designated humans, who is responsible for everything. eVoting is just a tool, nothing more.
Obviously, if you don't trust the people organizing the vote (and counting), trusting a machine would be silly as well.
I'd contend that researchers & scientists in general would be quite silly to site an electronic-only resource in their publications,
It actually happens all the time. Most recent papers cite in their biography other papers with URL. As long as they cite correctly, and there is an alternative way to obtain those papers (such as printed journals), that's fine. Unfortunately, sometimes only URLs are published, some of them not active anymore.
The worst happens when you try to track down the author of a cited paper, and are not able to locate him/her. Universities used to maintain useable registries and good archives, but if you don't know where to start, your SOL.
There are plenty of programs out there that will capture your computer's audio output.
It would be cool to intercept audio, just before it is turned to analog, perhaps directly in or before the sound card/chips.
Anyone with average technical knowledge would know which input pins of a sound card/chip carry unencrypted digital audio, and could build a small hardware appliance which would intercept those digital signals. This device could then output mp3 or other formats, e.g. for use by a CD-R/DVD burner. Perhaps some companies in asia would sell those devices for the consumer market.
Invent a smart mouse-trap, and soon mice will outsmart you.
The EU anti-spam laws are tighter than the proposed US law, because it specifies opt-in, rather that opt-out. It's sad that the US didn't follow the Europeans here.
Agreed. Assume that an IDS system detects that a (lengthy) virus is just being transmitted. This IDS system could then notify the router to close the TCP connection, to prevent the virus from reaching in its entirety the victim host. The router would need a hook (SNMP?) to quickly close a connection, as long as it persists.
This wouldn't catch small virii, that fit in a single IP packet, but the vast majority of them are transmitted in TCP and are large enough anyway. An IDS would still have plenty of time to instruct the router to reset the connection.
OTOH, the router will not necessarily have to close the TCP connection itself. IDS could do this too, masquarading as the victim. There's no reason why the router should be bothered with this task, right? And it would be faster too.
To summarize: "Let routers route, servers serve, and [AV-]detection systems stop virus TCP streams dead on their tracks.
Yes, but unlike multiregion DVD players, which also ignore the region byte (somewhat illegally, but who cares anyway?), hosts will be free to decide wether they want to honor this bit or not. Consider this as a hint, a suggestion, not as a policy that is forced upon you. If you choose to ignore the hint, that's perfectly fine, and, most importantly, this bit wouldn't break backward compatibility in any way.
Slashdot Mirror
Reveal the secret key to this obviously encrypted file, or face contempt of court and an automatic prison sentence.
You can encrypt two (or more generally N) messages with different keys into the same encrypted file. If confronted with the above ultimatum, reveal just one key and keep the very important information secret just as before.
Of course, many messages encrypted into the same file would draw suspition from cryptanalysts, but those experts are in rare supply and regular police would generally stop bothering you if they can see one mildly incriminating decrypted message (surely, it has to be a a nice bait).
Steganography comes into play if you want to hide the secondary secret messages in the multi-message encrypted file...
Windows is a worldwide standard
Wrong. There are no ISO documents specifiying a "Windows" standard. It is not even a de-facto standard, as there are no RFC, POSIX, whatever open recommendations specifying its interfaces. Windows is just a widely used OS, with proprietary interfaces, sold by a unique company. This hardly qualifies it as a worldwide standard.
How many simultaneous different TCP connections could a Linux or *BSD host keep open? There's a certain amount of state per connection involved. How much will that be? Would a few gigs of RAM and a big swap space be enough?
If a host should keep, say, 100 tcp connections from every host in the IP address space open simultaneously, how big would the required resources be?
If it is feaseable, let's do it.
Watch out! More Bush-shit ahead!
It's actually amazing. We're living in democracies, and have the right to kill the best initiative our governments are about to take w.r.t. the space program. Meanwhile dictatorial China is stepping forward and is on its best way of becoming the leading nation in this area.
Heck, we're even dependant upon the russians to keep contact with the ISS! Meanwhile, at home, the political bickering happily goes on and on. What a shame!
Online books are not so exotic as you might think:
Unfortunately, free online computer books are still very rare, for obvious reasons.
But when the police or employers can do it as a matter of course, then it fundamentally changes the kind of society we have.
That's true. As soon as it becomes socially acceptable to be tracked, anyone who refuses to be, automatically becomes suspicious. This is a similar argument to encryption used by PGP activists a while ago: if everyone used encryption, that would be fine. If only a few used it, then they must have something to hide...
It won't be long before people without cellphones, or those who don't always carry them along, will show up on Ashcroft's radar.
General Protection Fault at 32FA:23CD. Airbag not deployed. Please contact Microsoft Support for assistance. Have nice death.
The MAC address goes no further than the first router
Yes, but the AOL closed-source client application could get this MAC address from the OS, and transmit it to AOL's servers (covert channel). After all, we don't know what this AOL client does.
but RSA keys isn't the way to go. They're impossible to remember, which means you need to store them on a computer.
They can also be stored on a smart card, memory stick, etc... Once all keyboards come with integrated card readers, the situation will improve a lot.
Google has many means of striking back:
Attacking Google is like attacking the Press. It is always a mistake. But Google is more powerful than the Press (at least as long as they are the favorite search engine)! Their results are considered authoritative by most casual surfers, and CEOs, investors and the Press surf the web too.
Port80 Software is dying.
Linux likes to have hard disks but again, you run a loop device if you want.
With a little help from BIOS, Flash can emulate a harddisk. There's nothing that would prevent linux from, say, mounting flash read-only on /usr, and mount modifiable stuff on a RAM-disk. Or am I completely wrong here?
That's an excellent idea! A system with a multi-purpose BIOS, a Flash "disk" for the OS (you could choose Linux, BSD, or even *yuck* Windows), and plenty of memory for a scratch RAM disk. Et voila, a self-sufficient, diskless system, that can be upgraded anytime you want, by simply reinstalling your favorite OS on the Flash disk!
Is it possible to put a complete OS like Linux, BSD, Windows, etc... in the BIOS? Or, more precisely, in Flash RAM?
Many PCs are mostly ran as single-purpose OS, e.g. as firewalls, file servers, etc. Sometimes, hard disks aren't even necessary.
A typical setup would involve a BIOS which boots any OS from Flash RAM, and uses that 1GB+ DRAM to hold both a RAM disk and run normal processes.
Such a system would be energy efficient, would have much higher MTBF, and would be much more stable against tampering. Modifications to Flash memory would only be possible through the BIOS in a controlled manner and it would be always possible to reboot the machine to its previous stage.
It would be somewhat like Cisco routers: A very small Firmware ROM, and plenty of Flash RAM space for OS images that could be downloaded per TFTP/whatever. The only difference is in size: Flash would need to be MUCH bigger to accomodate even moderate OS partitions.
This kind of BIOS would be most welcome, not that DRM-crippled crap that Phoenix seems to be pushing now.
There's already rudimentary IP support in many NICs that can boot off the network.
That's a good point! A DHCP client is very useful in this situation. And since NICs are now most often part of the motherboard, it is increasingly difficult to add a boot EEPROM to them. DHCP at BIOS level is here a Good Thing(tm).
But do you need more than this bootstrapping capability, which could be easily provided by a OS image? Mounting remote disks involves at least NFS and SMB shares, and you need a basic root filesystem as well. This looks very OS-dependant. More importantly, it's error prone. We can expect bug reports on bugtrag soon...
The vision of an open and modular, OS-less system, is still very interesting. But what happens is simply that parts of the OS(es) is being burnt into firmware, and can't be changed or fixed easily later. Is that worth it? Perhaps, perhaps not. As long as the customer is able to configure things both ways, that would be okay.
TCP/IP in the BIOS is a most silly idea. Unless you can easily update this BIOS every now and then to include the latest bug-fixes...
A TCP/IP stack is also quite memory intensive application (not only ROM, but also RAM). A TCP/IP in the BIOS may probably be suitable to small desktop systems, but you'll have to buy extra expensive "Enterprise-Level" updates to support thousands of connections on production servers.
Ah, you want firewall rules? pf? Let's hope it's in the BIOS. Oh, they "forgot" it? Your problem.
Oh yes, one more thing: I'd never use this proprietary TCP/IP stack for anything security-related like building firewalls. Who knows how many backdoors Phoenix put in?!
will anyone stay 'rogue' and avoid DRM, or will everyone conform
Nobody is forced to buy Phoenix DRM-crippled BIOSes. There are plenty of manufacturers abroad (China, Taiwan, Eastern Europe, hell, even Old Europe!) that will be more than happy to sell you unencumbered BIOSes. Not everyone cowers before US laws and the DRM cartell (unless you come and invade those countries too).
It's not about trusting software, open sourced or not, it's about trusting the people who are actually doing the counting and certifying the results.
In most countries in the world, simple paper ballots, where you can put an X in a circle, work perfectly well. They are counted locally in every voting district, and the results are reported back up the hierarchy. Results are available 1-5 hours after closing time. Think of a distributed counting algorithm with human CPUs.
Some districts may experiment with eVoting too, but at the end of the day, it's still a commission of appointed/designated humans, who is responsible for everything. eVoting is just a tool, nothing more.
Obviously, if you don't trust the people organizing the vote (and counting), trusting a machine would be silly as well.
Add this to the list of silly US laws. If only the world didn't follow blindly so fast...
In your-town-here, it is illegal to your-behavior-which-is-perfectly-legal-elsewhere.
I'd contend that researchers & scientists in general would be quite silly to site an electronic-only resource in their publications,
It actually happens all the time. Most recent papers cite in their biography other papers with URL. As long as they cite correctly, and there is an alternative way to obtain those papers (such as printed journals), that's fine. Unfortunately, sometimes only URLs are published, some of them not active anymore.
The worst happens when you try to track down the author of a cited paper, and are not able to locate him/her. Universities used to maintain useable registries and good archives, but if you don't know where to start, your SOL.
There are plenty of programs out there that will capture your computer's audio output.
It would be cool to intercept audio, just before it is turned to analog, perhaps directly in or before the sound card/chips.
Anyone with average technical knowledge would know which input pins of a sound card/chip carry unencrypted digital audio, and could build a small hardware appliance which would intercept those digital signals. This device could then output mp3 or other formats, e.g. for use by a CD-R/DVD burner. Perhaps some companies in asia would sell those devices for the consumer market.
Invent a smart mouse-trap, and soon mice will outsmart you.
The EU anti-spam laws are tighter than the proposed US law, because it specifies opt-in, rather that opt-out. It's sad that the US didn't follow the Europeans here.
(1.) U.S. Laws only reach as far as U.S. borders. Where does 95% of spam come from?
Most spam actually originates from the US! And most virulent spammers are also located in the US: just look at the rokso list for the top spammers.
Agreed. Assume that an IDS system detects that a (lengthy) virus is just being transmitted. This IDS system could then notify the router to close the TCP connection, to prevent the virus from reaching in its entirety the victim host. The router would need a hook (SNMP?) to quickly close a connection, as long as it persists.
This wouldn't catch small virii, that fit in a single IP packet, but the vast majority of them are transmitted in TCP and are large enough anyway. An IDS would still have plenty of time to instruct the router to reset the connection.
OTOH, the router will not necessarily have to close the TCP connection itself. IDS could do this too, masquarading as the victim. There's no reason why the router should be bothered with this task, right? And it would be faster too.
To summarize: "Let routers route, servers serve, and [AV-]detection systems stop virus TCP streams dead on their tracks.
Yes, but unlike multiregion DVD players, which also ignore the region byte (somewhat illegally, but who cares anyway?), hosts will be free to decide wether they want to honor this bit or not. Consider this as a hint, a suggestion, not as a policy that is forced upon you. If you choose to ignore the hint, that's perfectly fine, and, most importantly, this bit wouldn't break backward compatibility in any way.