Example time. You have a password, say it's 8 characters long. For the sake of simplicity-of-example, let's say all characters must be alphabetic and upper-case. (Obviously, this is a very insecure system, but it's only for example.)
Let's say you are lame, and choose P-A-S-S-W-O-R-D.
If a cracker attempts to break your password by manually trying each word in a dictionary, this could take a long time, but would certainly succeed. If the same cracker automates the process by trying each word in a text file such as/usr/dict/words, it would take a lot less time, and also be certain to succeed.
The above is known as a "dictionary attack" for obvious reasons. BTW, the more effective variations include subverting such common lame attempts to "improve" ths security of a password by changing letters to numbers (password -> passw0rd) by including these variants in the text file (or a tiny algorithm) so don't rely upon such.
Let's say you instead chose N-X-B-Q-R-K-Y-V as your password.
A dictionary attack would not succeed against such a password. Not only is N-X-B-Q-R-K-Y-V not to be found in Merriam-Webster, but it is not contained in any of the enhanced lists of "words" that are available for password cracking.
Can a cracker defeat such a password? Certainly. Manually, it would require a ridiculous amount of typing (or phenomenal luck.) But how about an automated solution?
It is trivial to write a routine to test A-A-A-A-A-A-A-A, then A-A-A-A-A-A-A-B, then A-A-A-A-A-A-A-C, and so on (which is known as a "brute force" attack, btw.) Writing the routine isn't the issue, running it is. The security of a password is based solely upon *how*long* it takes an attacker to guess it, right?
A brute force attack, by definition, will always succeed, if carried out to completion, since, by definition, it tests every possible combination of characters. A dictionary attack will only succeed against "common" passwords (such as those containing only "words" (or variants) and their combinations (such as TASTY-BUG.)) The advantage of a dictionary attack over a brute force attack is that it takes a lot less time to run, and is likely to be successful much sooner, since most people, sadly enough, are either lazy or uneducated or perhaps both, and choose very insecure passwords/passphrases.
Now, let's leave the world of this example, and enter the world of more security. Passwords would not be limited to just A through Z. We could add 0 through 9. Each additional possible character would increase the number of potential passwords exponentially, since each of the eight positions could now contain that character. We could then remove the case sensitivity requirement and add a through z. We could then add a number of "special characters." To add each of these to the above brute force routine would also be trivial, taking well under a minute. To actually run that routine through to completion however would become more and more time-consuming, to the point of being "unattainable" using (ahem) "today's technology" (especially if we removed the eight-character restriction.) For more on this principle, consult a math text book regarding "permutations.":-)
Password "security" == Estimated-time-to-crack-it. A "good" password will protect longer than the data inside needs protection. "Foever" requires more than just a password/passphrase.
"I couldn't find any leagalease(sp) about HushMail's policy concerning Subpenas(sp) and/or Court Ordered searches."
No legalese, but they did in fact seem to address this in their FAQ (even while making no specific committments.)
From Hushmail's FAQ:
"People in oppressed nations who need to get information out can use HushMail and not be tracked by their governments."
Your reference to the FBI implies you are in the United States. The years I spent in that country certainly show it to be an "oppressed nation," (and becoming more so with the passage of time.)
I agree, chained remailers are the best solution (and yes, of course they are still available.)
Re: free ISP/pay telephones: Public access terminals such as libraries may be a lower-tech solution, especially if the site doesn't log identities with time of use. It still ties the message to a geographic location of course though, but offers the advantage of being a method accessible to greater numbers of users. After all, if "everyone" used anonymous/secure mailing on a routine basis, it would stand out less and would result in a more spook-unfriendly solution, which seems to be your desire. Two ends would be acheived, one, the volume the spooks would need to process (thereby increasing their budgets to the point of accountability,) and two, the "mindshare" in the general populus.
All in all, while Hushmail may be far from a perfect solution, I am glad to see the trend toward increased awareness of privacy issues which it represents. Now what we need to do is educate the masses about the concept that weak privacy is worse than none at all (similar to the argument presented in PGP's docs in early versions.)
BTW, I have not yet examined the source code for Hushmail (but also don't have an account there so can be "forgiven.":) )
"But I see Canadian women with no tops at the beaches so I am a little confused here coming from an American perspective."
Topfree is legal here (stateside) as well. A friend of mine was one of the women arrested in an act of CD to get the sexist law thrown out. Thanks to her and her friends, it is now legal for women to dress the same as men in public places.
BTW, nudity/naturism is not the same issue as censorship, even though censorship is sometimes a factor with nudists/naturists. Censorship is an evil that is much more pervasive than just affecting body parts and their display. Much!
(This is NYS law, btw. YMMV. IANAL. blahblah #include std_disc.h)
glibc 2.1 and ssh ... and violating the law
on
Red Hat 6.0
·
· Score: 1
"someone from ssh emailed me rpms for ssh 1.2.26 for glibc2.1 f you want them, they are mirrored on my comp... ftp://sparky.student.umd.edu/ssh.glibc2.1.rpms/"
So, you are publically posting that you are violating U.S. export laws (as stupid as they may be) by making ssh (crypto software) publically available from a site in the U.S.?
Does this mean that Slashdot is now also guilty of consipiracy to violate these (stupid) laws? UMD's lawyers would certainly find this "interesting."
Phil Zimmerman wasn't ever actually tried; I wonder if they'll consider your case more likely to succeed? Tried or not, his life was certainly majorly disrupted for years.
Please people, consider the denotation of the term, not the connotation. To do less is to show your own ignorance.
Tim O'Reilly basically relies upon the existence of the "free" software community. This is a statement of fact, not of approval or disapproval.
Whether or not you find that concept reprehensible, the definition of the word "parasite" does not change. I think some here would benefit from reading that definition.
Here I am in my trusty lynx, and I'm asked for a password.
That's not the frustrating part. I take a guess at a l/p combo which works, being an old crypto fan.;-)
But then I found that the article can't be read anyway, because it's in some proprietary format. This is ridiculous. Can't Slashdot consider such formats (as well as passwords) when accepting articles for submission?
Slashdot Mirror
Example time. You have a password, say it's 8 characters long. For the sake of simplicity-of-example, let's say all characters must be alphabetic and upper-case. (Obviously, this is a very insecure system, but it's only for example.)
Let's say you are lame, and choose P-A-S-S-W-O-R-D.
If a cracker attempts to break your password by manually trying each word in a dictionary, this could take a long time, but would certainly succeed. If the same cracker automates the process by trying each word in a text file such as /usr/dict/words, it would take a lot less time, and also be certain to succeed.
The above is known as a "dictionary attack" for obvious reasons. BTW, the more effective variations include subverting such common lame attempts to "improve" ths security of a password by changing letters to numbers (password -> passw0rd) by including these variants in the text file (or a tiny algorithm) so don't rely upon such.
Let's say you instead chose N-X-B-Q-R-K-Y-V as your password.
A dictionary attack would not succeed against such a password. Not only is N-X-B-Q-R-K-Y-V not to be found in Merriam-Webster, but it is not contained in any of the enhanced lists of "words" that are available for password cracking.
Can a cracker defeat such a password? Certainly. Manually, it would require a ridiculous amount of typing (or phenomenal luck.) But how about an automated solution?
It is trivial to write a routine to test A-A-A-A-A-A-A-A, then A-A-A-A-A-A-A-B, then A-A-A-A-A-A-A-C, and so on (which is known as a "brute force" attack, btw.) Writing the routine isn't the issue, running it is. The security of a password is based solely upon *how*long* it takes an attacker to guess it, right?
A brute force attack, by definition, will always succeed, if carried out to completion, since, by definition, it tests every possible combination of characters. A dictionary attack will only succeed against "common" passwords (such as those containing only "words" (or variants) and their combinations (such as TASTY-BUG.)) The advantage of a dictionary attack over a brute force attack is that it takes a lot less time to run, and is likely to be successful much sooner, since most people, sadly enough, are either lazy or uneducated or perhaps both, and choose very insecure passwords/passphrases.
Now, let's leave the world of this example, and enter the world of more security. Passwords would not be limited to just A through Z. We could add 0 through 9. Each additional possible character would increase the number of potential passwords exponentially, since each of the eight positions could now contain that character. We could then remove the case sensitivity requirement and add a through z. We could then add a number of "special characters." To add each of these to the above brute force routine would also be trivial, taking well under a minute. To actually run that routine through to completion however would become more and more time-consuming, to the point of being "unattainable" using (ahem) "today's technology" (especially if we removed the eight-character restriction.) For more on this principle, consult a math text book regarding "permutations." :-)
Password "security" == Estimated-time-to-crack-it. A "good" password will protect longer than the data inside needs protection. "Foever" requires more than just a password/passphrase.
No legalese, but they did in fact seem to address this in their FAQ (even while making no specific committments.)
From Hushmail's FAQ:
Your reference to the FBI implies you are in the United States. The years I spent in that country certainly show it to be an "oppressed nation," (and becoming more so with the passage of time.)
I agree, chained remailers are the best solution (and yes, of course they are still available.)
Re: free ISP/pay telephones: Public access terminals such as libraries may be a lower-tech solution, especially if the site doesn't log identities with time of use. It still ties the message to a geographic location of course though, but offers the advantage of being a method accessible to greater numbers of users. After all, if "everyone" used anonymous/secure mailing on a routine basis, it would stand out less and would result in a more spook-unfriendly solution, which seems to be your desire. Two ends would be acheived, one, the volume the spooks would need to process (thereby increasing their budgets to the point of accountability,) and two, the "mindshare" in the general populus.
All in all, while Hushmail may be far from a perfect solution, I am glad to see the trend toward increased awareness of privacy issues which it represents. Now what we need to do is educate the masses about the concept that weak privacy is worse than none at all (similar to the argument presented in PGP's docs in early versions.)
BTW, I have not yet examined the source code for Hushmail (but also don't have an account there so can be "forgiven." :) )
Have others here yet? Is it secure?
Topfree is legal here (stateside) as well. A friend of mine was one of the women arrested in an act of CD to get the sexist law thrown out. Thanks to her and her friends, it is now legal for women to dress the same as men in public places.
BTW, nudity/naturism is not the same issue as censorship, even though censorship is sometimes a factor with nudists/naturists. Censorship is an evil that is much more pervasive than just affecting body parts and their display. Much!
(This is NYS law, btw. YMMV. IANAL. blahblah #include std_disc.h)
So, you are publically posting that you are violating U.S. export laws (as stupid as they may be) by making ssh (crypto software) publically available from a site in the U.S.?
Does this mean that Slashdot is now also guilty of consipiracy to violate these (stupid) laws? UMD's lawyers would certainly find this "interesting."
Phil Zimmerman wasn't ever actually tried; I wonder if they'll consider your case more likely to succeed? Tried or not, his life was certainly majorly disrupted for years.
(The phrase "Stupid Americans" comes to mind.)
Tim O'Reilly basically relies upon the existence of the "free" software community. This is a statement of fact, not of approval or disapproval.
Whether or not you find that concept reprehensible, the definition of the word "parasite" does not change. I think some here would benefit from reading that definition.
Here I am in my trusty lynx, and I'm asked for a password.
That's not the frustrating part. I take a guess at a l/p combo which works, being an old crypto fan. ;-)
But then I found that the article can't be read anyway, because it's in some proprietary format. This is ridiculous. Can't Slashdot consider such formats (as well as passwords) when accepting articles for submission?