nobody should ever turn to the heavy factoring algorithms without first exhausting all of the trivial checks.
That depends on wether it is worth the effort. If you know the generating algorithm and it does not have any flaws, it is not worth the effort. But of course since your chance of finding the factorization is so small already, the chance of the factorization being generated by an idiot insisting on using an unsafe approach might very well be larger. (Without proof I will claim that the fraction of idiots in this world is larger than one in a billion.)
With RSA, I thought you wanted "strong primes," not just primes.
In general I don't think that is the case, but some special uses of RSA makes that requirement. The "safe primes" are harder to find because there is not that many of them.
But finding primes is a different task than factoring numbers. The algorithms for finding primes is a lot more efficient than factoring, if they weren't RSA wouldn't make much sense. There is an algorithm that will find a prime and a proof it is a prime, with a minor modification it will produce "safe primes". The proof basically consits of a factorization of p-1 together with a recursive proof that the factors are primes. The reucursion ends when you reach the prime 2, because p-1 will then be 1 and has the empty set as its prime factorization. There is a litle more to the proof than this, but in fact if you are just given a list of all the primes involved in the primality proof you can easilly reconstruct the entire proof.
But usually you don't need a proof, so instead you use a probabilistic algorithm for veryifying primality. You can write a very efficient algorithm that gives sufficiently small probability of ending up with a non-prime. If the probability that one of your "primes" is not a prime is as small as the chance of the attacker finding your prime by his first random guess, that is not a problem.
Can't they get busy with spam legislation instead?
With the amount of spam being send with forged headers through open proxies and open relays, that might well be covered by the law as well. But of course I agree with you that a law dealing with spam and nothing else would be a better effort. As for the IP space problematics, I would be happy to see a law requiring IPv6. I wouldn't want IPv4 to be illegal, it should just require each link being used for IPv4 traffic to support IPv6 as well. It should be starting from the backbone and later the big ISPs must follow. Private users and small ISPs with less than 100 computers should not be covered.
It's only a step backwards if you consider the end of a beta test a step backwards.
If you can go from IPv6 tunneled over IPv4 to a pure IPv6 network, it is a step forwards. But if you are loosing your only way to get IPv6 access and are forced to go back to IPv4 it is a step backwards. Do you believe IPv6 will be widespread enough by the time they start closing the temporary solutions?
But using two shouldn't be any slower than using one. (That is the slowest of the two.) So if they can just find twice as many proxies using two should not slow down anything.
While that is also what I see, I wonder why they never use more than one proxy? Don't they think they could hide their true identity better by using multiple proxies? Anyway this idea of course also can be modified to perform a DoS attack against open proxies. Connect to one and then keep sending more and more CONNECT commands alternating between a few proxies. You will only send each command once, while they will have to travel more and more times between the proxies.
I'd like to have a way to capture the session and start complaining to ISPs.
I wish you good luck. My experience is that most of the people reading the mail in the abuse account at various ISPs does not know an SMTP session when they see one. If I try to explain them that the computer with IP address 172.184.164.229 established an SMTP connection with my computer and tried to use it as relay, they simply asks to see the mail headers. Of course anybody knowing how these things works know that at this point there will not yet be any headers (unless they are forged).
I run a program that just listen on port 25, pretending to be an open relay, and logs all relay tests to a file.
That is also what I do, and your probes sure look familiar. Occationally I actually relay the probes to see what they are actually up to, and then I get loads of spam. I also run another program on ports 1080, 3128, 6588, 8000, and 8080 that pretends to an open proxy which can be used to connect to an open relay.
Next step would be to automatically report received spam to razor.
A honeypot for spam - mentioned here previously, I think - would be one answer.
I have previously mentioned a honeypot here, but not the one you are talking about. I try to receive the spam as fast as possible in the hope that every spam ending up in my honeypot is one less spam to end up elsewhere. But I feel it is getting harder to attract spam. Though I have been working hard to make my honeypot attract lots of spam, and in the process managed to get my IP on OpenRelayCheck, I only got 1.3 million yesterday. My record from october 2002 was 36 million in 4 days.
I believe you must mean spoofed headers, becaue actually spoofing IP through an entire TCP session is too difficult. Now the SMTP server receiving the message with spoofed headers would still be adding an additional header stating the source address of the message. So it is likely that the IP of the computer where the spoofed header was produced will itself also be in the final header.
However if an open proxy is used to connect to the open SMTP relay, the original source can be hidden. The proxy might not know the communication is SMTP, and does not add a header of its own. So the sender can add a header looking like what would have been produced by the proxy if it had been an SMTP server. Now this header can in fact look perfectly valid without any indication it is spoofed, and it would list an incorrect source IP and thus perfectly hiding the identity of the spammer.
In fact gzip is already an optinal part of the HTTP/1.1 specification. So if people use this, there wouldn't be much to win from adding compression above or below this layer.
Splitting this one into two new seperate ones would yield a slower app
It would not necesarilly be slower. If the interface is not completely braindead there would not be need for much communication, and the communication between backend and frontend should certainly be far less than the communication between frontend and X.
The major work to do is not going to be communication between backend and frontend, but rather the management of folders and the actual producing of graphics. Both of which are tasks that has to be done anyway and is not going to be slowed down by the split. In fact since each of the two applications would be smaller, I believe more focus would be given to the performance of either. I can imagine I would personally look into the backend while I'm not that interested in development of the frontend. If they were too integrated with each other, I guess I might give up before even trying to get into it.
I think netscape is a perfect example of an application where the two parts in a single program doesn't give lightning speed. In fact management of folders is horribly slow. Had netscape been split into two applications like my suggestion, I'd have given the backend an amount of work a long time ago. Some of the advantages of the split would be that either part could be replaced with something faster without having to switch the other. I could have replaced the slow backend and kept the UI I liked. Another advantage is that it would be easy to switch GUI. You don't have to care about migrating mails, preferences, profiles, etc. since that would all be in the backend. Just connect an alternate frontend to your backend. You could even switch back and forth as you like.
As long as I have a decent GUI rather then an obtuse CLI
In fact what I would like to see is a mailer split into a CLI backend and a GUI frontend. The CLI backend should do the actual sending and retrieval of messages as well as managing folders. The GUI should be just that, it shouldn't store any data on its own, and all communication it should ever do would be with the backend and the Xserver. Configuration should to as large an extent as possible be stored by the backend, but a few options need to be stored by the GUI most notably the command to invoke the backend. It would be interesting that this command could possibly include a call of ssh to run backend and frontend on different computers (with display possibly being on a third computer). The communicaiton between frontend and backend should be kept as simple as possible. If I execute the backend directly from my commandline, I want a usable interface (at least for the average geek), but I don't want no fancy features like commandline editing or message editing. I want to use the exact same interface being provided as would have been to the frontend, and this should be as easy to use as telnet to an SMTP server would.
Where I live that would just mean it is the shops selling the chips that has to give the warranty. I think most shops couldn't afford to sell the non-warranty version.
By stealing the link and posting it to Freenet, you're cheating
the people who paid a premium for early access.
But most of the software was not written by RedHat, and the option
to make this copy is what the authors wanted. By not informing the
users that they have the right to copy the software, RedHat would
be violating the license, and RedHat would loose the right to sell
the software.
I seem to recall 7.0 and 7.1+ being rather a disaster in terms of library version compatibility
7.0 was a disaster, it was hardly compatible with itself. I had to upgrade some packages (glibc, lam) and downgrade other packages (autofs) to get a working system. And the installer couldn't handle later glibc rpms. So I had to modify the glibc spec file and rebuild the rpm from source. Compiling a kernel and modules was horrible. RedHat had released kernel sources with patches producing incorrect version numbers on the compiled kernel.
A related question: I have the Advanced Server installation CDs.
AFAIK the Advanced Server version contains propriatary software which you cannot copy freely. If you stripped it down you could copy and distribute it as you liked. But such a stripped down version might be nothing more than an enterprise install from the usual RHL CDs.
Anyone know if RH 9.0 will have the required tools already there for 2.[56].xx?
That is indeed a good question. I too had expected RH9.0 to be released after 2.6.0. In fact I have time after time predicted that RH9.0 would come with a 2.6.x kernel. It seems I might have been wrong in my predictions, I don't believe 2.6 is going to be ready before april. When 2.4.0 was released I was still running RH6.0, and I upgraded to a 2.4 kernel quite early. (2.4.2 or 2.4.4 I don't remember exactly.) That actually worked quite well, I didn't have to upgrade any tools to get the new kernel working. (Well rpc.rstatd broke, but I didn't need it anyway.) Right now I'm using RH7.3 and I want to try out 2.5.x, but the fact that RH7.3 doesn't have the necesarry tools is holding me a litle back. I had started thinking it would be nice to see RH8.1 ship with a 2.5.x kernel for the brave, and a 2.4.x kernel by default for the not so brave.
Slashdot Mirror
nobody should ever turn to the heavy factoring algorithms without first exhausting all of the trivial checks.
That depends on wether it is worth the effort. If you know the generating algorithm and it does not have any flaws, it is not worth the effort. But of course since your chance of finding the factorization is so small already, the chance of the factorization being generated by an idiot insisting on using an unsafe approach might very well be larger. (Without proof I will claim that the fraction of idiots in this world is larger than one in a billion.)
With RSA, I thought you wanted "strong primes," not just primes.
In general I don't think that is the case, but some special uses of RSA makes that requirement. The "safe primes" are harder to find because there is not that many of them.
But finding primes is a different task than factoring numbers. The algorithms for finding primes is a lot more efficient than factoring, if they weren't RSA wouldn't make much sense. There is an algorithm that will find a prime and a proof it is a prime, with a minor modification it will produce "safe primes". The proof basically consits of a factorization of p-1 together with a recursive proof that the factors are primes. The reucursion ends when you reach the prime 2, because p-1 will then be 1 and has the empty set as its prime factorization. There is a litle more to the proof than this, but in fact if you are just given a list of all the primes involved in the primality proof you can easilly reconstruct the entire proof.
But usually you don't need a proof, so instead you use a probabilistic algorithm for veryifying primality. You can write a very efficient algorithm that gives sufficiently small probability of ending up with a non-prime. If the probability that one of your "primes" is not a prime is as small as the chance of the attacker finding your prime by his first random guess, that is not a problem.
I mean, it's not like it's trivial to break a composite number of the form p^2-1. :-)
In fact it is trivial, but of course there is no need telling that, because every real geek would have figured that out long time ago.
For those who don't know applied number theory, when factoring a number you first try the small primes
In fact there is much more efficient ways to factor large numbers than by trying to divide with each and every prime.
Can't they get busy with spam legislation instead?
With the amount of spam being send with forged headers through open proxies and open relays, that might well be covered by the law as well. But of course I agree with you that a law dealing with spam and nothing else would be a better effort. As for the IP space problematics, I would be happy to see a law requiring IPv6. I wouldn't want IPv4 to be illegal, it should just require each link being used for IPv4 traffic to support IPv6 as well. It should be starting from the backbone and later the big ISPs must follow. Private users and small ISPs with less than 100 computers should not be covered.
unfortunatly they didnt know you didnt buy it, :-(
When you are in the shop looking on such a piece of plastic, you could take it to a shop assistant and ask if it is also available on CD.
deliberately buy a bunch of Arista's broken CD's and then returning them, because they are broken?
And to add another twist in the meantime you could have copied them, because of course you can circumvent their protection.
It's only a step backwards if you consider the end of a beta test a step backwards.
If you can go from IPv6 tunneled over IPv4 to a pure IPv6 network, it is a step forwards. But if you are loosing your only way to get IPv6 access and are forced to go back to IPv4 it is a step backwards. Do you believe IPv6 will be widespread enough by the time they start closing the temporary solutions?
Because open proxies are usually slow.
But using two shouldn't be any slower than using one. (That is the slowest of the two.) So if they can just find twice as many proxies using two should not slow down anything.
[Client]->[Open Proxy]->[Open Relay]->[Their Mailserver]->[Client]
While that is also what I see, I wonder why they never use more than one proxy? Don't they think they could hide their true identity better by using multiple proxies? Anyway this idea of course also can be modified to perform a DoS attack against open proxies. Connect to one and then keep sending more and more CONNECT commands alternating between a few proxies. You will only send each command once, while they will have to travel more and more times between the proxies.
I'd like to have a way to capture the session and start complaining to ISPs.
I wish you good luck. My experience is that most of the people reading the mail in the abuse account at various ISPs does not know an SMTP session when they see one. If I try to explain them that the computer with IP address 172.184.164.229 established an SMTP connection with my computer and tried to use it as relay, they simply asks to see the mail headers. Of course anybody knowing how these things works know that at this point there will not yet be any headers (unless they are forged).
Do you have the code for it posted anywhere.
Here are my SMTP and proxy honeypots. The programs are not yet complete, and the proxy honeypot in particular needs more features.
I run a program that just listen on port 25, pretending to be an open relay, and logs all relay tests to a file.
That is also what I do, and your probes sure look familiar. Occationally I actually relay the probes to see what they are actually up to, and then I get loads of spam. I also run another program on ports 1080, 3128, 6588, 8000, and 8080 that pretends to an open proxy which can be used to connect to an open relay. Next step would be to automatically report received spam to razor.
A honeypot for spam - mentioned here previously, I think - would be one answer.
I have previously mentioned a honeypot here, but not the one you are talking about. I try to receive the spam as fast as possible in the hope that every spam ending up in my honeypot is one less spam to end up elsewhere. But I feel it is getting harder to attract spam. Though I have been working hard to make my honeypot attract lots of spam, and in the process managed to get my IP on OpenRelayCheck, I only got 1.3 million yesterday. My record from october 2002 was 36 million in 4 days.
spoofed IP
I believe you must mean spoofed headers, becaue actually spoofing IP through an entire TCP session is too difficult. Now the SMTP server receiving the message with spoofed headers would still be adding an additional header stating the source address of the message. So it is likely that the IP of the computer where the spoofed header was produced will itself also be in the final header.
However if an open proxy is used to connect to the open SMTP relay, the original source can be hidden. The proxy might not know the communication is SMTP, and does not add a header of its own. So the sender can add a header looking like what would have been produced by the proxy if it had been an SMTP server. Now this header can in fact look perfectly valid without any indication it is spoofed, and it would list an incorrect source IP and thus perfectly hiding the identity of the spammer.
Don't worry, lzip comments have already been modded up thousands of times.
That's a lot.
http://lzip.sourceforge.net/
Where are my mod points when I read a funny comment like that one?
gzip or equivalent of the HTML
In fact gzip is already an optinal part of the HTTP/1.1 specification. So if people use this, there wouldn't be much to win from adding compression above or below this layer.
Splitting this one into two new seperate ones would yield a slower app
It would not necesarilly be slower. If the interface is not completely braindead there would not be need for much communication, and the communication between backend and frontend should certainly be far less than the communication between frontend and X.
The major work to do is not going to be communication between backend and frontend, but rather the management of folders and the actual producing of graphics. Both of which are tasks that has to be done anyway and is not going to be slowed down by the split. In fact since each of the two applications would be smaller, I believe more focus would be given to the performance of either. I can imagine I would personally look into the backend while I'm not that interested in development of the frontend. If they were too integrated with each other, I guess I might give up before even trying to get into it.
I think netscape is a perfect example of an application where the two parts in a single program doesn't give lightning speed. In fact management of folders is horribly slow. Had netscape been split into two applications like my suggestion, I'd have given the backend an amount of work a long time ago. Some of the advantages of the split would be that either part could be replaced with something faster without having to switch the other. I could have replaced the slow backend and kept the UI I liked. Another advantage is that it would be easy to switch GUI. You don't have to care about migrating mails, preferences, profiles, etc. since that would all be in the backend. Just connect an alternate frontend to your backend. You could even switch back and forth as you like.
As long as I have a decent GUI rather then an obtuse CLI
In fact what I would like to see is a mailer split into a CLI backend and a GUI frontend. The CLI backend should do the actual sending and retrieval of messages as well as managing folders. The GUI should be just that, it shouldn't store any data on its own, and all communication it should ever do would be with the backend and the Xserver. Configuration should to as large an extent as possible be stored by the backend, but a few options need to be stored by the GUI most notably the command to invoke the backend. It would be interesting that this command could possibly include a call of ssh to run backend and frontend on different computers (with display possibly being on a third computer). The communicaiton between frontend and backend should be kept as simple as possible. If I execute the backend directly from my commandline, I want a usable interface (at least for the average geek), but I don't want no fancy features like commandline editing or message editing. I want to use the exact same interface being provided as would have been to the frontend, and this should be as easy to use as telnet to an SMTP server would.
one without warranty
Where I live that would just mean it is the shops selling the chips that has to give the warranty. I think most shops couldn't afford to sell the non-warranty version.
By stealing the link and posting it to Freenet, you're cheating the people who paid a premium for early access.
But most of the software was not written by RedHat, and the option to make this copy is what the authors wanted. By not informing the users that they have the right to copy the software, RedHat would be violating the license, and RedHat would loose the right to sell the software.
I seem to recall 7.0 and 7.1+ being rather a disaster in terms of library version compatibility
7.0 was a disaster, it was hardly compatible with itself. I had to upgrade some packages (glibc, lam) and downgrade other packages (autofs) to get a working system. And the installer couldn't handle later glibc rpms. So I had to modify the glibc spec file and rebuild the rpm from source. Compiling a kernel and modules was horrible. RedHat had released kernel sources with patches producing incorrect version numbers on the compiled kernel.
A related question: I have the Advanced Server installation CDs.
AFAIK the Advanced Server version contains propriatary software which you cannot copy freely. If you stripped it down you could copy and distribute it as you liked. But such a stripped down version might be nothing more than an enterprise install from the usual RHL CDs.
Anyone know if RH 9.0 will have the required tools already there for 2.[56].xx?
That is indeed a good question. I too had expected RH9.0 to be released after 2.6.0. In fact I have time after time predicted that RH9.0 would come with a 2.6.x kernel. It seems I might have been wrong in my predictions, I don't believe 2.6 is going to be ready before april. When 2.4.0 was released I was still running RH6.0, and I upgraded to a 2.4 kernel quite early. (2.4.2 or 2.4.4 I don't remember exactly.) That actually worked quite well, I didn't have to upgrade any tools to get the new kernel working. (Well rpc.rstatd broke, but I didn't need it anyway.) Right now I'm using RH7.3 and I want to try out 2.5.x, but the fact that RH7.3 doesn't have the necesarry tools is holding me a litle back. I had started thinking it would be nice to see RH8.1 ship with a 2.5.x kernel for the brave, and a 2.4.x kernel by default for the not so brave.
couldn't an RHN member technically just leak it without consequence?
He could, and then start praying for the link not to be posted on slashdot for the first week.