Linux looks like something conceived by system administrators for system administrators. Therefore, it is increasingly succesful on the server-side.
On the client side,however, when a linux person says *apps*, he means gcc, emacs, sed, awk, perl. When a user says *apps*, he means the things he uses to manage sales orders, time sheets, bills of material, and other stuff that he knocks in to his RAD-tool developed, mostly client/server database-oriented programs, quite often custom-made or adapted.
When I look at the linux community, I can see a quite a lot of idealistic people, who, unfortunately don't have a clue of why these users don't want linux, not even for free. By far and by large, they prefer to shell out cash, and massively, to Micros~1.
Linux, is nothing more than a total waste of time for these users. Time being money, the cost of using linux is, therefore, much higher than all license fees for buggy M$ gear.
If you don't believe me, ask any business, small or big, to manage sales invoices and VAT returns with emacs; or anything else in the latest Red Hat distribution. I guarantee you that they'll even pay you to throw the CD out of the window, and fast.
I agree with you, if you are the kind of person that can write encryption algorithms of strength comparable to DES and IDEA.
That means, for example, that you understand the DES and IDEA algorithm, and the reasons why they are strong. When you read the DES or IDEA source files, you understand fully why it works that way, and you can change it, and apply new ideas to it. For example, you can create a variation on DESIII and propose DESIV.
If you are that kind of person, you may indeed make your own encryption algorithm. That puts you in the category of specialists, the experts, so to say.
If you are not this level, you may be sure that creating your own encryption scheme is not such a good idea.
Your own encryption scheme will most likely perform worse than the component schemes you have used. It is the same with compression algorithms. Try, for example, to zip or gzip an mpeg-compressed video file. The resulting file will usually be of the same size or bigger than the original file; defeating the object of compressing files. Because the mpeg algorithm heavily takes advantage of the fundamental properties of video data, it is able to compress this kind of data substantially. If you miss the point, and fail to understand the fundamentals of video data, your attempts to compress will not only be much worse than mpeg, you will also be unable to take advantage of the body of research that has been done already on the mpeg algorithm. Therefore, you will not be able to assess the fundamental properties of your algorithm, and the conditions in which it will perform properly or badly.
Even strong encryption algorithms seem to be of varying strength. For example, I see experts writing about weak keys, and other kind of problems that you may encounter; and the strategies that these algorithms implement to alleviate these problems.
If you concoct your own algorithm, you will be unable to assess the conditions in which your own algorithm may seriously lose strength.
Maybe applying 128-bit DES after 128-bit IDEA, reduces the bit strength to an overall 32-bit strength BOGUS algorithm? I don't know. To find out, you need to understand the fundamentals of these algorithms.
The question remains: How good are you at the subject? If you are any less than absolutely excellent, I advise you to stay away from writing your own encryption algorithm and to stop fooling yourself.
There is one serious problem with your approach. You say IDEA and DES are strong encryption systems. Well, why do you know this? Because people have been able to review them prove their strength. If you use a secret algorithm, you will not be able to know if they are actually strong... Therefore, there is no option D.
I am definitely not aware a crypto expert. So this could be the opinion of Joe Everybody, when listening to the STO argument. The STO person says: "I will protect your secrets, but I will not tell you how, because that is a secret." The OSS person says: "I will protect your secrets, and I can mathematically prove that your secrets are safe (within known bounds); and you can let anyone of your own choice verify this." Now it's my choice whose solution I want to buy. Well, I can only say to the STO person: "Why don't you prove mathematically that your solution is safe?" STO requires you to trust the STO person, while OSS requires you to trust mathematics.
Slashdot Mirror
Linux looks like something conceived by system administrators for system administrators. Therefore, it is increasingly succesful on the server-side.
On the client side,however, when a linux person says *apps*, he means gcc, emacs, sed, awk, perl. When a user says *apps*, he means the things he uses to manage sales orders, time sheets, bills of material, and other stuff that he knocks in to his RAD-tool developed, mostly client/server database-oriented programs, quite often custom-made or adapted.
When I look at the linux community, I can see a quite a lot of idealistic people, who, unfortunately don't have a clue of why these users don't want linux, not even for free. By far and by large, they prefer to shell out cash, and massively, to Micros~1.
Linux, is nothing more than a total waste of time for these users. Time being money, the cost of using linux is, therefore, much higher than all license fees for buggy M$ gear.
If you don't believe me, ask any business, small or big, to manage sales invoices and VAT returns with emacs; or anything else in the latest Red Hat distribution. I guarantee you that they'll even pay you to throw the CD out of the window, and fast.
I agree with you, if you are the kind of person that can write encryption algorithms of strength comparable to DES and IDEA.
That means, for example, that you understand the DES and IDEA algorithm, and the reasons why they are strong. When you read the DES or IDEA source files, you understand fully why it works that way, and you can change it, and apply new ideas to it. For example, you can create a variation on DESIII and propose DESIV.
If you are that kind of person, you may indeed make your own encryption algorithm. That puts you in the category of specialists, the experts, so to say.
If you are not this level, you may be sure that creating your own encryption scheme is not such a good idea.
Your own encryption scheme will most likely perform worse than the component schemes you have used. It is the same with compression algorithms. Try, for example, to zip or gzip an mpeg-compressed video file. The resulting file will usually be of the same size or bigger than the original file; defeating the object of compressing files. Because the mpeg algorithm heavily takes advantage of the fundamental properties of video data, it is able to compress this kind of data substantially. If you miss the point, and fail to understand the fundamentals of video data, your attempts to compress will not only be much worse than mpeg, you will also be unable to take advantage of the body of research that has been done already on the mpeg algorithm. Therefore, you will not be able to assess the fundamental properties of your algorithm, and the conditions in which it will perform properly or badly.
Even strong encryption algorithms seem to be of varying strength. For example, I see experts writing about weak keys, and other kind of problems that you may encounter; and the strategies that these algorithms implement to alleviate these problems.
If you concoct your own algorithm, you will be unable to assess the conditions in which your own algorithm may seriously lose strength.
Maybe applying 128-bit DES after 128-bit IDEA, reduces the bit strength to an overall 32-bit strength BOGUS algorithm? I don't know. To find out, you need to understand the fundamentals of these algorithms.
The question remains: How good are you at the subject? If you are any less than absolutely excellent, I advise you to stay away from writing your own encryption algorithm and to stop fooling yourself.
There is one serious problem with your approach. You say IDEA and DES are strong encryption systems. Well, why do you know this? Because people have been able to review them prove their strength. If you use a secret algorithm, you will not be able to know if they are actually strong... Therefore, there is no option D.
I am definitely not aware a crypto expert. So this could be the opinion of Joe Everybody, when listening to the STO argument.
The STO person says: "I will protect your secrets, but I will not tell you how, because that is a secret."
The OSS person says: "I will protect your secrets, and I can mathematically prove that your secrets are safe (within known bounds); and you can let anyone of your own choice verify this."
Now it's my choice whose solution I want to buy. Well, I can only say to the STO person: "Why don't you prove mathematically that your solution is safe?"
STO requires you to trust the STO person, while OSS requires you to trust mathematics.