This is slashdot... After the horse is dead, we skin it and learn to play drums.
The fear is not bogus data that we have to remove. Rather, the true damage to the integrity of a project comes from bogus data which is indistinguishable from legitimate data. Infinite man-hours of effort cannot correct the damage done by a false-negative in the case of a crypto contest.
It's also a bit optimistic to assume that we'd be able to isolate a committed vandal to the degree required to successfully filter their bogus submissions. An attacker could simply instruct their malicious client to submit work using participant emails randomly taken from stats, easily blending their work in with legitimate work. We can't assume that every attacker will send in their work with a consistent IP or email address.
I'm not making the argument that there's not room for improvement in the current scheme, but it's difficult for us to become too enamored with solutions that only offer a marginal improvement over the current model.
We welcome suggestions and creative remedies from out in the world. If someone has a solution to this quandary, we'd love to implement it. This client trust issue is the holy grail of distributed computing projects, and we hope that it's solvable. I don't think that a lack of access to our buffer file formats is a stumbling block which would prevent a creative and insightful person from devising a solution, however. We don't need to open that source in order to allow someone to solve the issue.
Thanks for your comments and support, and if you do have any proposal which would allow us to trust the work performed by an open source client, we'd love to put it to work.
Yes, you're correct. It's very enlightening that this error existed in one of the few pieces of code which is not present in the public source. It's unfortunate that we're required to obscure the buffer-handling and network protocol aspects of the client for project integrity, and we'd very much prefer it not be that way. It's unlikely that this sort of error would have survived the scrutiny of public source.
For those hwo haven't read it, Jeff Lawson wrote a document which explains why there are still portions of the client which are necessarily closed-source. The link is easy to miss, so I'm assuming those who are raising the issue here on slashdot have simply missed it.
But is that really how it would work? Seems to me that what would happen would be more along the lines of:
They come into the lab, lay down on a table, and go to sleep. They never wake up, they're killed in their sleep.
Later, a new consciousness that believes it is the same person comes to life. From this entity's perspective there would be no percieved discontinuity, but the original person would be just as dead.
It all hinges on what you believe consciousness to be. Is there a spirit "you" that floats in limbo whenever your body is unconscious? Would that spirit consciousness lock onto the machine-based representation of your bits and inhabit it? Or is the copy creating a new consciousness which is wholly independent of the original?
I highly recommend the novel Permutation City by Greg Egan for a very intriguing treatment of this concept.
The concept of virtual clones, no matter what form they assume, opens a great number of ethical and moral issues. What rights should a clone of you have? Is your electronic clone a person while you are still alive, or only after your demise? What if your electronic clone wishes to commit suicide, should it have that right?
I simultaneously find this concept appealing and appalling. It's hard to imagine ever feeling a sense of unity with running code, no matter how closely it mirrors my own brain image. Bottom line, such technology is equivalent to forking another process in unix. Sure, it's a perfect replica, but it's not me. If it walks like a nugget, and talks like a nugget, that's just not sufficient in my eyes.
I can smugly tell myself that such a creation isn't me. After all, wouldn't I continue to retain my own consciousness after the creation of a virutal facsimile of my brain? In Egan's book, it's explained that typically the human is rendered unconsious during the transfer, and never regains consciousness after the transfer.
In effect, people commit suicide to give their "copies" life. On the surface, this is most unsatisfying. To the person involved, how is this any different than simply dying? Is the knowledge that a clone of yourself will continue to persist sufficient?
Without a seamless, unbroken consciousness, can you maintain your identity? I tell myself no, that I am me and I know that because yesterday I was me, and the day before. But am I just tricking myself? For all practical purposes, the hours I spent last night sleeping are a complete cessitation of consciousness. The "me" who woke up this morning isn't in any way linked to the "me" that went to sleep last night, other than the fact that I remember and believe that I am the same consciousness that provided my memories.
I don't claim to have anything close to answers or even a solid theory. I just find the concepts involved very compelling, and I found Egan's book to be a wonderful way of exploring these issues. I highly recommend it.
You're exactly right that security and authentication are some of the most signifigant hurdles between the current state of distributed computing and the future we all envision where no cycles are ever wasted.
Jeff lawson has put together an excellent treatise on the subject, outlining the specific pitfalls and challenges we see in this area. Recommended reading if this subject interests you.
I sincerely doubt that this AC posting is from the real dcypher.net administration, since there's absolutely no factual basis for the statements.
It's unfortunate that dcypher.net chooses to post to slashdot anonymously, making this type of confusion possible.
dcypher.net has never approached distributed.net to discuss cooperating in the CSC contest.
The truth is, that unless dcypher.net releases their code, cooperation is impossible. CSC, like DES, is a bitslicable algorithim. This means that performance improvements can be achieved by overlapping common work for multiple keys.
Since the dcypher.net cores are not available, there is no way for us (distributed.net) to know what real range of keys is represented in one of their blocks.
Even knowing the start block and size of the block, without knowing the details of their core, there's no way to be certain what work is contained in the block.
Even if we did know the full details of their code, if the two codebases take differing approaches to optimization (which is likely), coordination of the keyspace might still prove to be cumbersome and impractical. This is exactly the situation distributed.net faced when we joined forces with EFF's deep crack box during the most-recent DES challenge. Due to the nature of deep crack's bitslicing, we had very little flexibility in subdividing the keyspace. We had very few options for the division that did not involve duplicating work between the distributed.net network and the deep crack boxes.
As you can see here, the bulk of the money will go to a non-profit organization as decided by the distributed.net participants. When we do begin CSC officially, an equivalent voting board will determine the distribution of the prize money as you see here for RC5-64.
As you can see from the public ledger, distributed net has donated almost US$20,000 to selected non-profits such as EFF, FSF, and Project Gutenberg.
What money we have retained has gone directly to supporting the network and buying necessary equipment, and not to staff.
Any of the IRDA-equipped Palm-based units can communicate with a supported (i.e. Nokia, Ericsson) GSM phone for net connectivity on the road. You don't even need a cable, it's all infra-red. With a cable, you can connect them to some other GSM phones (cheaper Nokias and cheaper Ericssons) with the same result -- wireless IP.
Bandwidth isn't great, at 9600 or 14.4k depending on your carrier, but it's more than functional.
Once you're online, you can use ssh or vnc to work on a box. I've had only minor difficulty ssh'ing into a unix box and reading my mail with mutt. I still haven't really seen the usefulness of vnc in a 160x160 window, but it exists and it works.
I'm not quite sure I understand the logic behind the implementation of public keys stored in the slashdot database. I'm not sure it's useful, and perhaps it's even a bit misguided.
There's already a robust and well-supported infrastrucure in place for the network storage and retrieval of PGP/GPG public keys with the existing public keyserver network. The most compelling feature of the keyserver network is that it promotes the web-of-trust model of key trust, allowing users to sign and update trusted keys. This means that the web of trust continues to spread and become ultimately more useful.
The collection of pgp keys is not static data and should not be treated as such. It's a corpulent, growing, interrelated lattice of identies and trust relationships that changes continuously.
A redundant, and static storage of public keys in slashdot is nice and geeky, but not as useful as the public key networks. Key storage will not be beneficial without update capabilities, and I think we all can agree that such function is well beyond the scope of the slashdot engine. There is already a tool in place which is nearly ubiquitious for retreiving public keys on the net -- let's support that and not try to re-invent the wheel.
Rather, I think what would be useful would be a way for slashdot users to store and display their PGP Fingerprint and Key ID. Not the key itself, but simply the unique fingerprint of the key.
This is, I think, much closer to the usage philosophies of the public keyserver system. In fact, with a more rigid entry format (i.e. a field for just the key ID), Rob could even code links to the public keyservers to retreive a users current key in a dynamic manner.
Plus a line for verification of my fingerprint: D50C 1ABB 0D80 CC78 2939 FBE4 B379 C4A5 E43C 5FC3 to add yet another datapoint in people's ability to evaluate whether the key 0xE43C5FC3 really belongs to me.
A much more useful solution, I think. It Still allows slashdot to further promote the use of encryption while not attempting to address problems which are already solved.
Not only is this an insanely good thing to see, but it provides an excellent opportunity to endorse ssh and pgp.
You! Reading this article! Do you use ssh and pgp? If not, why not? You're part of the problem!
If you're not using PGP (yet), drop by http://www.pgpi.com/ and have a look around. http://www.pgpi.com/cgi/download-wizard.cgi will let you easily determine exactly which version of is appropriate for your OS and location. PGP installation is pretty straightforward and there is ample online documentation and tutorials. Not only does PGP become more useful each time a new person starts using it, but the more people we have using PGP routinely the harder it will be to remove our freedom to do so. There's no reason not to use encryption, except for inertia. And I guarantee it's not as hard to install or use as you may be thinking.
Using a nice pgp-aware mailer like mutt is a nice step, too.
If you ARE using telnet or rlogin or ftp, then you have problems now and you don't even realize it. Did you realize that every time you telnet or rlogin or ftp to a remote host that you are transmitting your username and password in clear text? Sniffing passwords is a trivial task, mostly due to the widespread use of insecure protocols such as telnet. ssh is a drop-in, secure alternative for telnet, rlogin, rsh, and ftp. Not only is it secure, but it's easier to use and more featureful as well. On top of security it adds such features as compression, encrypted traffic, encrypted tunnels, and completely automatic and secure X11 forwarding. Plus with RSA Authentication you can eliminate passwords entirely. A cracker can't crack a password that doesn't exist.
Unix users can obtain ssh from ftp://ftp.cs.hut.fi/pub/ssh/ and have it up and running in a matter of minutes. I recommend the 1.2.27 version of ssh (as opposed to the v2 platform) due to licensing difficulties with the v2 platform. Non-unix users have even more options.
There's even an opensource ssh for win32 at http://www.chiark.greenend.o rg.uk/~sgtatham/putty.html although I must admit that I'm not sure I trust an ssh implementation done by a guy who refuses to implement RSA Authentication.
There's never been a better time to be more secure. Simply by installing a couple of easy-to-use applications you could be on your way to a more secure, more private computing experience. Your data is yours, and here are two ways to ensure that it stays that way.
Yeah, I ripped this shamelessly from my.plan -- so sue me, it's still useful information...
You can get full ICQ functionality by running a socks5 proxy. If you're running an icq clone, your mileage will obviously vary, but the mirabilis releases do just fine.
Commercial sites will run into licensing issues, too.
Before the speculation and misinformation get too far out of hand, I'd like to respond to the biggest issues I see raised in the threads here.
1. We *can* detect if a client has or has not performed the work it claimed to perform. Right now we have the ability to pass a known positive key to a client, and we detect very quickly if a client returns a negative result for a known-positive block. Granted, this is not foolproof but it raises the skill required to hack a client much past the insertion of a simple JMP at the start of the keytesting code. Both czcrack and the russian cracked clients failed this test and were spotted in this way. It is not simply their unbelievable keyrates that allows us to tell that something is wrong.
2. The anonymous coward who accuses us of having ego problems is correct that calculating and md5 hash of the decrypted strings is another way of being able to verify that the work was performed as claimed by a client. I don't know who he is, or when he claims to have submitted his code however. *shrug* This concept is not implemented in the current clients, but it's likely to be added soon. Hopefully the situation with the russian vandal will encourage people to upgrade to the client supporting this feature even though their keyrate will fall somewhat as a result. This addition is arguably quite overdue.
3. No, we do not think that we are secure because the source is closed. I'd point to http://www.distributed.net/source/ for the answer to the FAQ "Why is distributed.net closed source?":
"Quite truthfully, releasing binary-only clients still does not completely eliminate the possibility of sabotage, since it is relatively easy for any knowledgeable person to disassemble or patch binaries. This is actually quite a trivial task, so we urge you not to try. Indeed, security through obscurity is actually not secure at all, and we do not claim it to be such."
More on this later, but I'd advise all the people crying for open source to think through their proposal. This is an unfair demand to make unless you have the solution to the client trust issue. Your argument is only compelling if it contains the solution to how an opensource client can be trusted.
4. Full logs are kept showing who tested each block, when they tested it, what client version they used, and what CPU and OS were involved. While the stats database does not retain information at this level, the logfiles do and it is quite simple to "unflag" work performed by known spammer/vandal.
5. Finally, the difficult truth we face is that even if we do implement every last suggestion. If we were to completely swing the pendulum the other direction and check every block twice, calculate an md5 hash of the decrypted texts, and implement every other suggested countermeasure to broken clients it still would not be sufficient to allow the client to be released as open source. It is false logic to equate work verification with results verification. Even if you prove conclusively that the client performed the work, you still cannot trust the answer that the client provides. A client could conceivably perform all the work, and provide the necessary hashes and checksums to prove that, yet always return a negative answer even if the correct key is found.
From looking at the actual work being performed, there is no reason to believe that this person is using a hacked client. We've been in contact with the user and although the details are sketchy his story seems legitimate.
We're still talking with him, but for now the assumption is that this activity is legitimate. Our biggest fear is not that he's compromised the project but that he's using resources he doesn't have permission to use.
For what it's worth, he's not claiming that the blocks are being completed by an E2K. The motto is just his way of showing enthusiasm for the platform. In reality, it's win32 (and a few sparcs) all going through a linux proxy.
It's still way too early to draw any conclusions, but so far there's been nothing to set off any alarms on our end.
move Type: quadoption Default: ask-no Controls whether you will be asked to confirm moving read messages from your spool mailbox to your $mbox mailbox, or as a result of a mbox-hook command.
Witness the scene in episode IV (as one example) when uncle owen and luke are first buying r2d2 and c3po from the jawas.
both r2d2 and the red droid originally purchased are referred to as "r2 units", which would lead one to believe that the r2 is a model or class designation, and d2 is the only component of "r2d2" that's a unique identifier.
Insofar as unix is concerned, you simply cannot beat mutt ( http://www.mutt.org/) for a pgp-aware mailer.
If you're currently using either pine or elm, you're doing yourself a serious disservice not looking at mutt. It's easier, more flexible, and more powerful than any of the alternatives.
PGP support is top-notch and native, for both v2 and v5 pgp. Highly recommended.
I hate to grab such a tiny portion of the announcement for comment, but I believe that the bulk of the announcement stands quite well on its own. This was a wise move, and will likely go a very long way at correcting the handful of problems with slashdot that people seem to be most frustrated by. Congratulations Rob and Jeff, and best wishes for continued success.
I just wanted to take the opportunity to tell everyone how insanely cool Project Gutenberg and Michael Stern Hart are. I had the opportunity to meet Michael in Urbana (Illinois) when we delivered the prize money from rc5-56 back in 1997. It was a very rewarding experience to have had a chance to meet and chat with him over pizza and beers. Project Gutenberg are good people, and well deserving of all our help.
Actually more than money, they're always in need of people with access to scanners and some time on their hands for proofreading. If anyone is feeling like giving back to the net, this is a great way to do so.
We've all said it at one time or another: "You can get anything on the net" and thanks to the efforts of Project Gutenberg, the "everything" covers the great classics of literature and some very enriching texts.
You've never heard distributed.net claim that closed-source provides perfect security. To make such a claim would be foolish and incorrect.
I do think, however, that it's fair to say that until an alternative is devised, that it's a good compromise.
If the lack of an open source distributed computing effort bothers you, then I'd encourage you to research and devise a solution to these concerns. Until you have a solution, then there's little room to complain about the lack of an implementation.
It's depressing that lack of source would give you the motivation to sabotage the work of thousands of people. I would argue that if the lack of an open source disributed computing project offends you to the point of action, then that action should be starting one and not simply attacking a group you disagree with.
Sabotaging a closed-source project like SETI or distributed.net will NOT prove your point. If you truly wish to show that distributed computing can be done in an open source manner, then the only course of action before you is to do just that.
The logical flaw in your argument is that you appear to be implying that if source were available then there would be no motivation for sabotage. This simply isn't true. There will always be malicious people intent on destruction.
For every person skilled enough to hack the binary, there are many more who would love to sabotage a project but cannot because they lack the sufficient skills to do so without source.
By raising the bar for sabotage, you restrict the set of people capable of sabotage to a group who (I would hope) are less likely to feel so motivated.
Nobody is arguing that closed-source is perfect security. If that's the point you wish to prove, then don't bother. We all know that already.
If your argument is that since some people can sabotage the project, we should just give up and allow everyone that opportunity, then I'm afraid I must disagree with that analysis.
If your argument is that it's possible to trust the work done by an open source client, then you're half-way there. All you have to do now is show us all how.
Slashdot Mirror
The fear is not bogus data that we have to remove. Rather, the true damage to the integrity of a project comes from bogus data which is indistinguishable from legitimate data. Infinite man-hours of effort cannot correct the damage done by a false-negative in the case of a crypto contest.
It's also a bit optimistic to assume that we'd be able to isolate a committed vandal to the degree required to successfully filter their bogus submissions. An attacker could simply instruct their malicious client to submit work using participant emails randomly taken from stats, easily blending their work in with legitimate work. We can't assume that every attacker will send in their work with a consistent IP or email address.
I'm not making the argument that there's not room for improvement in the current scheme, but it's difficult for us to become too enamored with solutions that only offer a marginal improvement over the current model.
We welcome suggestions and creative remedies from out in the world. If someone has a solution to this quandary, we'd love to implement it. This client trust issue is the holy grail of distributed computing projects, and we hope that it's solvable. I don't think that a lack of access to our buffer file formats is a stumbling block which would prevent a creative and insightful person from devising a solution, however. We don't need to open that source in order to allow someone to solve the issue.
Thanks for your comments and support, and if you do have any proposal which would allow us to trust the work performed by an open source client, we'd love to put it to work.
For those hwo haven't read it, Jeff Lawson wrote a document which explains why there are still portions of the client which are necessarily closed-source. The link is easy to miss, so I'm assuming those who are raising the issue here on slashdot have simply missed it.
They come into the lab, lay down on a table, and go to sleep. They never wake up, they're killed in their sleep.
Later, a new consciousness that believes it is the same person comes to life. From this entity's perspective there would be no percieved discontinuity, but the original person would be just as dead.
It all hinges on what you believe consciousness to be. Is there a spirit "you" that floats in limbo whenever your body is unconscious? Would that spirit consciousness lock onto the machine-based representation of your bits and inhabit it? Or is the copy creating a new consciousness which is wholly independent of the original?
The concept of virtual clones, no matter what form they assume, opens a great number of ethical and moral issues. What rights should a clone of you have? Is your electronic clone a person while you are still alive, or only after your demise? What if your electronic clone wishes to commit suicide, should it have that right?
I simultaneously find this concept appealing and appalling. It's hard to imagine ever feeling a sense of unity with running code, no matter how closely it mirrors my own brain image. Bottom line, such technology is equivalent to forking another process in unix. Sure, it's a perfect replica, but it's not me. If it walks like a nugget, and talks like a nugget, that's just not sufficient in my eyes.
I can smugly tell myself that such a creation isn't me. After all, wouldn't I continue to retain my own consciousness after the creation of a virutal facsimile of my brain? In Egan's book, it's explained that typically the human is rendered unconsious during the transfer, and never regains consciousness after the transfer.
In effect, people commit suicide to give their "copies" life. On the surface, this is most unsatisfying. To the person involved, how is this any different than simply dying? Is the knowledge that a clone of yourself will continue to persist sufficient?
Without a seamless, unbroken consciousness, can you maintain your identity? I tell myself no, that I am me and I know that because yesterday I was me, and the day before. But am I just tricking myself? For all practical purposes, the hours I spent last night sleeping are a complete cessitation of consciousness. The "me" who woke up this morning isn't in any way linked to the "me" that went to sleep last night, other than the fact that I remember and believe that I am the same consciousness that provided my memories.
I don't claim to have anything close to answers or even a solid theory. I just find the concepts involved very compelling, and I found Egan's book to be a wonderful way of exploring these issues. I highly recommend it.
(Here's a Barnes and Noble link, if amazon.com offends you.)
Jeff lawson has put together an excellent treatise on the subject, outlining the specific pitfalls and challenges we see in this area. Recommended reading if this subject interests you.
It's unfortunate that dcypher.net chooses to post to slashdot anonymously, making this type of confusion possible.
dcypher.net has never approached distributed.net to discuss cooperating in the CSC contest.
The truth is, that unless dcypher.net releases their code, cooperation is impossible. CSC, like DES, is a bitslicable algorithim. This means that performance improvements can be achieved by overlapping common work for multiple keys.
Since the dcypher.net cores are not available, there is no way for us (distributed.net) to know what real range of keys is represented in one of their blocks.
Even knowing the start block and size of the block, without knowing the details of their core, there's no way to be certain what work is contained in the block.
Even if we did know the full details of their code, if the two codebases take differing approaches to optimization (which is likely), coordination of the keyspace might still prove to be cumbersome and impractical. This is exactly the situation distributed.net faced when we joined forces with EFF's deep crack box during the most-recent DES challenge. Due to the nature of deep crack's bitslicing, we had very little flexibility in subdividing the keyspace. We had very few options for the division that did not involve duplicating work between the distributed.net network and the deep crack boxes.
As you can see from the public ledger, distributed net has donated almost US$20,000 to selected non-profits such as EFF, FSF, and Project Gutenberg.
What money we have retained has gone directly to supporting the network and buying necessary equipment, and not to staff.
Bandwidth isn't great, at 9600 or 14.4k depending on your carrier, but it's more than functional.
Once you're online, you can use ssh or vnc to work on a box. I've had only minor difficulty ssh'ing into a unix box and reading my mail with mutt. I still haven't really seen the usefulness of vnc in a 160x160 window, but it exists and it works.
Useful links:
Wireless Connections for Nokia 51x0/61x0
Top Gun ssh for PalmOS
VNC
And of course, ssh, because only morons use telnetd
You should be using ssh 1.2.27, not telnet.
There's already a robust and well-supported infrastrucure in place for the network storage and retrieval of PGP/GPG public keys with the existing public keyserver network. The most compelling feature of the keyserver network is that it promotes the web-of-trust model of key trust, allowing users to sign and update trusted keys. This means that the web of trust continues to spread and become ultimately more useful.
The collection of pgp keys is not static data and should not be treated as such. It's a corpulent, growing, interrelated lattice of identies and trust relationships that changes continuously.
A redundant, and static storage of public keys in slashdot is nice and geeky, but not as useful as the public key networks. Key storage will not be beneficial without update capabilities, and I think we all can agree that such function is well beyond the scope of the slashdot engine. There is already a tool in place which is nearly ubiquitious for retreiving public keys on the net -- let's support that and not try to re-invent the wheel.
Rather, I think what would be useful would be a way for slashdot users to store and display their PGP Fingerprint and Key ID. Not the key itself, but simply the unique fingerprint of the key.
This is, I think, much closer to the usage philosophies of the public keyserver system. In fact, with a more rigid entry format (i.e. a field for just the key ID), Rob could even code links to the public keyservers to retreive a users current key in a dynamic manner.
For instance, if there were a place in my profile to enter my key ID: 0xE43C5FC3 there could easily be a link in the header above my comments linking to a keyserver using the url: http://pgp5.ai.mit .edu:11371/pks/lookup?op=get&search=0xE43C5FC3
Plus a line for verification of my fingerprint:
D50C 1ABB 0D80 CC78 2939 FBE4 B379 C4A5 E43C 5FC3
to add yet another datapoint in people's ability to evaluate whether the key 0xE43C5FC3 really belongs to me.
A much more useful solution, I think. It Still allows slashdot to further promote the use of encryption while not attempting to address problems which are already solved.
# tar xzvf ssh-1.2.27.tar.gz ./configure
# cd ssh-1.2.27
#
# make
# make install
http://194.234.236.31/ and http://194.234.236.31/cgi/download-wi zard.cgi
You! Reading this article! Do you use ssh and pgp? If not, why not? You're part of the problem!
If you're not using PGP (yet), drop by http://www.pgpi.com/ and have a look around. http://www.pgpi.com/cgi/download-wizard .cgi will let you easily determine exactly which version of is appropriate for your OS and location. PGP installation is pretty straightforward and there is ample online documentation and tutorials. Not only does PGP become more useful each time a new person starts using it, but the more people we have using PGP routinely the harder it will be to remove our freedom to do so. There's no reason not to use encryption, except for inertia. And I guarantee it's not as hard to install or use as you may be thinking.
Using a nice pgp-aware mailer like mutt is a nice step, too.
If you ARE using telnet or rlogin or ftp, then you have problems now and you don't even realize it. Did you realize that every time you telnet or rlogin or ftp to a remote host that you are transmitting your username and password in clear text? Sniffing passwords is a trivial task, mostly due to the widespread use of insecure protocols such as telnet. ssh is a drop-in, secure alternative for telnet, rlogin, rsh, and ftp. Not only is it secure, but it's easier to use and more featureful as well. On top of security it adds such features as compression, encrypted traffic, encrypted tunnels, and completely automatic and secure X11 forwarding. Plus with RSA Authentication you can eliminate passwords entirely. A cracker can't crack a password that doesn't exist.
Unix users can obtain ssh from ftp://ftp.cs.hut.fi/pub/ssh/ and have it up and running in a matter of minutes. I recommend the 1.2.27 version of ssh (as opposed to the v2 platform) due to licensing difficulties with the v2 platform. Non-unix users have even more options.
For Win32 there's SecureCRT (http://www.vandyke.com) which is an excellent, albeit commercial solution. There's also a very nice, free implementation of ssh which works with Tera Term. You can grab it from http://hp.vector.co.jp/author s/VA002416/teraterm.html
There's even an opensource ssh for win32 at http://www.chiark.greenend.o rg.uk/~sgtatham/putty.html although I must admit that I'm not sure I trust an ssh implementation done by a guy who refuses to implement RSA Authentication.
For Macintosh, I understand that there's a nice plug-in for NiftyTelnet at http://www.lysator.liu.se/~jon asw/freeware/niftyssh/ although I've not used it.
There's never been a better time to be more secure. Simply by installing a couple of easy-to-use applications you could be on your way to a more secure, more private computing experience. Your data is yours, and here are two ways to ensure that it stays that way.
Yeah, I ripped this shamelessly from my .plan -- so sue me, it's still useful information...
Just a clever reminder that many IPOs aren't licenses to print money, although most of them are anticipated to be just that.
Commercial sites will run into licensing issues, too.
http://www.socks.nec.com
FreeBSD users see
Before the speculation and misinformation get too far out of hand, I'd like to respond to the biggest issues I see raised in the threads here.
1. We *can* detect if a client has or has not performed the work it claimed
to perform. Right now we have the ability to pass a known positive key to
a client, and we detect very quickly if a client returns a negative result
for a known-positive block. Granted, this is not foolproof but it raises the
skill required to hack a client much past the insertion of a simple JMP at
the start of the keytesting code. Both czcrack and the russian cracked clients
failed this test and were spotted in this way. It is not simply their
unbelievable keyrates that allows us to tell that something is wrong.
2. The anonymous coward who accuses us of having ego problems is correct that
calculating and md5 hash of the decrypted strings is another way of being able
to verify that the work was performed as claimed by a client. I don't know
who he is, or when he claims to have submitted his code however. *shrug*
This concept is not implemented in the current clients, but it's likely to be
added soon. Hopefully the situation with the russian vandal will encourage
people to upgrade to the client supporting this feature even though their
keyrate will fall somewhat as a result. This addition is arguably quite
overdue.
3. No, we do not think that we are secure because the source is closed. I'd
point to http://www.distributed.net/source/ for the answer to the FAQ "Why is
distributed.net closed source?":
"Quite truthfully, releasing binary-only clients still does not completely
eliminate the possibility of sabotage, since it is relatively easy for any
knowledgeable person to disassemble or patch binaries. This is actually quite a
trivial task, so we urge you not to try. Indeed, security through obscurity is
actually not secure at all, and we do not claim it to be such."
More on this later, but I'd advise all the people crying for open source to
think through their proposal. This is an unfair demand to make unless you
have the solution to the client trust issue. Your argument is only compelling
if it contains the solution to how an opensource client can be trusted.
4. Full logs are kept showing who tested each block, when they tested it, what client version they used, and what CPU and OS were involved. While the stats database does not retain information at this level, the logfiles do and it is quite simple to "unflag" work performed by known spammer/vandal.
5. Finally, the difficult truth we face is that even if we do implement
every last suggestion. If we were to completely swing the pendulum the other
direction and check every block twice, calculate an md5 hash of the decrypted
texts, and implement every other suggested countermeasure to broken clients
it still would not be sufficient to allow the client to be released as
open source. It is false logic to equate work verification with results
verification. Even if you prove conclusively that the client performed
the work, you still cannot trust the answer that the client provides.
A client could conceivably perform all the work, and provide the necessary
hashes and checksums to prove that, yet always return a negative answer
even if the correct key is found.
From looking at the actual work being performed, there is no reason to believe that this person is using a hacked client. We've been in contact with the user and although the details are sketchy his story seems legitimate.
We're still talking with him, but for now the assumption is that this activity is legitimate. Our biggest fear is not that he's compromised the project but that he's using resources he doesn't have permission to use.
For what it's worth, he's not claiming that the blocks are being completed by an E2K. The motto is just his way of showing enthusiasm for the platform. In reality, it's win32 (and a few sparcs) all going through a linux proxy.
It's still way too early to draw any conclusions, but so far there's been nothing to set off any alarms on our end.
http://www.mutt.org/doc/manual/ma nual-6.html#move
move
Type: quadoption
Default: ask-no
Controls whether you will be asked to confirm moving read messages from your spool mailbox to your $mbox mailbox, or as a result of a mbox-hook command.
"set move=no" will do exactly what you want.
You don't even need to delve into the source. Here is a sample muttrc which will redefine all the key bindings to their pine equivalents.
Witness the scene in episode IV (as one example) when uncle owen and luke are first buying r2d2 and c3po from the jawas.
both r2d2 and the red droid originally purchased are referred to as "r2 units", which would lead one to believe that the r2 is a model or class designation, and d2 is the only component of "r2d2" that's a unique identifier.
Insofar as unix is concerned, you simply cannot beat mutt ( http://www.mutt.org/) for a pgp-aware mailer.
If you're currently using either pine or elm, you're doing yourself a serious disservice not looking at mutt. It's easier, more flexible, and more powerful than any of the alternatives.
PGP support is top-notch and native, for both v2 and v5 pgp. Highly recommended.
I hate to grab such a tiny portion of the announcement for comment, but I believe that the bulk of the announcement stands quite well on its own. This was a wise move, and will likely go a very long way at correcting the handful of problems with slashdot that people seem to be most frustrated by. Congratulations Rob and Jeff, and best wishes for continued success.
I just wanted to take the opportunity to tell everyone how insanely cool Project Gutenberg and Michael Stern Hart are. I had the opportunity to meet Michael in Urbana (Illinois) when we delivered the prize money from rc5-56 back in 1997. It was a very rewarding experience to have had a chance to meet and chat with him over pizza and beers. Project Gutenberg are good people, and well deserving of all our help.
Actually more than money, they're always in need of people with access to scanners and some time on their hands for proofreading. If anyone is feeling like giving back to the net, this is a great way to do so.
We've all said it at one time or another: "You can get anything on the net" and thanks to the efforts of Project Gutenberg, the "everything" covers the great classics of literature and some very enriching texts.
Wish I could pre-moderate this as flamebait.
Sorry, just couldn't resist.
Please don't put words in our mouths.
You've never heard distributed.net claim that closed-source provides perfect security. To make such a claim would be foolish and incorrect.
I do think, however, that it's fair to say that until an alternative is devised, that it's a good compromise.
If the lack of an open source distributed computing effort bothers you, then I'd encourage you to research and devise a solution to these concerns. Until you have a solution, then there's little room to complain about the lack of an implementation.
It's depressing that lack of source would give you the motivation to sabotage the work of thousands of people. I would argue that if the lack of an open source disributed computing project offends you to the point of action, then that action should be starting one and not simply attacking a group you disagree with.
Sabotaging a closed-source project like SETI or distributed.net will NOT prove your point. If you truly wish to show that distributed computing can be done in an open source manner, then the only course of action before you is to do just that.
The logical flaw in your argument is that you appear to be implying that if source were available then there would be no motivation for sabotage. This simply isn't true. There will always be malicious people intent on destruction.
For every person skilled enough to hack the binary, there are many more who would love to sabotage a project but cannot because they lack the sufficient skills to do so without source.
By raising the bar for sabotage, you restrict the set of people capable of sabotage to a group who (I would hope) are less likely to feel so motivated.
Nobody is arguing that closed-source is perfect security. If that's the point you wish to prove, then don't bother. We all know that already.
If your argument is that since some people can sabotage the project, we should just give up and allow everyone that opportunity, then I'm afraid I must disagree with that analysis.
If your argument is that it's possible to trust the work done by an open source client, then you're half-way there. All you have to do now is show us all how.