Think.. Porn images tend to be noisy, low quality. Perfect for hiding random bits.
And if someone sees them, then don't tend to look twice.. Though they might tend to make copies for 'safe keeping'.
So, you can move data through sending porn images to each other. You send american porn, they send chinese porn.
Another option is to do the same, only on an FTP site.
There are a few practical problems though, first, the stego technique must be some type of spread-spectrum. (IE: keyed, if you don't know the key, you can't determine if there's any data stego'ed in it.) The second problem is where do you obtain so much porn? Maybe you'll have to accept donations? Or make your own porn?
Interesting reading; I'll give ya that much.. Right now I'm going through the Hoar paper on your site.. Semi-interesting.
But it seems to be more along the lines of defining your langauge in a logical framework (a prolog-like language), then defining the semantics and theorems of it..
Suggestion, try looking at twelf (www.twelf.org). You can define any damned language you want in it, and for some, you can automatically derive theorems from it, and go up&down.. Not too good with the theorem proving between layers; but I doubt that you could make a useful sound top-down logic.
We've all heard of the nastiness with people snooping around our hard drives.. Since automated bootup's are important, I don't think it's practical to require a password JUST to decrypt stuff to start up the machine. Even if users can use encrypted loopback filesystems to encrypt stuff, there are other places where stuff can hide.
Here's what I'd like for linux:
Encrypted swap file. It doesn't get cleaned out regularily, there's no easy way TO clean it out, and it's something you can easily miss. As an alternative, clean it on boot and slowly overwrite unused pages. (Say, nuke one free page every X seconds.) Or encrypt and overwrite, to make things harder to backtrace.
Secure delete. Have the ability to secure-delete files, on a per-file or per-partitian basis. (I'd nominate '/var' for this.) Or, have a way to slowly run through free harddrive space and nuke anything sitting there. Best yet, have both.
Secure storage of old logfiles. Logfiles can be a goldmine, squid, httpd, mail, process accounting, lastlog, etc. You want to save them around, but you don't want anyone nosey to be able to look at them. How about secure deleting them and then running them through a user-chosen PGP key for storage, or making several different archival backups on different PGP key's. That way, I can keep the last week's logs on my pgp key, and secure-delete them after a week, while keeping the archival logs on a PGP key that isn't even physically located near the computer. (In a bank, or a friends house.)
Encrypted/tmp. Let someone define a/tmp partitian that isn't intended to survive a reboot. That/tmp may be encrypted with a random key and then reformatted on each reboot. You can make a second/tmp2 which is formatted normally and is kept accross a reboot. This could be hacked with encrypted loopback and mke2fs it on bootup.
None of these require a non-automatic bootup.
For semi-important stuff that you don't want people to look at easily (shell history, other history, email), you can store it in an automatically-generated encrypted file. Each file is encrypted with a seperate key. The inode stores the file-key XOR'ed with a user-key, a group-key, a root-key and an 'any-key'. Having a root-key on every file means that the contents can be compromised if root's password is compromised. This isn't much of a problem because any really important files can be in an encrypted partitian. Leaving it out doesn't buy you much either.
The group-key is stored in/etc/group. The user-key is an XOR between a number sitting in/etc/passwd and the MD5 hash of their password. This type of encryption is a good choice for something like ~/.bash_history, or ~/.ssh, or ~/.pgp. The 'any-key' is a the plaintext key, it exists if the file is readable to the public, It also must exist for any encrypted file that's required for bootup. (such file may be phsyically encrypted, but must be logically plaintext). All files are subject to normal access permission, and the above keys are altered appropriately and automatically on a chmod.
As we still want to retain automatic boot, some files must remain physically unencrypted, or logically unencrypted. (encrypted with a key, but a key that's stored unencrypted on the drive.) log files in/var, for example. There are some reasons to keep all files physically encrypted; it makes it hard to trivially scan the drive for statistically interesting material. The drive superficially appears a morass of encrypted gibberish.:)
Unless I'm mistaken, the above, or a variant of the above won't prevent automatic booting. Also, it doesn't require anything extra from user-level code and it'll keep even very nosey people away.
Finally, you have encrypted filesystems. Real encrypted filesystems that are mounted manually by the user. These could be immune from everything but a hardware sniffer, or a root sniffer.
Personally, I can't wait to see some or all of these.. First priorty for me is encrypted swap file, secure deletion, and secure storeage of old logfiles. There is already a (hackish) implementation of encrypted filesystems. With that, you can hack an encrypted/tmp. The transparently-encrypted filesystem is the most complicated, but would be sweet to have.:)
(Professor Robert Harper is one of the creators of Standard ML, and a very neat guy. BTW, if you could feed me some info on the TILT project, I'd love to study the compiler.. TILT is where the Python LISP compiler was about 8 years ago.)
I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago. (CMUCL)
Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)
It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.
Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros' A simple example is a 3-way if-then. (:less,:greater,:equal). A slightly more complicated example is adding in c-style for-loops. (done with the 'loop' facility)
For a fairly complicated example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops and other iteration constructs.
For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.
This is much like the one example of aspect-oriented programming, which was a realtime handwriting recognition program. It needed to do edge detects, averaging, convolutions. To do each operation in turn would have been horrific in time and space. The loops could be merged manually, but obfuscated the core algorithms and made it difficult to modify. The overhead of doing this transformation manually was a 50x code increase. From 700 lines to 35000 lines!
They implemented a new mini-langauge (Adding 'primitive' things like pointwise, convolve, etc to the language.) and used macro's do that merging automatically made the core algorithm obvious and trivial to change. The result was the core algorithm required only 700 lines of code, and another 1000 lines of code to do the merging and fusing of loops.. 2000 lines of code to do what took 35000 lines of code to do manually!
If you come from LISP, Aspect oriented programming is stupidly obvious. (If you don't, you think, 'wow' look at the cool stuff that they invented, and think that they created it.)
As a much much more complicated example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer? Aspect oriented programming will never get this good.:)
Yet another plus of this is that you can runtime-generate and compile code. Want to compile that encryption inner loop to make a custom version for this key? It's as easy as
This works because the function 'twofish-encrypt' will be declared maybe-inline. Thus it'll be compiled as normal, but the source code will also be saved. Normally, a function call to it will invoke the unspecialized version. But if we compile a call to it that has known arguments, the compiler will fully specialize and inline it, and create a specialized assembly. (This is how CLOS is implemented.)
There are some nice advantages to having a simple syntax.:)
For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual. (I'd give links, but I use my personal version so I don't know where to find them on the net anymore.)
Common LISP still has the features of a functional language. It has first-order and higher-order functions or closures. Python has a strong type system and it makes fast code. Your claim that LISP runs slow is false.:) Like SML, it's interactive and incremental compilation. You can redefine functions without quitting. You can even redefine functions that are running in a different thread.
In fact, LISP was found to be almost 50% faster than C/C++ on average. There was a study done about a year ago where they compared C++ and Java. Unlike other study's between langauges, they had a dozen people implement the same program in C++ and Java and then compared the results. They found what you'd expect, Java was slow and sucked memory.
These guys decided to repeat the study, only comparing LISP and Java. Although the fastest implementation was in C++, they found that Lisp programs, as a group, were over 50% faster than the C++ programs as a group. Also, development time was a fraction that of C++ or Java, and the number of lines of code was half. Not only that, the variability in the number of lines of code and development times was signifigantly reduced.
(Tom, I'll be back at CMU in a month, if you want to talk about this, or let me get my greedy hands on the TILT compiler. Send mail to crosby@qwes.math.cmu.edu if interested.)
(Professor Harper is one of the creators of Standard ML, and a very neat guy. BTW, if you could feed me some info on the TILT project, I'd love to study the compiler.. TILT is where the Python LISP compiler was about 8 years ago.)
I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago.
Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)
It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.
Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros' For example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops.
For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.
This is much like the first example of aspect-oriented programming. As another example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer?
For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual.
There are hidden costs with spam. We all know and agree with that. There is the time that people waste downloading and deleting it.
But noone mentions the hidden costs of trying to BLOCK spam. Filters don't work perfectly. Good email gets rejected and blocked. Which is worse? Blocking 10 legitimate emails while blocking 1 spam? Blocking 10 spams while blocking one legitimate email?
Which is worse for the users and which is worse for the ISP?
If an ISP blocks legitimate email, first-time senders will forget it or not try again. Neither you nor they will never know what happened to; you'll probably blame it on the net-gods. But if the ISP doesn't block spammers they get complaints out the wazoo. Which will they choose?
That's what pisses me off about the RBL, they *are* a vigilante group. Would they have condoned DDOS against CyberPromotions? I'd say yes!
If I go with an ISP, I expect my ISP to *not* add my dialup range to the DUL. If I want to connect manually to a destination mail server (use the local sendmail to queue up mail) I'm paying for that service. Similarily, if they block any email destined for me without my consent, I'll change service providers.
I don't like the Spam, and the RBL's targets somewhat justify what they get, but I won't condone how the RBL acts.
They're like the ALF arsonists who would `` `bring to a screeching halt what countless protests and letter-writing campaigns could never stop.' '' by arsoning a slaughterhouse with some homemade napalm.
MAPS is just the coordinator; it's the people who use the list who are at fault and liable for the damages. It's harder to sue the thousands of people who use the RBL than it is to sue the coordinators. The coordinators just make a list.
Here's an email I sent to Hatch. Here's a quote from near the end:
No DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.
--
Hi.. I'm a fresh college graduate; I am an artist, instead of movies or art or music, I write code and come up with ideas. I'm in computer science, so my whole life will be creating what's commonly called 'intellecual property'.
As you are one of the initial creators of the DMCA, I would like to state my opinions on the topic after giving a short quotation:
--
"There has grown up in the minds of certain groups in this country the notion that because a man or a corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary public interest. This strange doctrine is not supported by statute nor common law. Neither individuals nor corporations have any right to come into court and ask that the clock of history be stopped, or turned back, for their private benefit. That is all." -- Robert A. Heinlein ("Life-Line")
--
I feel that copyright is untenable in the long term. Computers are too fast and can move duplicate information too easily. The current mass of human creativity is only 10^18 bytes. Everything. Film. Satelite pictures. Music. Science. Knowledge.
Last year, 10^17 bytes of storage was sold, so, easily, in under 10 years we'll have enough storage to store all of humanity digitally. Right now, >10^12 bytes are moved per second within the US, and that's doubling every year. That means that the equivalent of the entire body of human creativity gets moved every 3 months. In ten years 10^18 bytes will move every day. That flood of data can be controlled, but only at extreme effort and require the censorship infrastructure of 1984.
Within the bill, there are two specific clauses which stick out. The first is the term extension. The second is the anticircumvention provisions.
Copyright was intended as a limited term. I enjoy the cartoon strip Dilbert. As it is, it won't leave copyright till my great grandkids are born. Did you enjoy Santa Clause as a child? Santa was created by Thomas Nast who died in 1902. With a 70 year copyright term, Santa Clause would not have left copyright until 1972. His great grandchildren would have had the power of controlling if or when you saw Santa. For example, the Salvation Army couldn't have used his likeness. Copyright terms were shorter then, Santa entered the public domain and our culture is far richer for it.
No modern icon of our culture has entered the public domain. No icon that's newer than the TV set, newer than Rock&Roll, or newer than I Love Lucy have entered the public domain. How might those icons have affected our childhood if they were freely usable. Many of these icons are held by immortal corporations, who have no desire to see copyrights ever end.
Licensed use does not mean that it is freely usable. Licenses are revokable and can have their terms changed.
Copyright was intended to increase the number of icons in the public domain. It has failed. That is why the term should have never have increased.
The other part are the anticircumvention provisions. If I purchase a device, why do I not have a legitimate right to open it up and see how it works? If that device is my DVD player, or an SDMI player, and I engage my desire to see how it works, I am infringing on the anticircumvention provision. Similarily, if I purchase a device, I may wish to put my DVD player in a car, but as they do not sell DVD players designed for that use, I might need to reverse-engineer the player to adapt my own. I've broken no copyright-related law except for the DMCA anticircumvention.
This is the endemic problem with the anticircumvention provision is that one can insert many technological provisions into a device to prevent one from doing things that are legal under fair use. Things like making a backup copy for archival purposes. Make a copy of a CD of children's music so they can't scratch the origional.
Such technological measures may make it difficult for the amateur to violate copyright, but they make it equally difficult for them to do legitimate actions like make archival backups, or to use extracts for the purposes of critiquing or intellectual discourse. Or to convert their thousand-dollar CD collection into DVD-audio.
Such technological measures are useless against any well-supported adversary.
Do you have any friends who have hundreds of LP's? Fair use dictates that they should be able to convert their collection into CD's before they molder. If a technological provision prevented that, they cannot. If they violate the technological provision, they're in violation of the DMCA! There's no way to win!
Iron bars all around a bank prevent customers from stealing the furniture, but they also make it impossible to make a withdraw on their money. Determined bank robbers will get in regardless of the bars.
CD's, DVD's, or MP3's aren't the end of progress. Unless our cultural icons are continously replenished onto modern media, they will molder with the media they're stored on. This is already happening. Master's recorded in the 60's, or film from a decade earlier are already in danger of being lost forever. Even people who care can do nothing without violating copyright law, pre-DMCA. By the time they enter the public domain in 30-50 and something can be done, they'll be unreadable!
Is this the heritage we want to leave for our children.
When the last DVD player dies, whether that be in 30 years or 50 years, there will be no way to see a DVD movie. As there is a technological protection measure on DVD's and violating that is illegal, those movies won't be saved and are lost forever. If the DMCA stands, soon, all media will have such measures and will also be lost forever.
Thus, NO DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.
My personal preference is either to do away with copyright altogether, or to restrict copyright to a reasonable term, 20 years, renewable for an extra 20 years. 20 years suited the country for it's first 150 years. It suited Thomas Nast, the creator of Santa Clause and Uncle Sam. In this modern hectic world, it is more than enough.
Thanks for your time.. Scott A. Crosby crosby@qwes.math.cmu.edu
:: Duplicate unchanged all ya want, (please send email), but you must attribute it.
This quote is taken from a soon-to-be-posted copy of an email I'll be posting elsewhere.
Thus, NO DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.
Whenever I hear one of these discussions, I cannot help but remember this quote.
"There has grown up in the minds of certain groups in this country the notion that because a man or a corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary public interest. This strange doctrine is not supported by statute nor common law. Neither individuals nor corporations have any right to come into court and ask that the clock of history be stopped, or turned back, for their private benefit. That is all." -- Robert A. Heinlein ("Life-Line")
I remember hearing about it on a mailing list that postgresql loses a respectible amount of time because it fsync's it's files all the time. postgresql IS, like most other good RDBMs, paranoid about data security.
I'm sure everyone can guess how much of a slowdown constant fsync's would be, though maybe with ext3 or reiserfs, those operations can dump to the log and the penalty of fsync won't be as large.
If you don't mind giving up some integrity, you can disable them. I'd like to see that benchmark rerun where postgresql wasn't fsync'ing all the time.
The founders of DNS have reserved those 3 domains for use in 'example' documentation, explicitly so that documentation can use those domains in safety and know that any email will go to the bit-bucket.
They have a similarly reserved set of IP addresses that are only to be used as 'examples' in documentation. This is more important than you might think, there are several class-B's that are unusable on the modern internet because CISCO used them (instead of the real 'example IP's') in their documentation for setting up their routers. And more than a few admin's have used them verbatim.
So, for everyone who writes documentation, or wants an address/DNS that's reserved and will never be used in the global internet, use example.(com|net|org) and the appropriate IP ranges.
And we should start getting PGP keys up there, for two reasons. First, spammers aren't going to go looking into PGP keys for email addresses, and second so we can start encrypting more of our email.
I'm fairly intelligent and I am aware of the risks that that article talks about, but damnit! It scares me..
Here's a useful tip for all of us here. When you install a friend's computer or email program, make sure that it's got PGP and they know how to use it.
Then why don't they say that they'll release any source code after (say) 3-6 years. That's 3-6 years where they can be proprietary all they want and by the time they release it, it'll be obsolete and nearly worthless commercially.
That would be a hedge against abandonware and worth a LOT in the public-relations standpoint.
I don't mind closed source proprietary software as much as I dislike closed source proprietary software that will remain that way in perpetuity.
How many people would like to look at the origional PACMAN source? Or at the DR-DOS source? Or at a game AI algorithm. (I once spent several afternoons trying to figure out 'how they did that'. Hard with no source.)
Hell, what wouldn't I do to see the source code for Future Crew's Unreal2 demo!!
That's what makes me sad is that companies hold on to everything, no matter how commercially worthless it might be and never want to give it up. If Apple truly wanted to support the free software/open source community, then why not offer to release their code GPL in 4 or 5 years? Releasing it GPL will keep most of the sharks at bay. Microsoft (for example) won't want to glob chunks of it because they'd be forced to release their software too.
You claim that your anecdote is more 'true' than any number of statistics. Anecdotes lie because people remember the one anecdote and forget the millions of contrary examples.
Hell! I gave references that debunked 3 stupid anecdotes in the parent to your post. If you look around the right places, you can find people who debunk more anecdotes.
How much are land prices? How big of a house could you buy/build out in the middle of nowhere? If you want to live in the city where everyone else lives, you have to pay the prices, or settle with a smaller living area. You have to compete with everyone else who wants to live there. And many of them are people who are also computer science and have fairly signifigant incomes.
How much is a farm in western Montana with lots of land and a big house? How much is a small house close to Silicon Valley? If having a big house is so important, why not move to Montana?
It's a choice that life gives you. Quit bitching that you don't like either option.
Try running some statistics; the poor in the year 2000 are better off than the middle class in 1971. The average work week has gone DOWN by about 2 hours in the last 30 years.
Since 1900, we've gone from 76% of out income being spent on food, clothing, and shelter to 37%, which is why we have *twice* the income to spend on goodies like cars and computers. If you want a workweek half as long, just give up those toys. More good news like this here.
Here's another tidbit. Did you know that bank's create wealth. Say a ``rich person'' puts a billion dollars in the bank. That money gets loaned out to people who buy goods which funds your salary. You, and a million other people put a thousand in the bank. Guess what? There's now two billion in the bank. So what if they have a billion in the bank? You have your thousand in the bank. Who controls more wealth? Your million friends of the big evil rich person? You both have the same wealth; wealth that you wouldn't have had had then not invested it. What does it matter, unless your envious?
That's what annoys me about all this inequitable distribution of wealth crap. If someone has money, they either do one of two things with it. They spend it, funding other people's salaries, or they invest it, where it gets multiplied 10x; with most of that going to other people's pockets.
The federal reserve is the one thing that's kept this economic expansion going so long. Fundamentally, if you make the competetion for labor sufficiently intense, the cost of labor goes up. Businesses then have to raise prices to compensate for the higher labor costs. This raises the cost of living and makes people demand higher wages. IE: inflation. Inflation is hideous, it can wipe out fixed incomes. (If you're retired and have to live on $500/month, having prices double over 5 years is nasty). It forces interest rates up, as banks have to hedge against being paid back in dollars that are worth less. It also makes long-term planning in any contract. If you agree to sell a million playstations for $300 over the next 3 years, and find out that the dollar is worth 1/2 as much near the end; you've wiped out your profit margin. There are places where inflation has been so severe, that prices have doubled every week; people got paid twice a day to help keep up. Either way, lending rates go up discourage lending, and the economy slows down. One's just nastier than the other.
Now, I will agree that a lot of the crap that corporations do should be stopped. I hate corporations railroading over honest people or freedom just because they're bigger. I hate corporations that lie and manipulate people or are hypocritical (like Ben and Jerrys unsafe, dioxin laced ice cream. ). I dislike the WTO or the MPAA.
But on the other side, I dislike the sabotage, terrorism and, most critically, the lies spread by the anti-corporations side.
Like any other human-made system, capitalism and corporatism isn't perfect. The system needs tuning and fixing once in a while. But, overall, it's the best way to run things that we know about. It's not a fundamentally broken system.
Spreading misinformation or lies around just to scare people into joining you is not the way to win. Spreading the truth is. Ultimately, in a democracy, the government answers to the people. If enough people demand something, it will happen.
I don't see too much of a big deal with their algorithm. So, they can do a public-private key cryptosystem faster than other people.
But, you never encrypt real data with RSA. It's slow and stupid. You use RSA to encrypt a session key and then encrypt the data with THAT key. If it's 100 times faster; that only means that it's 100x faster at something that already takes a fraction of a second (250ms on a P2-450). This is important for SSL or some other server which has to authenticate a large number of sessions. The average user won't need to authenticate more than a few sessions an hour.
Being 100x faster might have uses as a smartcard, but I don't immediately see a place where that would actually improve security, compared to current offerings. (If someone steals your smartcard that contains your private keys, you're just as screwed as if it was a plain old credit card.)
Also, RSA has withstood a 20 year test, unlike this new system. It has been standardized into almost every public cryptosystem alive, only the most pressing of reasons could force it out of that hegemony. Finally, RSA is about to leave patent production (3 months).
Who would want to ignore the time-proven RSA to risk an almost brand new cryptosystem. As Bruce Schiener said: There's no money in selling cyphers anymore. (And that goes double as RSA is about to leave patent protection.)
This company seems more interested in offering a product (music encryption) and selling it to management more than selling their cryptosystem. Why not just use standard techniques. Conceptually, they're just PGP'ing the music, why not do that literally?
If they're getting about 40,000 per license per year. (Or about 160,000 a year) What makes you think that suddenly it'll get cheaper.. Would they wan their profit margins to drop by a huge amount? Hell no!
What they'll do is they'll just charge you about 15,000/month. (or XYZ an hour, knowing that you'll use 15,000/XYZ hours in the typical month.)
I seem to remember hearing about all kinds of insane lawsuits and claims from about 20-25 years ago about how the VCR was supposed to kill film and how the TV industry and the movie industry were going to be dead by 1990.
Wow, I am *SO SUPRISED* that they've managed to make an insane bundle of money off of the rental industry. A rental industry that where they make how much profit, and one that they hadn't even imagined back then.
I wouldn't be surprised if a few lost out, but overall, the VCR was an incredible boom to the rental and videotape industry. Something that the extra freedom of the VCR was never expected to supply, but it did.
If you want the truth, I suspect that if they were to lose this case, and DMCA, and maybe even copyright. (as it's currently enforced), that they would be creative once again and figure out how to make even more insane bundles of money. And we'd get some more new art forms.
Of course, they see this as risk. And they're scared of being among the minority that can't adapt.
If I remember right, the IETF *requires* that there be two different implementations in order to ratify the RFC. (And incidently, they strongly frown upon anything based on patented technology.)
The GPL has similar requirements, so I wouldn't worry.
So thus, if a company can lose a million dollars in minute, that must mean that they make around 525 billion dollars a year in revenue.
Um, dudes, these numbers do not add up.
Even if we assume that that is a peak, and the average is 1/10 that.. How many companies on the planet run 50 billion dollars of revenue a year? More importantly, ANY such company would be plenty big enough to afford to avoid these outages.
The only other thing that plays with that quantity of money is banking. (Credit cards/Stock market), neither of which are californian E-businesses.
So, as written, it reads like trash. They're off by 3 orders of magnitude from the believable values.
... doesn't mean that your OEM won't purchase them seperately and install them on your system, or that you yourself can't do that.
Remember, this is just to keep MS from screwing off in the future. So what if your OEM has to go to N+1 companies instead of N. Most big OEM's install a half-doxen commercial packages and a dozen or more demo's. One more or one fewer won't make much of a difference.
You do realize that his ISP is going to probably choke or shoot him with his own gun over the slashdotting their server is about to recieve. Especially as it is in norway. (And given the probably very high per-megabyte bandwidth charge.)
Yes, a standard CFB or stream encryption algorithm has that weakness. Which is why you usually combine it with an (encrypted) CRC or cryptographically sign it. These are protocol-level issues.
And the fix is obvious, you said it yourself. If you don't sign the message in some fashion, you deserve to lose. Signing the message prevents most (all?) of these attacks.
If you do a 'gpg -e', you had better know what the security issues are. Of course, this applies to using ANY encryption software, no matter what settings you use on it. If you don't know your encryption software and what the options mean, you shouldn't be using it.
BTW, just including (and encrypting) the hash of the decrypted message isn't enough to protect against these attacks.
If the message is for multiple recipients, recipient A could decrypt the message, alter it, compute the correct hash for the altered message, and then repackage and send the altered message along to the other recipients who will accept this message as legitimate. To prevent this, the hash of the correct message should be 'signed' in some fashion where only the origional sender can create it. This process describes GPG's 'sign' option, which we know works.
Signing and encryption are orthogonal features and needed in different situations. If I am sending details of an auction to N people, I don't care who reads them, but I do NOT want them to alter the messages sent to the other recipients. If I just encrypt the message but leave it unsigned, noone can read the messgae, but they may alter it. (Admittedly, not very useful for communication, but useful for storage. For example, storing private stuff on a hard drive/floppy.) Finally, I may encrypt and sign the message.
You could consider it a user-interface issue. Maybe GPG should (by default) sign the message whenever the user requests encryption?
[[BTW, if you want to take this conversation to email, I'll be happy to. Unfortunately, my email address no longer works; I can email you.]]
Slashdot Mirror
Think.. Porn images tend to be noisy, low quality. Perfect for hiding random bits.
And if someone sees them, then don't tend to look twice.. Though they might tend to make copies for 'safe keeping'.
So, you can move data through sending porn images to each other. You send american porn, they send chinese porn.
Another option is to do the same, only on an FTP site.
There are a few practical problems though, first, the stego technique must be some type of spread-spectrum. (IE: keyed, if you don't know the key, you can't determine if there's any data stego'ed in it.) The second problem is where do you obtain so much porn? Maybe you'll have to accept donations? Or make your own porn?
Interesting reading; I'll give ya that much.. Right now I'm going through the Hoar paper on your site.. Semi-interesting.
But it seems to be more along the lines of defining your langauge in a logical framework (a prolog-like language), then defining the semantics and theorems of it..
Suggestion, try looking at twelf (www.twelf.org). You can define any damned language you want in it, and for some, you can automatically derive theorems from it, and go up&down.. Not too good with the theorem proving between layers; but I doubt that you could make a useful sound top-down logic.
We've all heard of the nastiness with people snooping around our hard drives.. Since automated bootup's are important, I don't think it's practical to require a password JUST to decrypt stuff to start up the machine. Even if users can use encrypted loopback filesystems to encrypt stuff, there are other places where stuff can hide.
Here's what I'd like for linux:
Encrypted swap file. It doesn't get cleaned out regularily, there's no easy way TO clean it out, and it's something you can easily miss. As an alternative, clean it on boot and slowly overwrite unused pages. (Say, nuke one free page every X seconds.) Or encrypt and overwrite, to make things harder to backtrace.
Secure delete. Have the ability to secure-delete files, on a per-file or per-partitian basis. (I'd nominate '/var' for this.) Or, have a way to slowly run through free harddrive space and nuke anything sitting there. Best yet, have both.
Secure storage of old logfiles. Logfiles can be a goldmine, squid, httpd, mail, process accounting, lastlog, etc. You want to save them around, but you don't want anyone nosey to be able to look at them. How about secure deleting them and then running them through a user-chosen PGP key for storage, or making several different archival backups on different PGP key's. That way, I can keep the last week's logs on my pgp key, and secure-delete them after a week, while keeping the archival logs on a PGP key that isn't even physically located near the computer. (In a bank, or a friends house.)
Encrypted
None of these require a non-automatic bootup.
For semi-important stuff that you don't want people to look at easily (shell history, other history, email), you can store it in an automatically-generated encrypted file. Each file is encrypted with a seperate key. The inode stores the file-key XOR'ed with a user-key, a group-key, a root-key and an 'any-key'. Having a root-key on every file means that the contents can be compromised if root's password is compromised. This isn't much of a problem because any really important files can be in an encrypted partitian. Leaving it out doesn't buy you much either.
The group-key is stored in
This type of encryption is a good choice for something like ~/.bash_history, or ~/.ssh, or ~/.pgp. The 'any-key' is a the plaintext key, it exists if the file is readable to the public, It also must exist for any encrypted file that's required for bootup. (such file may be phsyically encrypted, but must be logically plaintext). All files are subject to normal access permission, and the above keys are altered appropriately and automatically on a chmod.
As we still want to retain automatic boot, some files must remain physically unencrypted, or logically unencrypted. (encrypted with a key, but a key that's stored unencrypted on the drive.) log files in
Unless I'm mistaken, the above, or a variant of the above won't prevent automatic booting. Also, it doesn't require anything extra from user-level code and it'll keep even very nosey people away.
Finally, you have encrypted filesystems. Real encrypted filesystems that are mounted manually by the user. These could be immune from everything but a hardware sniffer, or a root sniffer.
Personally, I can't wait to see some or all of these.. First priorty for me is encrypted swap file, secure deletion, and secure storeage of old logfiles. There is already a (hackish) implementation of encrypted filesystems. With that, you can hack an encrypted
I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago. (CMUCL)
The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. (~30% slower at things like matrix multiplication, bench it yourself) , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)
Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)
It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.
Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros'
A simple example is a 3-way if-then. (:less,
A slightly more complicated example is adding in c-style for-loops. (done with the 'loop' facility)
For a fairly complicated example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops and other iteration constructs.
For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.
This is much like the one example of aspect-oriented programming, which was a realtime handwriting recognition program. It needed to do edge detects, averaging, convolutions. To do each operation in turn would have been horrific in time and space. The loops could be merged manually, but obfuscated the core algorithms and made it difficult to modify. The overhead of doing this transformation manually was a 50x code increase. From 700 lines to 35000 lines!
They implemented a new mini-langauge (Adding 'primitive' things like pointwise, convolve, etc to the language.) and used macro's do that merging automatically made the core algorithm obvious and trivial to change. The result was the core algorithm required only 700 lines of code, and another 1000 lines of code to do the merging and fusing of loops.. 2000 lines of code to do what took 35000 lines of code to do manually!
If you come from LISP, Aspect oriented programming is stupidly obvious. (If you don't, you think, 'wow' look at the cool stuff that they invented, and think that they created it.)
As a much much more complicated example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer? Aspect oriented programming will never get this good. :)
Yet another plus of this is that you can runtime-generate and compile code. Want to compile that encryption inner loop to make a custom version for this key? It's as easy as
,key)))
(defun twofish-make-fun (key)
(compile nil `#'(lambda (block) (twofish-encrypt block
This works because the function 'twofish-encrypt' will be declared maybe-inline. Thus it'll be compiled as normal, but the source code will also be saved. Normally, a function call to it will invoke the unspecialized version. But if we compile a call to it that has known arguments, the compiler will fully specialize and inline it, and create a specialized assembly. (This is how CLOS is implemented.)
There are some nice advantages to having a simple syntax. :)
For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual. (I'd give links, but I use my personal version so I don't know where to find them on the net anymore.)
Common LISP still has the features of a functional language. It has first-order and higher-order functions or closures. Python has a strong type system and it makes fast code. Your claim that LISP runs slow is false. :) Like SML, it's interactive and incremental compilation. You can redefine functions without quitting. You can even redefine functions that are running in a different thread.
In fact, LISP was found to be almost 50% faster than C/C++ on average. There was a study done about a year ago where they compared C++ and Java. Unlike other study's between langauges, they had a dozen people implement the same program in C++ and Java and then compared the results. They found what you'd expect, Java was slow and sucked memory.
These guys decided to repeat the study, only comparing LISP and Java. Although the fastest implementation was in C++, they found that Lisp programs, as a group, were over 50% faster than the C++ programs as a group. Also, development time was a fraction that of C++ or Java, and the number of lines of code was half. Not only that, the variability in the number of lines of code and development times was signifigantly reduced.
(Tom, I'll be back at CMU in a month, if you want to talk about this, or let me get my greedy hands on the TILT compiler. Send mail to crosby@qwes.math.cmu.edu if interested.)
I like SML a LOT, but there's a langauge which a lot of people aren't talking about. It's LISP. LISP has a public-domain compiler, an orphan of the Carnegie Mellon University lisp project from about 8 years ago.
The compiler (Python) is fast; it compiles down to raw machine code, and it's performance is comparable to C, and has been for the last 5 years. , which isn't bad for a compiler that's had a fraction of the effort of EGCS. It can use non-descriptor arguments and structures. It will also use type inference where it can (Roughly, the monomorphic subset of the type system of SML.)
Now, the language Common Lisp is exremely nice. It has a variety of built-in things like lists, hash tables, structures, vectors, multidimensional arrays... It's got a lot of declarative things too. Loops, 'foreach', 'set'... Lisp programs can't crash because it does typechecks too. (Though if Python infers that they're unnecessary, it'll omit them.)
It was the first object-oriented langauge to be standardized. CLOS (Common Lisp Object System) is amazing. You can have dispatch based on multiple arguments unlike java/C++ which is only polymorphic based on the first argument. And you've got multiple inheritence. With the MOP, you can even write your OWN OO system on top of it.
Because the syntax is simple, it makes it easy to have programmed transformations of code 'macros' For example, there's a package called 'SERIES' which adds in the equivalent of pipes to the language. You 'pipe' data between routines and it transforms the code into minimum-sized loops.
For example, if I have a list of triangles. My code looks like I first transform all of the triangles, then texture them, then transform them. again. This requires creating lots of superflouis triangles. SERIES will automagically turn this into a single loop on each triangle 'tranform -- texture -- transform'. Except that it'll handle multiple argument functions that return multiple results, and it'll handle conditionals in the functions. Not all loops can be merged, but it'll do what it can.
This is much like the first example of aspect-oriented programming. As another example, CLOS itself was implemented through macro's. Can you imagine a language powerful enough that you could 'transparently' layer a high-performance and very flexible OO system on top, WITHOUT REWRITING the underlying layer?
For hackers, there's the advantage that you can download ``Common Lisp The Language'' or the ``Common Lisp Hyperspec'' for a full specification of the language. No spending a hundred bux on a manual.
There are hidden costs with spam. We all know and agree with that. There is the time that people waste downloading and deleting it.
But noone mentions the hidden costs of trying to BLOCK spam. Filters don't work perfectly. Good email gets rejected and blocked. Which is worse? Blocking 10 legitimate emails while blocking 1 spam? Blocking 10 spams while blocking one legitimate email?
Which is worse for the users and which is worse for the ISP?
If an ISP blocks legitimate email, first-time senders will forget it or not try again. Neither you nor they will never know what happened to; you'll probably blame it on the net-gods. But if the ISP doesn't block spammers they get complaints out the wazoo. Which will they choose?
That's what pisses me off about the RBL, they *are* a vigilante group. Would they have condoned DDOS against CyberPromotions? I'd say yes!
If I go with an ISP, I expect my ISP to *not* add my dialup range to the DUL. If I want to connect manually to a destination mail server (use the local sendmail to queue up mail) I'm paying for that service. Similarily, if they block any email destined for me without my consent, I'll change service providers.
I don't like the Spam, and the RBL's targets somewhat justify what they get, but I won't condone how the RBL acts.
They're like the ALF arsonists who would `` `bring to a screeching halt what countless protests and letter-writing campaigns could never stop.' '' by arsoning a slaughterhouse with some homemade napalm.
MAPS is just the coordinator; it's the people who use the list who are at fault and liable for the damages. It's harder to sue the thousands of people who use the RBL than it is to sue the coordinators. The coordinators just make a list.
Here's an email I sent to Hatch. Here's a quote from near the end:
No DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.
--
Hi.. I'm a fresh college graduate; I am an artist, instead of movies or art or music, I write code and come up with ideas. I'm in computer science, so my whole life will be creating what's commonly called 'intellecual property'.
As you are one of the initial creators of the DMCA, I would like to state my opinions on the topic after giving a short quotation:
--
"There has grown up in the minds of certain groups in this country the notion that because a man or a corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary public interest. This strange doctrine is not supported by statute nor common law. Neither individuals nor corporations have any right to come into court and ask that the clock of history be stopped, or turned back, for their private benefit. That is all." -- Robert A. Heinlein ("Life-Line")
--
I feel that copyright is untenable in the long term. Computers are too fast and can move duplicate information too easily. The current mass of human creativity is only 10^18 bytes. Everything. Film. Satelite pictures. Music. Science. Knowledge.
Last year, 10^17 bytes of storage was sold, so, easily, in under 10 years we'll have enough storage to store all of humanity digitally. Right now, >10^12 bytes are moved per second within the US, and that's doubling every year. That means that the equivalent of the entire body of human creativity gets moved every 3 months. In ten years 10^18 bytes will move every day. That flood of data can be controlled, but only at extreme effort and require the censorship infrastructure of 1984.
Within the bill, there are two specific clauses which stick out. The first is the term extension. The second is the anticircumvention provisions.
Copyright was intended as a limited term. I enjoy the cartoon strip Dilbert. As it is, it won't leave copyright till my great grandkids are born. Did you enjoy Santa Clause as a child? Santa was created by Thomas Nast who died in 1902. With a 70 year copyright term, Santa Clause would not have left copyright until 1972. His great grandchildren would have had the power of controlling if or when you saw Santa. For example, the Salvation Army couldn't have used his likeness. Copyright terms were shorter then, Santa entered the public domain and our culture is far richer for it.
No modern icon of our culture has entered the public domain. No icon that's newer than the TV set, newer than Rock&Roll, or newer than I Love Lucy have entered the public domain. How might those icons have affected our childhood if they were freely usable. Many of these icons are held by immortal corporations, who have no desire to see copyrights ever end.
Licensed use does not mean that it is freely usable. Licenses are revokable and can have their terms changed.
Copyright was intended to increase the number of icons in the public domain. It has failed. That is why the term should have never have increased.
The other part are the anticircumvention provisions. If I purchase a device, why do I not have a legitimate right to open it up and see how it works? If that device is my DVD player, or an SDMI player, and I engage my desire to see how it works, I am infringing on the anticircumvention provision. Similarily, if I purchase a device, I may wish to put my DVD player in a car, but as they do not sell DVD players designed for that use, I might need to reverse-engineer the player to adapt my own. I've broken no copyright-related law except for the DMCA anticircumvention.
This is the endemic problem with the anticircumvention provision is that one can insert many technological provisions into a device to prevent one from doing things that are legal under fair use. Things like making a backup copy for archival purposes. Make a copy of a CD of children's music so they can't scratch the origional.
Such technological measures may make it difficult for the amateur to violate copyright, but they make it equally difficult for them to do legitimate actions like make archival backups, or to use extracts for the purposes of critiquing or intellectual discourse. Or to convert their thousand-dollar CD collection into DVD-audio.
Such technological measures are useless against any well-supported adversary.
Do you have any friends who have hundreds of LP's? Fair use dictates that they should be able to convert their collection into CD's before they molder. If a technological provision prevented that, they cannot. If they violate the technological provision, they're in violation of the DMCA! There's no way to win!
Iron bars all around a bank prevent customers from stealing the furniture, but they also make it impossible to make a withdraw on their money. Determined bank robbers will get in regardless of the bars.
CD's, DVD's, or MP3's aren't the end of progress. Unless our cultural icons are continously replenished onto modern media, they will molder with the media they're stored on. This is already happening. Master's recorded in the 60's, or film from a decade earlier are already in danger of being lost forever. Even people who care can do nothing without violating copyright law, pre-DMCA. By the time they enter the public domain in 30-50 and something can be done, they'll be unreadable!
Is this the heritage we want to leave for our children.
When the last DVD player dies, whether that be in 30 years or 50 years, there will be no way to see a DVD movie. As there is a technological protection measure on DVD's and violating that is illegal, those movies won't be saved and are lost forever. If the DMCA stands, soon, all media will have such measures and will also be lost forever.
Thus, NO DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.
My personal preference is either to do away with copyright altogether, or to restrict copyright to a reasonable term, 20 years, renewable for an extra 20 years. 20 years suited the country for it's first 150 years. It suited Thomas Nast, the creator of Santa Clause and Uncle Sam. In this modern hectic world, it is more than enough.
Thanks for your time..
Scott A. Crosby
crosby@qwes.math.cmu.edu
:: Duplicate unchanged all ya want, (please send email), but you must attribute it.
This quote is taken from a soon-to-be-posted copy of an email I'll be posting elsewhere.
Thus, NO DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.
Whenever I hear one of these discussions, I cannot help but remember this quote.
"There has grown up in the minds of certain groups in this country the notion that because a man or a corporation has made a profit out of the public for a number of years, the government and the courts are charged with the duty of guaranteeing such profit in the future, even in the face of changing circumstances and contrary public interest. This strange doctrine is not supported by statute nor common law. Neither individuals nor corporations have any right to come into court and ask that the clock of history be stopped, or turned back, for their private benefit. That is all." -- Robert A. Heinlein ("Life-Line")
That is what I expect. That's how it's supposed to be. But is it that way in practice? Is it that way 95% of the time? What about the other 5%?
I remember hearing about it on a mailing list that postgresql loses a respectible amount of time because it fsync's it's files all the time. postgresql IS, like most other good RDBMs, paranoid about data security.
I'm sure everyone can guess how much of a slowdown constant fsync's would be, though maybe with ext3 or reiserfs, those operations can dump to the log and the penalty of fsync won't be as large.
If you don't mind giving up some integrity, you can disable them. I'd like to see that benchmark rerun where postgresql wasn't fsync'ing all the time.
The founders of DNS have reserved those 3 domains for use in 'example' documentation, explicitly so that documentation can use those domains in safety and know that any email will go to the bit-bucket.
They have a similarly reserved set of IP addresses that are only to be used as 'examples' in documentation. This is more important than you might think, there are several class-B's that are unusable on the modern internet because CISCO used them (instead of the real 'example IP's') in their documentation for setting up their routers. And more than a few admin's have used them verbatim.
So, for everyone who writes documentation, or wants an address/DNS that's reserved and will never be used in the global internet, use example.(com|net|org) and the appropriate IP ranges.
And we should start getting PGP keys up there, for two reasons. First, spammers aren't going to go looking into PGP keys for email addresses, and second so we can start encrypting more of our email.
I'm fairly intelligent and I am aware of the risks that that article talks about, but damnit! It scares me..
Here's a useful tip for all of us here. When you install a friend's computer or email program, make sure that it's got PGP and they know how to use it.
Then why don't they say that they'll release any source code after (say) 3-6 years. That's 3-6 years where they can be proprietary all they want and by the time they release it, it'll be obsolete and nearly worthless commercially.
That would be a hedge against abandonware and worth a LOT in the public-relations standpoint.
I don't mind closed source proprietary software as much as I dislike closed source proprietary software that will remain that way in perpetuity.
How many people would like to look at the origional PACMAN source? Or at the DR-DOS source? Or at a game AI algorithm. (I once spent several afternoons trying to figure out 'how they did that'. Hard with no source.)
Hell, what wouldn't I do to see the source code for Future Crew's Unreal2 demo!!
That's what makes me sad is that companies hold on to everything, no matter how commercially worthless it might be and never want to give it up. If Apple truly wanted to support the free software/open source community, then why not offer to release their code GPL in 4 or 5 years? Releasing it GPL will keep most of the sharks at bay. Microsoft (for example) won't want to glob chunks of it because they'd be forced to release their software too.
You claim that your anecdote is more 'true' than any number of statistics. Anecdotes lie because people remember the one anecdote and forget the millions of contrary examples.
Hell! I gave references that debunked 3 stupid anecdotes in the parent to your post. If you look around the right places, you can find people who debunk more anecdotes.
How much are land prices? How big of a house could you buy/build out in the middle of nowhere? If you want to live in the city where everyone else lives, you have to pay the prices, or settle with a smaller living area. You have to compete with everyone else who wants to live there. And many of them are people who are also computer science and have fairly signifigant incomes.
How much is a farm in western Montana with lots of land and a big house? How much is a small house close to Silicon Valley? If having a big house is so important, why not move to Montana?
It's a choice that life gives you. Quit bitching that you don't like either option.
Try running some statistics; the poor in the year 2000 are better off than the middle class in 1971. The average work week has gone DOWN by about 2 hours in the last 30 years.
Since 1900, we've gone from 76% of out income being spent on food, clothing, and shelter to 37%, which is why we have *twice* the income to spend on goodies like cars and computers. If you want a workweek half as long, just give up those toys. More good news like this here.
Here's another tidbit. Did you know that bank's create wealth. Say a ``rich person'' puts a billion dollars in the bank. That money gets loaned out to people who buy goods which funds your salary. You, and a million other people put a thousand in the bank. Guess what? There's now two billion in the bank. So what if they have a billion in the bank? You have your thousand in the bank. Who controls more wealth? Your million friends of the big evil rich person? You both have the same wealth; wealth that you wouldn't have had had then not invested it. What does it matter, unless your envious?
That's what annoys me about all this inequitable distribution of wealth crap. If someone has money, they either do one of two things with it. They spend it, funding other people's salaries, or they invest it, where it gets multiplied 10x; with most of that going to other people's pockets.
The federal reserve is the one thing that's kept this economic expansion going so long. Fundamentally, if you make the competetion for labor sufficiently intense, the cost of labor goes up. Businesses then have to raise prices to compensate for the higher labor costs. This raises the cost of living and makes people demand higher wages. IE: inflation. Inflation is hideous, it can wipe out fixed incomes. (If you're retired and have to live on $500/month, having prices double over 5 years is nasty). It forces interest rates up, as banks have to hedge against being paid back in dollars that are worth less. It also makes long-term planning in any contract. If you agree to sell a million playstations for $300 over the next 3 years, and find out that the dollar is worth 1/2 as much near the end; you've wiped out your profit margin. There are places where inflation has been so severe, that prices have doubled every week; people got paid twice a day to help keep up. Either way, lending rates go up discourage lending, and the economy slows down. One's just nastier than the other.
Now, I will agree that a lot of the crap that corporations do should be stopped. I hate corporations railroading over honest people or freedom just because they're bigger. I hate corporations that lie and manipulate people or are hypocritical (like Ben and Jerrys unsafe, dioxin laced ice cream. ). I dislike the WTO or the MPAA.
But on the other side, I dislike the sabotage, terrorism and, most critically, the lies spread by the anti-corporations side.
Like any other human-made system, capitalism and corporatism isn't perfect. The system needs tuning and fixing once in a while. But, overall, it's the best way to run things that we know about. It's not a fundamentally broken system.
Spreading misinformation or lies around just to scare people into joining you is not the way to win. Spreading the truth is. Ultimately, in a democracy, the government answers to the people. If enough people demand something, it will happen.
I don't see too much of a big deal with their algorithm. So, they can do a public-private key cryptosystem faster than other people.
But, you never encrypt real data with RSA. It's slow and stupid. You use RSA to encrypt a session key and then encrypt the data with THAT key. If it's 100 times faster; that only means that it's 100x faster at something that already takes a fraction of a second (250ms on a P2-450). This is important for SSL or some other server which has to authenticate a large number of sessions. The average user won't need to authenticate more than a few sessions an hour.
Being 100x faster might have uses as a smartcard, but I don't immediately see a place where that would actually improve security, compared to current offerings. (If someone steals your smartcard that contains your private keys, you're just as screwed as if it was a plain old credit card.)
Also, RSA has withstood a 20 year test, unlike this new system. It has been standardized into almost every public cryptosystem alive, only the most pressing of reasons could force it out of that hegemony. Finally, RSA is about to leave patent production (3 months).
Who would want to ignore the time-proven RSA to risk an almost brand new cryptosystem. As Bruce Schiener said: There's no money in selling cyphers anymore. (And that goes double as RSA is about to leave patent protection.)
This company seems more interested in offering a product (music encryption) and selling it to management more than selling their cryptosystem. Why not just use standard techniques. Conceptually, they're just PGP'ing the music, why not do that literally?
If they're getting about 40,000 per license per year. (Or about 160,000 a year) What makes you think that suddenly it'll get cheaper.. Would they wan their profit margins to drop by a huge amount? Hell no!
What they'll do is they'll just charge you about 15,000/month. (or XYZ an hour, knowing that you'll use 15,000/XYZ hours in the typical month.)
Copyright is just a law. As such it can be enforced, unenforced, repealed, left alone, or strengthened.
Technological measures which attempt to preserve copyright. Those can be broken.
I seem to remember hearing about all kinds of insane lawsuits and claims from about 20-25 years ago about how the VCR was supposed to kill film and how the TV industry and the movie industry were going to be dead by 1990.
Wow, I am *SO SUPRISED* that they've managed to make an insane bundle of money off of the rental industry. A rental industry that where they make how much profit, and one that they hadn't even imagined back then.
I wouldn't be surprised if a few lost out, but overall, the VCR was an incredible boom to the rental and videotape industry. Something that the extra freedom of the VCR was never expected to supply, but it did.
If you want the truth, I suspect that if they were to lose this case, and DMCA, and maybe even copyright. (as it's currently enforced), that they would be creative once again and figure out how to make even more insane bundles of money. And we'd get some more new art forms.
Of course, they see this as risk. And they're scared of being among the minority that can't adapt.
If I remember right, the IETF *requires* that there be two different implementations in order to ratify the RFC. (And incidently, they strongly frown upon anything based on patented technology.)
The GPL has similar requirements, so I wouldn't worry.
So thus, if a company can lose a million dollars in minute, that must mean that they make around 525 billion dollars a year in revenue.
Um, dudes, these numbers do not add up.
Even if we assume that that is a peak, and the average is 1/10 that.. How many companies on the planet run 50 billion dollars of revenue a year? More importantly, ANY such company would be plenty big enough to afford to avoid these outages.
The only other thing that plays with that quantity of money is banking. (Credit cards/Stock market), neither of which are californian E-businesses.
So, as written, it reads like trash. They're off by 3 orders of magnitude from the believable values.
... doesn't mean that your OEM won't purchase them seperately and install them on your system, or that you yourself can't do that.
Remember, this is just to keep MS from screwing off in the future. So what if your OEM has to go to N+1 companies instead of N. Most big OEM's install a half-doxen commercial packages and a dozen or more demo's. One more or one fewer won't make much of a difference.
You do realize that his ISP is going to probably choke or shoot him with his own gun over the slashdotting their server is about to recieve. Especially as it is in norway. (And given the probably very high per-megabyte bandwidth charge.)
May I suggest a mirror? Quickly
Yes, a standard CFB or stream encryption algorithm has that weakness. Which is why you usually combine it with an (encrypted) CRC or cryptographically sign it. These are protocol-level issues.
And the fix is obvious, you said it yourself. If you don't sign the message in some fashion, you deserve to lose. Signing the message prevents most (all?) of these attacks.
If you do a 'gpg -e', you had better know what the security issues are. Of course, this applies to using ANY encryption software, no matter what settings you use on it. If you don't know your encryption software and what the options mean, you shouldn't be using it.
BTW, just including (and encrypting) the hash of the decrypted message isn't enough to protect against these attacks.
If the message is for multiple recipients, recipient A could decrypt the message, alter it, compute the correct hash for the altered message, and then repackage and send the altered message along to the other recipients who will accept this message as legitimate. To prevent this, the hash of the correct message should be 'signed' in some fashion where only the origional sender can create it. This process describes GPG's 'sign' option, which we know works.
Signing and encryption are orthogonal features and needed in different situations. If I am sending details of an auction to N people, I don't care who reads them, but I do NOT want them to alter the messages sent to the other recipients. If I just encrypt the message but leave it unsigned, noone can read the messgae, but they may alter it. (Admittedly, not very useful for communication, but useful for storage. For example, storing private stuff on a hard drive/floppy.) Finally, I may encrypt and sign the message.
You could consider it a user-interface issue. Maybe GPG should (by default) sign the message whenever the user requests encryption?
[[BTW, if you want to take this conversation to email, I'll be happy to. Unfortunately, my email address no longer works; I can email you.]]