We bitch about civil liberties on/. [...] but nobody even seems to care about the fact that Anthrax has been confirmed in New York City
This is known as a non-sequitor. I care. I also care about having our government walk down the path that so many others have already trod. "We need to protect our citizens, and to do that we need to restrict some of your rights" is the calling card of the totalitarian dictators of the world. Perhaps our current president will not take unfair advantage of this opportunity... however, we're setting the ground-work for the next president, or the one after that.
Most of these provisions (the one the Senate passed in particular) has a SUNSET clause.
Hmmm... I think you need to do a little more research. The Senate bill has no such clauses. The House bill suggests removing some measures in two years, but it looks like the compromise will remove only one provision after 3 years and the president will have the discression to extend it to 2006....
Check out CSPAN. It's your country too!
How important will PGP be to you when your entire home is destroyed by bombs/planes or wiped out by plague?
Here's the question back at you: how important is it NOW to make it illegal for me to use PGP? Right now, millions of people encrypt traffic of various sorts from email to web traffic to corporate VPNs. Replacing that hardware and software will take years. By then, we'll be back where we were in 2000. Yes, there will be terrorists using strong crypto. Yes, there will be terrorists using stegonography. Yes, there will be terrorists using various media outlets to transmit seemingly innocent messages. And, yes, it will be illegal for me to hide my credit card number from law enforcement.
So many folks get mad when Linux has bugs. Most of this is because they do not understand the model.
Let us compare the Linux development of a 2.odd version to a project branch in your average software company. That project branch will be unstable and used only for feature testing.
Then, you have the 2.evens. These are equivalent to a release branch or product mainline. You expect these to be *more* stable, but you still don't expect perfect code. When these are sent to your release egnineers and Q/A, you get several small rounds of bug-fixing as a result of regression tests, feature verification and so on.
This last step can be mapped to what distribution vendors do. So, for example, we expect Red Hat to go with something like 2.4.12, but to add the parport patch into their SRPM. They will doubtless also discover several other problems, or may be dragging along patches from previous kernels that have yet to be merged.
This is the art of release engineering. There's no such thing as a developer-released product. Never was. This is the value-add that distributions give us. They act as Q/A.
Re:How about OS's that should be brought back?
on
Niche Operating Systems
·
· Score: 3, Informative
Apollo's (then HP/Apollo, then HP) Domain/OS (originally Aegis) was the world's first network-based workstation operating system. By this I mean that it was developed to be a seamless part of a network of clients, servers and devices. It was a vaguely UNIX-like OS (which had UNIX emulation packages to layer on top of it) which was tied to the Apollo hardware.
Up until the RISC revolution, Apollo's hardware was not very exciting, but the Prism architecture in their DN10000 line made their OS really shine as an accedemic and scientific computing platform. Also, their DSEE (forunner of and superior to ClearCase) source control and versioning environment made it a powerfully compelling environment for large teams of programmers who needed to work collaberatively.
A great platform, gone forever because their marketting sucked and HP had no vision.:-(
No, not quite. There's still got to be glue between GDK and the hardware (which is what directfb is). If the hardware provided a GDK API, then directfb would just be a bunch of ioctls....
Ok, there are other replies that indicate some moderators might have been on crack, but let's take this simple suggestion seriously for a second and see where it goes.
If we were to put gnome-terminal and everything that it requires on a card, that card would hardly be a "graphics" card any longer. This would be a general purpose device with acces to (and thus assumptions about) all sorts of OS details. It would be managing its own IPC, creating devices in the filesystem, sockets on the network... it would be a BEAST.
Ok, let's just back off a second. *What* was the actuall proposal.... Well, someone wanted to speed up Gnome and remove some of the "bloat" by putting it in hardware.
A smaller subset of that is not only relatively easy, but quite desirable. An implementation of GDK (the abstraction layer that Gtk+ uses to talk to X or Windows or console graphics) in hardware would go a long way to eliminating the need for an X server entirely (the other pieces would be an Open/GL interface that Mesa could talk to, a set of window management primatives and a screen saver interface). This would be much more reasonable than putting an X Server in hardware, since it would provide a higher level interface, but at the same time you could still upgrade to the latest Gtk+ lib (assuming that its GDK supported the card's interfaces) and your version of Gnome would be totally independant of the card (except for the screen saver and window manager).
Such a device would give you much better Gnome performance, reduced footprint, a lack of need for the X server (in limited desktop environments where existing X applications were not needed) and an API that even Qt could be ported to (yes, Qt could be implemented on top of GDK).
MY_NET=1.2.3.4/5
INT_DEV=eth0
EXT_DEV=eth1
# 1. Any packet coming into your network must not have a source address of your internal network
ipchains -A forward -i $EXT_DEV -j DENY -s $MY_NET
# 2. Any packet coming into your network must have a destination address of your internal network
ipchains -A forward -i $EXT_DEV -j DENY -d ! $MY_NET
# 3. Any packet leaving your network must have a source address of your internal network
ipchains -A forward -i $INT_DEV -j DENY -s ! $MY_NET
# 4. Any packet leaving your network must not have a destination address of your internal network.
ipchains -A forward -i $INT_DEV -j DENY -d ! $MY_NET
# 5. Any packet coming into your network or leaving your network must not have a source or destination address of a private address or an address listed in RFC1918 reserved space. These include 10.x.x.x/8, 172.16.x.x/12 or 192.168.x.x/16 and the loopback network 127.0.0.0/8.
ipchains -A forward -i $EXT_DEV -j DENY -s 10.0.0.0/8
ipchains -A forward -i $EXT_DEV -j DENY -s 172.16.0.0/12
ipchains -A forward -i $EXT_DEV -j DENY -s 192.168.0.0/16
ipchains -A forward -j DENY -d 10.0.0.0/8
ipchains -A forward -j DENY -d 172.16.0.0/12
ipchains -A forward -j DENY -d 192.168.0.0/16
### REMOVE the next 3 rules for masquerading systems
ipchains -A forward -i $INT_DEV -j DENY -s 10.0.0.0/8
ipchains -A forward -i $INT_DEV -j DENY -s 172.16.0.0/12
ipchains -A forward -i $INT_DEV -j DENY -s 192.168.0.0/16
# 6. Block any source routed packets or any packets with the IP options field set.
# This is done at the kernel level under Linux, and is usually set by default.
MS Junk? Cool, I have to get it. I've been using lots of other junk, but if MS is entering the field, clearly I should dump the other junk and wait for an announcement of a beta for this new junk!
It's kind of scary that The President's Analyst is going to become timely again (BTW: If you haven't seen this movie, you should, it's got a very sneaky wit).
AT&T is thinking about selling it's broadband access to AOL, and this deal is likely just intended to sweeten the pot. Imagine, AOL as the one true broadband provider/movie studio/tv news outlet/browser company/music label? Yep, time to start a dialup ISP in MY area;-)
Ok, I'll admit I'm biased, but I think the next phase in the developing landscape of encryption is universal access to cryptography. I'm not talking about putting PGP on FTP servers, I'm talking about making hard crypto available to my mother.
To this end, I've started the PPS, which is a project devoted to transparent, universal email encryption. The goals are complex, since they are aimed at so many audiences, but you can browse the site and get an idea. If you find it to your liking, please drop me a line and sign up to help.
You don't have to have technical skills. I need proof-readers, coders, researchers, and more. The reference code is not nearly as important as getting the specification done and doing all of the research needed to get the various MUA vendors to sign on.
If in fact tools such as PGP are used by terrorists, how do governments protect against this?
Ignoring the Tom Clancy-esque view of our intelligence service as a jewel of freedom, what you describe is not a desirable goal. "Protecting" the government from the privacy of its citizens (and those of other nations) is about as awful as protecting them from my freedom to vote.
It's a disturbing reality that when you give people privacy, some will discuss how to blow up your cities. Revoking their freedom to discuss such things is called law enforcement, and it happens by punishing them for committing acts of agression, not for having privacy.
If my mother had been in the WTC, and it were CLEAR that PGP had been used to communicate how to attack, I would still fight to MY death to protect our right to use it. Terrorism can be stopped, but if we give up our freedom to do it, we've defended nothing.
Phil, as you know I've been rallying to get support for my take on what it would take to get privacy through encryption into the hands of everyone in the world (regardless of sophistication level).
I've been in the software and systems world for 12 years, but you have a whole lot on me when it comes to security through crypto. What do you think will be the major hurdles for getting ma-and-pa-average to use crypto?
The beauty of the one time pad is that the pad doesn't have to be truly random to be effective. There is still absolutely no way to know if you have decrypted the message "correctly."
That's a slippery slope, and many code-breakers would be thrilled to hear you say it (unless you were on their side;-)
Problem is that you can tell if what you decrypt to makes any sense at all. The chances of that happening are *very* remote. If it does happen, based on some course of reason (not just random tries), then you probably have something.
It becomes a game of statistics, you see.
I think the example in Cryptonomicon is hooey. I don't think that knowing the pad is guaranteed to "seem" random to a human is going to buy you enough to make 1945 technology work. However, given computers that can look for patterns VERY fast, the weakness of non-random data is a problem.
Re:One Time Pad Random Generation : OT
on
Blaming Encryption
·
· Score: 2
Of course, under Linux and many other modern OSes, you can simply read from/dev/random, which will block when it's waiting to collect more random bits from the environment, or/dev/urandom which will never block, instead it will use the entropy pool to seed a pseudo-random number generator.
I've seen code that uses setjmp/longjmp timing, seek delays and many other sources of POSIX randomness. The key thing is to make sure that external influences do not remove your randomness.
Seamless distribution. The system should determine where computations execute or data resides, moving them dynamically as necessary.
**FLASH** Redmond, WA -- Today a new computer clone (see "When Did We Stop Calling Them Virii") was released today by the hacker group, "Girls Just Wanna Have Fun". As is now typical of clones, it spreads by convincing millions of desktops around the world that it should be moved onto their processors for milliseconds at a time....
Worldwide scalability. Logically there should be only one system, although at any one time it may be partitioned into many pieces.
...researcher at M.I.T. says that it's nearly impossible to stop "She Bop", due in part to the fact that it's not technically "spreading", so much as it's simply "running"...
Fault-tolerance. The system should transparently handle failures or removal of machines, network links, and other resources without loss of data or functionality.
...even the most drastic measures have been discarded as impractical. Said one security expert, "if you took down all of the computers in the world but one, it would remain on that one last computer, until the rest were back up."...
Self-tuning. The system should be able to reason about its computations and resources, allocating, replicating, and moving computations and data to optimize its own performance, resource usage, and fault-tolerance.
...The effects of this clone seem to be somewhat benign. For the most part, it just convinces the systems that it runs on that they should run all of the normal programs on Department of Energy systems instead...
Self-configuration. New machines, network links, and resources should be automatically assimilated.
...One negative impact, however is that the last vestiges of the "open source" operating system networks in foreign countries (they are illegal, here in the U.S.) are being starved for network bandwidth because of what authorities are calling "quality of service feedback noise" which is apparently convincing all major "backbone" carriers (Sprint, AOL/AT&T and McDonalds/Worldcom) that they need to set asside more and more resources for upcoming games of MMHearts (Microsoft's hit game from last year, which combines massively multiplayer games with the most used program of all time)....
Security. Although a single system image is presented, data and computations may be in many different trust domains, with different rights and capabilities available to different security principals.
...In response to this latest event, the Justice department has said that they may petition the NSA for a copy of the Microsoft U.S. Trust Key, which would give the department ultimate control over all deployed operating systems. When asked if this was a temporary measure, Dr. Reno, III responded, "I can't see why we could need to use the key again, but it would probably be prudent of us to keep it for now...
Resource controls. Both providers and consumers may explicitly manage the use of resources belonging to different trust domains. For instance, while some people might be content to allow their data and computations to use any resources available anywhere, some companies might choose, for instance, not to store or compute their year-end financial statement on their competitor?s machines. What!? You thought I could come up with a witty way to make fun of that statement?! I'm not a magician!
This is weak because you are using data which is not random enough. You're much better off using a good source of random data and then distributing CDs before your agent leaves on his (or her) multi-year mission to buy jelly donuts and bring them back to the true believers in the great Homer.
You can then send him an order to abort the mission and instead turn themselves into the police mid-mission and no one can read the message.
Hiding the encrypted message is another matter which has many solutions. The easiest would probably be some form of steganography, but there are plenty of obvious places that such info is traded (e.g. short wave numbers stations).
Look, I'm not going to tell you how to run a terrorist organization securely, but suffice to say that a cell-based organization can (and likely they do) distribute a series of very-large one-time-pads on... say... DVD-ROMs and then use any one of the long-range, broadcast mediums to convey the encrypted data.
Is it slow without software? Yes. Can you write the software in Perl in 1 line? Yes. Can that code be sent on a CD along with the pads? Sure.
Well, then if we're not restricting terrorist communications, what ARE we doing?
Yep, we're making sure that in 10 years, no one's business transactions are safe from the prying eyes of government. Boeing will get the latest info on what Airbus is doing. Microsoft (whose campaign donations are adequate) will get info on what Red Hat (whose campaign donations are non-existant) is doing, etc.
This is how a government works. Be aware of it, and be smart about how much of it you allow.
Yes, certainly. Public key encryption raises the bar, and makes it easier to move keys. However, it does not make it any harder or easier to decrypt encrypted data. Will we make one-time pads illegal too? That's pretty hard, since you can't determine if a given chunk of data is a one-time-pad or noise generated by a buffer-underflow.
Sad, really, but I thank you for your intelligent comments. I especially liked your pointing out that "even a quantum" computer is helpless in the face of a one time pad, since you can't tell if you've got it right.
Has anyone read the short story that involves a gigantic maze of nodes, each with a book-shelf and with several people wandering around trying to figure out what the world is all about? Very cool book that points out some of the problems with one-time-pad decryption....
Exactly my point. If a kid who knows basic boolean algebra (XOR) can create encrypted messages that defy the best decryption, what the hell is this about?
We could argue that the average teen (or terrorist) doesn't have access to quality random data, but then there's/dev/random on your average Red Flag Linux from China...:-/
Many have said the cat is out of the bag... no, the cat was out of the bag in 1850. The cat is now living in a large and opulant palace in the Nile River Delta, being woshiped by women who thow tiny pickles at it... take the metaphor for what it's worth;-)
Break this or shut up....
on
Blaming Encryption
·
· Score: 3, Interesting
The following message was encrypted with one of the simplest cyphers known. I took the text and a random, non-repeating pad and used XOR between the ASCII values of the two. I then base64-encoded the result so that/. could display it (note, this last step is reversable trivially).
Let this string be the line in the sand. If this can be decrypted, THEN we should worry about encryption software. If it cannot be decrypted, then any high school student can do strong crypto in their bedroom with the calculator they got for free for signing up for a mall card, and this discussion is just about invading privacy and enabling government to spy on businesses.
He tinkered with a couple of stories without anyone noticing, then edited an August Reuters story about Dmitry Sklyarov, so that it said that Dmitry's program raised "the haunting specter of inner-city minorities with unrestricted access to literature, and through literature, hope."
My jaw is left gaping.... Oh, I wish all crackers were this smart! Thank you for restoring my faith in human sarcasm;-)
But, I'm already running Linux on 2 machines at home and close to 100 at work. I'm not in need of a new distro. I was SPECIFICALLY checking out debian because friends of mine had represented it as easier to maintain....
Can someone speak to us lay-people (when it comes to Java anyway) about the differences between Tomcat and J-Run? Are the competitors? Do they fit different niches?
I'm just wondering because I know some folks who are looking at upgrading J-Run, and I might advise them to check out Tomcat instead if that makes sense.
Check out CSPAN. It's your country too!
Here's the question back at you: how important is it NOW to make it illegal for me to use PGP? Right now, millions of people encrypt traffic of various sorts from email to web traffic to corporate VPNs. Replacing that hardware and software will take years. By then, we'll be back where we were in 2000. Yes, there will be terrorists using strong crypto. Yes, there will be terrorists using stegonography. Yes, there will be terrorists using various media outlets to transmit seemingly innocent messages. And, yes, it will be illegal for me to hide my credit card number from law enforcement.Yep, big improvement.
So many folks get mad when Linux has bugs. Most of this is because they do not understand the model.
Let us compare the Linux development of a 2.odd version to a project branch in your average software company. That project branch will be unstable and used only for feature testing.
Then, you have the 2.evens. These are equivalent to a release branch or product mainline. You expect these to be *more* stable, but you still don't expect perfect code. When these are sent to your release egnineers and Q/A, you get several small rounds of bug-fixing as a result of regression tests, feature verification and so on.
This last step can be mapped to what distribution vendors do. So, for example, we expect Red Hat to go with something like 2.4.12, but to add the parport patch into their SRPM. They will doubtless also discover several other problems, or may be dragging along patches from previous kernels that have yet to be merged.
This is the art of release engineering. There's no such thing as a developer-released product. Never was. This is the value-add that distributions give us. They act as Q/A.
Apollo's (then HP/Apollo, then HP) Domain/OS (originally Aegis) was the world's first network-based workstation operating system. By this I mean that it was developed to be a seamless part of a network of clients, servers and devices. It was a vaguely UNIX-like OS (which had UNIX emulation packages to layer on top of it) which was tied to the Apollo hardware.
:-(
Up until the RISC revolution, Apollo's hardware was not very exciting, but the Prism architecture in their DN10000 line made their OS really shine as an accedemic and scientific computing platform. Also, their DSEE (forunner of and superior to ClearCase) source control and versioning environment made it a powerfully compelling environment for large teams of programmers who needed to work collaberatively.
A great platform, gone forever because their marketting sucked and HP had no vision.
No, not quite. There's still got to be glue between GDK and the hardware (which is what directfb is). If the hardware provided a GDK API, then directfb would just be a bunch of ioctls....
Ok, there are other replies that indicate some moderators might have been on crack, but let's take this simple suggestion seriously for a second and see where it goes.
If we were to put gnome-terminal and everything that it requires on a card, that card would hardly be a "graphics" card any longer. This would be a general purpose device with acces to (and thus assumptions about) all sorts of OS details. It would be managing its own IPC, creating devices in the filesystem, sockets on the network... it would be a BEAST.
Ok, let's just back off a second. *What* was the actuall proposal.... Well, someone wanted to speed up Gnome and remove some of the "bloat" by putting it in hardware.
A smaller subset of that is not only relatively easy, but quite desirable. An implementation of GDK (the abstraction layer that Gtk+ uses to talk to X or Windows or console graphics) in hardware would go a long way to eliminating the need for an X server entirely (the other pieces would be an Open/GL interface that Mesa could talk to, a set of window management primatives and a screen saver interface). This would be much more reasonable than putting an X Server in hardware, since it would provide a higher level interface, but at the same time you could still upgrade to the latest Gtk+ lib (assuming that its GDK supported the card's interfaces) and your version of Gnome would be totally independant of the card (except for the screen saver and window manager).
Such a device would give you much better Gnome performance, reduced footprint, a lack of need for the X server (in limited desktop environments where existing X applications were not needed) and an API that even Qt could be ported to (yes, Qt could be implemented on top of GDK).
MY_NET=1.2.3.4/5
INT_DEV=eth0
EXT_DEV=eth1
# 1. Any packet coming into your network must not have a source address of your internal network
ipchains -A forward -i $EXT_DEV -j DENY -s $MY_NET
# 2. Any packet coming into your network must have a destination address of your internal network
ipchains -A forward -i $EXT_DEV -j DENY -d ! $MY_NET
# 3. Any packet leaving your network must have a source address of your internal network
ipchains -A forward -i $INT_DEV -j DENY -s ! $MY_NET
# 4. Any packet leaving your network must not have a destination address of your internal network.
ipchains -A forward -i $INT_DEV -j DENY -d ! $MY_NET
# 5. Any packet coming into your network or leaving your network must not have a source or destination address of a private address or an address listed in RFC1918 reserved space. These include 10.x.x.x/8, 172.16.x.x/12 or 192.168.x.x/16 and the loopback network 127.0.0.0/8.
ipchains -A forward -i $EXT_DEV -j DENY -s 10.0.0.0/8
ipchains -A forward -i $EXT_DEV -j DENY -s 172.16.0.0/12
ipchains -A forward -i $EXT_DEV -j DENY -s 192.168.0.0/16
ipchains -A forward -j DENY -d 10.0.0.0/8
ipchains -A forward -j DENY -d 172.16.0.0/12
ipchains -A forward -j DENY -d 192.168.0.0/16
### REMOVE the next 3 rules for masquerading systems
ipchains -A forward -i $INT_DEV -j DENY -s 10.0.0.0/8
ipchains -A forward -i $INT_DEV -j DENY -s 172.16.0.0/12
ipchains -A forward -i $INT_DEV -j DENY -s 192.168.0.0/16
# 6. Block any source routed packets or any packets with the IP options field set.
# This is done at the kernel level under Linux, and is usually set by default.
Friends don't help friends install MS junk
;-)
MS Junk? Cool, I have to get it. I've been using lots of other junk, but if MS is entering the field, clearly I should dump the other junk and wait for an announcement of a beta for this new junk!
It's kind of scary that The President's Analyst is going to become timely again (BTW: If you haven't seen this movie, you should, it's got a very sneaky wit).
;-)
AT&T is thinking about selling it's broadband access to AOL, and this deal is likely just intended to sweeten the pot. Imagine, AOL as the one true broadband provider/movie studio/tv news outlet/browser company/music label? Yep, time to start a dialup ISP in MY area
Ok, I'll admit I'm biased, but I think the next phase in the developing landscape of encryption is universal access to cryptography. I'm not talking about putting PGP on FTP servers, I'm talking about making hard crypto available to my mother.
To this end, I've started the PPS, which is a project devoted to transparent, universal email encryption. The goals are complex, since they are aimed at so many audiences, but you can browse the site and get an idea. If you find it to your liking, please drop me a line and sign up to help.
You don't have to have technical skills. I need proof-readers, coders, researchers, and more. The reference code is not nearly as important as getting the specification done and doing all of the research needed to get the various MUA vendors to sign on.
It's harder than that.
For example, one of the trade-offs that PPS had to make was to eliminate any pass-phrases on private keys by default.
This is because most users won't remember a password, and having to remember another one will be why they find ways not to use encryption.
You and I will still want to set passphrases, but Joe Sixpack won't.
I was asking Phil if he saw any other hurdles like that.
Ignoring the Tom Clancy-esque view of our intelligence service as a jewel of freedom, what you describe is not a desirable goal. "Protecting" the government from the privacy of its citizens (and those of other nations) is about as awful as protecting them from my freedom to vote.
It's a disturbing reality that when you give people privacy, some will discuss how to blow up your cities. Revoking their freedom to discuss such things is called law enforcement, and it happens by punishing them for committing acts of agression, not for having privacy.
If my mother had been in the WTC, and it were CLEAR that PGP had been used to communicate how to attack, I would still fight to MY death to protect our right to use it. Terrorism can be stopped, but if we give up our freedom to do it, we've defended nothing.
Phil, as you know I've been rallying to get support for my take on what it would take to get privacy through encryption into the hands of everyone in the world (regardless of sophistication level).
I've been in the software and systems world for 12 years, but you have a whole lot on me when it comes to security through crypto. What do you think will be the major hurdles for getting ma-and-pa-average to use crypto?
Thanks!
The beauty of the one time pad is that the pad doesn't have to be truly random to be effective. There is still absolutely no way to know if you have decrypted the message "correctly."
;-)
That's a slippery slope, and many code-breakers would be thrilled to hear you say it (unless you were on their side
Problem is that you can tell if what you decrypt to makes any sense at all. The chances of that happening are *very* remote. If it does happen, based on some course of reason (not just random tries), then you probably have something.
It becomes a game of statistics, you see.
I think the example in Cryptonomicon is hooey. I don't think that knowing the pad is guaranteed to "seem" random to a human is going to buy you enough to make 1945 technology work. However, given computers that can look for patterns VERY fast, the weakness of non-random data is a problem.
For starters, you want to read RFC1750.
/dev/random, which will block when it's waiting to collect more random bits from the environment, or /dev/urandom which will never block, instead it will use the entropy pool to seed a pseudo-random number generator.
Of course, under Linux and many other modern OSes, you can simply read from
I've seen code that uses setjmp/longjmp timing, seek delays and many other sources of POSIX randomness. The key thing is to make sure that external influences do not remove your randomness.
Hardware devices exist as well.
Congradulations H! I can't wait to see the little Hemoid approving submissions! ;-)
- Seamless distribution. The system should determine where computations execute or data resides, moving them dynamically as necessary.
- Worldwide scalability. Logically there should be only one system, although at any one time it may be partitioned into many pieces.
- Fault-tolerance. The system should transparently handle failures or removal of machines, network links, and other resources without loss of data or functionality.
- Self-tuning. The system should be able to reason about its computations and resources, allocating, replicating, and moving computations and data to optimize its own performance, resource usage, and fault-tolerance.
- Self-configuration. New machines, network links, and resources should be automatically assimilated.
- Security. Although a single system image is presented, data and computations may be in many different trust domains, with different rights and capabilities available to different security principals.
- Resource controls. Both providers and consumers may explicitly manage the use of resources belonging to different trust domains. For instance, while some people might be content to allow their data and computations to use any resources available anywhere, some companies might choose, for instance, not to store or compute their year-end financial statement on their competitor?s machines.
Yep, this'll be fun. Where do I buy the popcorn?What!? You thought I could come up with a witty way to make fun of that statement?! I'm not a magician!
This is weak because you are using data which is not random enough. You're much better off using a good source of random data and then distributing CDs before your agent leaves on his (or her) multi-year mission to buy jelly donuts and bring them back to the true believers in the great Homer.
You can then send him an order to abort the mission and instead turn themselves into the police mid-mission and no one can read the message.
Hiding the encrypted message is another matter which has many solutions. The easiest would probably be some form of steganography, but there are plenty of obvious places that such info is traded (e.g. short wave numbers stations).
Look, I'm not going to tell you how to run a terrorist organization securely, but suffice to say that a cell-based organization can (and likely they do) distribute a series of very-large one-time-pads on... say... DVD-ROMs and then use any one of the long-range, broadcast mediums to convey the encrypted data.
Is it slow without software? Yes. Can you write the software in Perl in 1 line? Yes. Can that code be sent on a CD along with the pads? Sure.
Well, then if we're not restricting terrorist communications, what ARE we doing?
Yep, we're making sure that in 10 years, no one's business transactions are safe from the prying eyes of government. Boeing will get the latest info on what Airbus is doing. Microsoft (whose campaign donations are adequate) will get info on what Red Hat (whose campaign donations are non-existant) is doing, etc.
This is how a government works. Be aware of it, and be smart about how much of it you allow.
Yes, certainly. Public key encryption raises the bar, and makes it easier to move keys. However, it does not make it any harder or easier to decrypt encrypted data. Will we make one-time pads illegal too? That's pretty hard, since you can't determine if a given chunk of data is a one-time-pad or noise generated by a buffer-underflow.
Sad, really, but I thank you for your intelligent comments. I especially liked your pointing out that "even a quantum" computer is helpless in the face of a one time pad, since you can't tell if you've got it right.
Has anyone read the short story that involves a gigantic maze of nodes, each with a book-shelf and with several people wandering around trying to figure out what the world is all about? Very cool book that points out some of the problems with one-time-pad decryption....
Exactly my point. If a kid who knows basic boolean algebra (XOR) can create encrypted messages that defy the best decryption, what the hell is this about?
/dev/random on your average Red Flag Linux from China... :-/
;-)
We could argue that the average teen (or terrorist) doesn't have access to quality random data, but then there's
Many have said the cat is out of the bag... no, the cat was out of the bag in 1850. The cat is now living in a large and opulant palace in the Nile River Delta, being woshiped by women who thow tiny pickles at it... take the metaphor for what it's worth
The following message was encrypted with one of the simplest cyphers known. I took the text and a random, non-repeating pad and used XOR between the ASCII values of the two. I then base64-encoded the result so that /. could display it (note, this last step is reversable trivially).
5 w+lAsIAozQt6OMUCji4E2BInB+
W QJ AOkNb1LHm60vNbR5uNyrYgkNPY
Let this string be the line in the sand. If this can be decrypted, THEN we should worry about encryption software. If it cannot be decrypted, then any high school student can do strong crypto in their bedroom with the calculator they got for free for signing up for a mall card, and this discussion is just about invading privacy and enabling government to spy on businesses.
du+27XAFml4uYuezNwvsewJpwj+AElF6ySV7vgXjtdoMIHYVT
tZHoDscCzdoV2VjlT9zPwJtdfbmHrt3wABqINnfrRbTRppr
FyzyfS+Gp+/L+w3u04A=
He tinkered with a couple of stories without anyone noticing, then edited an August Reuters story about Dmitry Sklyarov, so that it said that Dmitry's program raised "the haunting specter of inner-city minorities with unrestricted access to literature, and through literature, hope."
;-)
My jaw is left gaping.... Oh, I wish all crackers were this smart! Thank you for restoring my faith in human sarcasm
But, I'm already running Linux on 2 machines at home and close to 100 at work. I'm not in need of a new distro. I was SPECIFICALLY checking out debian because friends of mine had represented it as easier to maintain....
Can someone speak to us lay-people (when it comes to Java anyway) about the differences between Tomcat and J-Run? Are the competitors? Do they fit different niches?
I'm just wondering because I know some folks who are looking at upgrading J-Run, and I might advise them to check out Tomcat instead if that makes sense.
Thanks!
Yep, there's one called Mozilla ;-)