Indeed, there is no "overwrite all readable blocks and spare the unreadable blocks" program, is there? "dd" would only need minor modifications to do that.
The 'dd' option 'conv=noerror' might do it, although the man page suggests that it is used to skip over read errors, I suspect it will also ignore write errors.
It's a shame that there isn't a Linux program that does something similar.
Others have mentioned specific utilities, but with almost any bootable CDROM Linux variant you can wipe a disk pretty throroughly as follows. This is for when you're retiring a system and want to overwrite the entire disk, not scrubbing free space on a live system:
for i in `seq 1 10` do dd if=/dev/urandom of=/dev/hda done
This will write pseudo-random data over the hard drive 10 times. To make it happen more times, change '10' to 'N' where N is larger than 10 in the 'seq' command. To use true random data rather than pseudo-random, use/dev/random, but realize it may hang waiting to gain more entropy and, for this use, I'm not sure there is any real advantage in true randomness.
You can also use 'dd' on a live system, writing to a file instead of a partition, and fill up free space on that partition (then delete the file!). This will overwrite data from deleted files, but will not get slack space, which is the particular advantage of using the 'wipe' tool that someone else mentioned. Also, remember only root can fill the filesystem; everyone else gets cut off with some small % free.
Windows users should also realize that with Windows 2000 (um, SP3 I think) and above the EFS tool 'cipher' will allow you to wipe unused disk space, so that you can proactively make sure that deleted files aren't hanging around on disk. This is useful if you want to make sure old files don't accumulate on the hard drive of a working system, especially physically insecure laptops etc. etc. It presumes the NTFS file system, of course.
cipher/w:c:
will overwrite the free space on the C: partition with 0s, then 1s, then random data. I'm not sure if it gets slack space.
Of course, a very slim possibility remains that sophisticated and expensive physical analysis will still recover data from disks wiped in this manner. Unless you've seriously honked off the NSA, however, these should provide sufficient protection for most uses.
If it is password-protected, it means I have to pass password to decrypt my private key with my email which will make it even more confusing, unsecure and most of email clients not compatible.
Not neccessarily. If STARTTLS + SMTP AUTH was the submission protocol, and the AUTH password was used to decrypt the private key, then you've still got user password control with great email client compatibility.
If it is not - it means someone will encrypt and sign my email on my behalf. In many jurisdictions the digital sig is just like sig on paper. If something else but me signs my data - it blows the whole PKI thing out of the water.
But PKI isn't necessary for legally binding digital signatures in many jurisdictions, so this setup is no weaker than current practice. See Doherty v. RMV, where email marked "This is the report of TROOPER THOMAS KELLEY and was made by TROOPER THOMAS KELLEY under the penalties of perjury. Data entry and transmission were done by KELLY, THOMAS by or at the direction of TROOPER THOMAS KELLEY" was deemed to be a valid signature by the court. No PKI required.
You take the (oh... forgive me) Lotus Notes approach (I'm *not* a fan, but I understand this aspect of the software): it can be setup so the encrypt and decrypt happens transparently to the user between Lotus Notes servers. If you had something along this level between mail servers, then you might start getting into secure transmission of e-mail.
Yes, we call that STARTTLS in the SMTP world. However, that only provides hop-to-hop encryption, not end-to-end. There is no guarantee that each link in the delivery chain will employ encryption. While I'm not familiar with Lotus Notes, I daresay that once it forwards to SMTP it either stops encryption there, or uses STARTTLS for the first hop out with no control after that.
If someone really needs to use PGP security, which is almost unbreakable, they would figure out how to use existing programs.
Ah, but what if they don't need to, but are required by regulation to?
You can bet that John/Jane Doe, who work at your health insurance company / bank / credit card company / e-commerce site don't feel the "need" to use PGP security, because hey, what does your personal information mean to them? Also, not being geeks or security wonks, many of these people are not going to "figure out how to use existing programs." However, they're handling your data. In some cases, the Government has regulated that they must protect the data. Encryption is an efficient and sometimes necessary form of protection... but isn't easy enough to ensure people use today.
This looks like it doesn't accomplish significantly more than the existing SMTP option STARTTLS.
It does. The classic problem with STARTTLS is that it isn't end-to-end encryption - there is no guarantee that your mail server will use STARTTLS for the next hop, or that the recipient will use (SIMAP, POP+STARTTLS, whatever) to download it from their mail server.
With this solution, the first hop is encrypted with SSL (just like STARTTLS) and after that the message itself is encrypted/signed, and any MTA hops beyond that don't need to be encrypted if the message is.
But you're still not secure between the client and the proxy as far as network transport is concerned...
Sure you are. SSL, as described in the posted links.
A more pertinent question might be, what about all those private keys sitting on the server? How do you get the signing and non-repudiation advantages of PGP if the user doesn't hold the key, but rather depend on a shared server?
In the end, given the usability issues that even security professionals have with PGP, this can only help spread encryption down to some end-user masses. And that's a good thing, as long as the certificate store isn't trivially crackable or foolable.
Do a Google search on solar cell window and you quickly realize that this is an old idea.
Absolutely. Very old idea. However, do a Google search on commercially available products in this space and you quickly realize that this an old idea that hasn't really been commercially developed. You could chalk that up to the dangerous imprecations of the 'old girls' network, but I think it's just a problem that hasn't been solved yet in a cost-effective manner. Which is why money is still being spent looking into it.
But what's important this time I guess is that it's a woman who "discovered" the idea.
I don't see why you would conclude that. I can think of two reasons this article might be important:
This design appears to have commercial viability. 50% efficiency, 25 cents per cell? Depending on how many cells are required per window, that could be remarkably viable on the market.
The university/sponsors/whatever made a press release or an article placement, which sounds really neat but is effectively vapor until a product ships. This happens quite often with Solar technologies (and, of course, other things). However, people like to post these things, and Solar windows make a nice follow up to the recent power grid issues.
Note that those two options are not mutually exclusive.
If they can come out with a hybrid SUV with 4-wheel drive and good cargo capacity and power to carry the weight of my musical gear, then believe me, I will be one of the first in line to check it out!
Yeah but how much would they weigh at sea level in metric elephants?
African or European?
James Bond? Dirk Pitt!
on
Bay of Souls
·
· Score: 1
...James Bond adventure in which a sexual tigress seduces Bond into a Caribbean political crisis, requiring a nighttime scuba-dive into a sunken treasure-wreck, and then a voodoo ceremony that reads like a nightmare acid trip.
This solution will only work if it is exclusive of existing practice.
That was their first mistake.
Had they designed this as an SMTP Service Extension so that it could be integrated into existing mail servers, it would stand a chance of eventually being adopted. Sites could accept both, perhaps treating AMTP messages as SPAM-free for filtering purposes, until use was widespread enough to turn away messages that didn't have AMTP verification.
But to make an all-or-nothing stand will just doom the project. Sure, some rare people will want to run AMTP for cred and SMTP for the rest of their mail. Everyone else will wait for sendmail to create a service extension to do the same thing without having to rip out the plumbing.
While I have heard that other, lesser states have higher mountains... none of them have the same fame as Mt. Washington, except perhaps McKinley in Alaska. (Rushmore, of course, is not famous as a mountain per se...)
Of those that are famous, I daresay Mt. Washington is the only one with an auto road leading up to the peak. Insofar as they were on Segways, that kind of limited their choices.
So tell me? What did Stallman do to pay the rent and eat before he became a MacArthur fellow?
Dame Rumor says he implemented. I recall hearing back in '94-'96 or so that he commanded a very hefty hourly rate for consulting, mostly extending emacs and the like for companies that wanted useful tools.
Of course, I understand a lot of that went straight back into FSF. I did confuse him for a bum (sorry, but that's truth) when I first saw him, so he clearly wasn't spending much on himself.
That's the rumor. How true it is, I have no idea...
I did, and if you would like to do so, you should pay particular attention to section 4.3, which outlines which codes may be used when:
CONNECTION ESTABLISHMENT S: 220 F: 421
The section you quote, "Appendix E - Theory of Reply Codes" is designed to explain how to interpret codes, not to suggest that every code may be used in response to every command.
As I posted in another reply, if AOL chose to reject the RCPT command with a 5yz error, then 821-compliant mailers would know it was rejected and bounce it. They have chosen a less compatible method that allows them to appear less culpable.
...AOL 220- may no longer accept connections from IP addresses which 220 have no reverse-DNS (PTR record) assigned
I would be interested to know if your reverse DNS is working (e.g., if your IP is 1.2.3.4, then
% host 1.2.3.4
Should either return a name or that no name is found. If no name is found, then presumably your problem is that you are not on a so-called "dynamic" block, but that your RDNS isn't working. Different codes for different issues.
You're citing an out-of-date RFC. 821 was superseded by RFC 2821, which makes it clear that 554 is a valid connection-opening response...
You make an excellent point. Unfortunately, RFC 821 is not yet officially superceded by 2821, as of 8/25/03 (see Official Internet Protocol Standards - note that 821 is listed as STD #10, and 2821 is listed in the table labeled "Draft Standards"). RFC 2821 compliance is still uneven among the various MTAs.
If AOL wanted to lower their load, then they should happily HELO the competi^H^H^H^H^H blacklisted cable modem ranges, and then reject the RCPT command with a hearty 550, which is not only 821-compliant but almost every mailer on earth will recognize as a permanent refusal. The mail bounces, the bounce makes it clear AOL did it, no timeout is incurred and no retries waste client or server cycles.
For AOL, it isn't about lowering their load or doing the right thing. It's about screwing their competitors, and (more importantly to me), their competitors' customers.
Among other petty annoyances, AOL is incorrectly refusing connections from blacklisted hosts, as follows:
$ telnet mailin-01.mx.aol.com 25 554- (RTR:BB) The IP address you are using to connect to AOL is a dynamic 554- (residential) IP address. AOL will not accept future e-mail transactions 554- from this IP address until your ISP removes this IP address from its list 554- of dynamic (residential) IP addresses. For additional information, 554 please visit http://postmaster.info.aol.com.
According to RFC 821 (sections 4.3 and 4.2.2), the server can respond to new connections in with a 220 ("let's dance") or a 421 ("go away, I have a headache") response. Not a 554 ("you're lousy in bed") code. Among other things, the manner in which they reject mail from residential IPs causes it to languish in the queue, rather than bouncing as it should if they intend to permanently refuse delivery.
I'm sure they do this intentionally so that it will look like your mail server is at fault ("sorry, couldn't get through") rather than theirs ("buzz off, I don't like your IP address").
So where's the third DVD movie in a two movie DVD release? D'OH! Oh wait, it hasn't come out yet...
*hem, hem*
The article is, in fact, referring to "theatrical release." The idea is that, in the same month, the extended versions of the first two movies will be available in limited theaters, so that one might properly prep for the release of the third movie (also in theaters).
Slashdot Mirror
Is it perhaps time for a code rewrite in Sendmail...
IIRC 8.9 was the code rewrite.
maybe a quiet, dignified retirement?
At this point, I'd settle for a noisy drag-it-out-back-and-shoot-it.
Secure alternatives exist - Postfix, qmail. Other alternatives with better security track records and lower target profiles exist - Exim, Courier.
Time and past time to move. How many holes is it going to take?
Indeed, there is no "overwrite all readable blocks and spare the unreadable blocks" program, is there? "dd" would only need minor modifications to do that.
The 'dd' option 'conv=noerror' might do it, although the man page suggests that it is used to skip over read errors, I suspect it will also ignore write errors.
It's a shame that there isn't a Linux program that does something similar.
Others have mentioned specific utilities, but with almost any bootable CDROM Linux variant you can wipe a disk pretty throroughly as follows. This is for when you're retiring a system and want to overwrite the entire disk, not scrubbing free space on a live system:
This will write pseudo-random data over the hard drive 10 times. To make it happen more times, change '10' to 'N' where N is larger than 10 in the 'seq' command. To use true random data rather than pseudo-random, use /dev/random, but realize it may hang waiting to gain more entropy and, for this use, I'm not sure there is any real advantage in true randomness.
You can also use 'dd' on a live system, writing to a file instead of a partition, and fill up free space on that partition (then delete the file!). This will overwrite data from deleted files, but will not get slack space, which is the particular advantage of using the 'wipe' tool that someone else mentioned. Also, remember only root can fill the filesystem; everyone else gets cut off with some small % free.
Windows users should also realize that with Windows 2000 (um, SP3 I think) and above the EFS tool 'cipher' will allow you to wipe unused disk space, so that you can proactively make sure that deleted files aren't hanging around on disk. This is useful if you want to make sure old files don't accumulate on the hard drive of a working system, especially physically insecure laptops etc. etc. It presumes the NTFS file system, of course.
will overwrite the free space on the C: partition with 0s, then 1s, then random data. I'm not sure if it gets slack space.
Of course, a very slim possibility remains that sophisticated and expensive physical analysis will still recover data from disks wiped in this manner. Unless you've seriously honked off the NSA, however, these should provide sufficient protection for most uses.
If it is password-protected, it means I have to pass password to decrypt my private key with my email which will make it even more confusing, unsecure and most of email clients not compatible.
Not neccessarily. If STARTTLS + SMTP AUTH was the submission protocol, and the AUTH password was used to decrypt the private key, then you've still got user password control with great email client compatibility.
If it is not - it means someone will encrypt and sign my email on my behalf. In many jurisdictions the digital sig is just like sig on paper. If something else but me signs my data - it blows the whole PKI thing out of the water.
But PKI isn't necessary for legally binding digital signatures in many jurisdictions, so this setup is no weaker than current practice. See Doherty v. RMV, where email marked "This is the report of TROOPER THOMAS KELLEY and was made by TROOPER THOMAS KELLEY under the penalties of perjury. Data entry and transmission were done by KELLY, THOMAS by or at the direction of TROOPER THOMAS KELLEY" was deemed to be a valid signature by the court. No PKI required.
You take the (oh... forgive me) Lotus Notes approach (I'm *not* a fan, but I understand this aspect of the software): it can be setup so the encrypt and decrypt happens transparently to the user between Lotus Notes servers. If you had something along this level between mail servers, then you might start getting into secure transmission of e-mail.
Yes, we call that STARTTLS in the SMTP world. However, that only provides hop-to-hop encryption, not end-to-end. There is no guarantee that each link in the delivery chain will employ encryption. While I'm not familiar with Lotus Notes, I daresay that once it forwards to SMTP it either stops encryption there, or uses STARTTLS for the first hop out with no control after that.
If someone really needs to use PGP security, which is almost unbreakable, they would figure out how to use existing programs.
Ah, but what if they don't need to, but are required by regulation to?
You can bet that John/Jane Doe, who work at your health insurance company / bank / credit card company / e-commerce site don't feel the "need" to use PGP security, because hey, what does your personal information mean to them? Also, not being geeks or security wonks, many of these people are not going to "figure out how to use existing programs." However, they're handling your data. In some cases, the Government has regulated that they must protect the data. Encryption is an efficient and sometimes necessary form of protection... but isn't easy enough to ensure people use today.
This looks like it doesn't accomplish significantly more than the existing SMTP option STARTTLS.
It does. The classic problem with STARTTLS is that it isn't end-to-end encryption - there is no guarantee that your mail server will use STARTTLS for the next hop, or that the recipient will use (SIMAP, POP+STARTTLS, whatever) to download it from their mail server.
With this solution, the first hop is encrypted with SSL (just like STARTTLS) and after that the message itself is encrypted/signed, and any MTA hops beyond that don't need to be encrypted if the message is.
But you're still not secure between the client and the proxy as far as network transport is concerned...
Sure you are. SSL, as described in the posted links.
A more pertinent question might be, what about all those private keys sitting on the server? How do you get the signing and non-repudiation advantages of PGP if the user doesn't hold the key, but rather depend on a shared server?
In the end, given the usability issues that even security professionals have with PGP, this can only help spread encryption down to some end-user masses. And that's a good thing, as long as the certificate store isn't trivially crackable or foolable.
Do a Google search on solar cell window and you quickly realize that this is an old idea.
Absolutely. Very old idea. However, do a Google search on commercially available products in this space and you quickly realize that this an old idea that hasn't really been commercially developed. You could chalk that up to the dangerous imprecations of the 'old girls' network, but I think it's just a problem that hasn't been solved yet in a cost-effective manner. Which is why money is still being spent looking into it.
But what's important this time I guess is that it's a woman who "discovered" the idea.
I don't see why you would conclude that. I can think of two reasons this article might be important:
Note that those two options are not mutually exclusive.
If they can come out with a hybrid SUV with 4-wheel drive and good cargo capacity and power to carry the weight of my musical gear, then believe me, I will be one of the first in line to check it out!
Keep an eye out for the Ford Escape Hybrid.
Better update it so that you don't [open] a specially crafted email sent by an attacker.
"It would be trivial for this exploit to be fashioned into a worm, targeting e-mail addresses found in any readable text files (inbox, etc.)."
Here we are 50 years later, and nothing has changed...except that 50 years ago almost everyone knew how to spell "calculus". :-/
And since we're discussing written science fiction, it should be noted that 40 years ago everyone who knew the word could spell 'grok.'
Yeah but how much would they weigh at sea level in metric elephants?
African or European?
Sounds like just about any Clive Cussler novel.
And the list goes on and on and on and...
This solution will only work if it is exclusive of existing practice.
That was their first mistake.
Had they designed this as an SMTP Service Extension so that it could be integrated into existing mail servers, it would stand a chance of eventually being adopted. Sites could accept both, perhaps treating AMTP messages as SPAM-free for filtering purposes, until use was widespread enough to turn away messages that didn't have AMTP verification.
But to make an all-or-nothing stand will just doom the project. Sure, some rare people will want to run AMTP for cred and SMTP for the rest of their mail. Everyone else will wait for sendmail to create a service extension to do the same thing without having to rip out the plumbing.
Good point. Pikes Peak, at least, people have heard of. So there are acceptable alternates.
Not until after. Oops!
Christ, that isn't a fucking mountain...
While I have heard that other, lesser states have higher mountains... none of them have the same fame as Mt. Washington, except perhaps McKinley in Alaska. (Rushmore, of course, is not famous as a mountain per se...)
Of those that are famous, I daresay Mt. Washington is the only one with an auto road leading up to the peak. Insofar as they were on Segways, that kind of limited their choices.
Did they get bumper stickers that say This Segway climbed Mt. Washington?
So tell me? What did Stallman do to pay the rent and eat before he became a MacArthur fellow?
Dame Rumor says he implemented. I recall hearing back in '94-'96 or so that he commanded a very hefty hourly rate for consulting, mostly extending emacs and the like for companies that wanted useful tools.
Of course, I understand a lot of that went straight back into FSF. I did confuse him for a bum (sorry, but that's truth) when I first saw him, so he clearly wasn't spending much on himself.
That's the rumor. How true it is, I have no idea...
Read your references before using them, please.
I did, and if you would like to do so, you should pay particular attention to section 4.3, which outlines which codes may be used when:
The section you quote, "Appendix E - Theory of Reply Codes" is designed to explain how to interpret codes, not to suggest that every code may be used in response to every command.
As I posted in another reply, if AOL chose to reject the RCPT command with a 5yz error, then 821-compliant mailers would know it was rejected and bounce it. They have chosen a less compatible method that allows them to appear less culpable.
I would be interested to know if your reverse DNS is working (e.g., if your IP is 1.2.3.4, then
Should either return a name or that no name is found. If no name is found, then presumably your problem is that you are not on a so-called "dynamic" block, but that your RDNS isn't working. Different codes for different issues.
You're citing an out-of-date RFC. 821 was superseded by RFC 2821, which makes it clear that 554 is a valid connection-opening response...
You make an excellent point. Unfortunately, RFC 821 is not yet officially superceded by 2821, as of 8/25/03 (see Official Internet Protocol Standards - note that 821 is listed as STD #10, and 2821 is listed in the table labeled "Draft Standards"). RFC 2821 compliance is still uneven among the various MTAs.
If AOL wanted to lower their load, then they should happily HELO the competi^H^H^H^H^H blacklisted cable modem ranges, and then reject the RCPT command with a hearty 550, which is not only 821-compliant but almost every mailer on earth will recognize as a permanent refusal. The mail bounces, the bounce makes it clear AOL did it, no timeout is incurred and no retries waste client or server cycles.
For AOL, it isn't about lowering their load or doing the right thing. It's about screwing their competitors, and (more importantly to me), their competitors' customers.
Among other petty annoyances, AOL is incorrectly refusing connections from blacklisted hosts, as follows:
According to RFC 821 (sections 4.3 and 4.2.2), the server can respond to new connections in with a 220 ("let's dance") or a 421 ("go away, I have a headache") response. Not a 554 ("you're lousy in bed") code. Among other things, the manner in which they reject mail from residential IPs causes it to languish in the queue, rather than bouncing as it should if they intend to permanently refuse delivery.
I'm sure they do this intentionally so that it will look like your mail server is at fault ("sorry, couldn't get through") rather than theirs ("buzz off, I don't like your IP address").
So where's the third DVD movie in a two movie DVD release? D'OH! Oh wait, it hasn't come out yet...
*hem, hem*
The article is, in fact, referring to "theatrical release." The idea is that, in the same month, the extended versions of the first two movies will be available in limited theaters, so that one might properly prep for the release of the third movie (also in theaters).