Slashdot Mirror

TOO LATE!

ftp://ftp.auckland.ac.nz/pub/g...

vim too!

http://www.bttr-software.de/fr...

I guess it's time to link to this, which we ran into at work some years ago. Ended up getting printed as a poster and stuck on walls until The Mgt. complained about the swearing in it. Which was strange really, swearing seems to be a natural part of using Notes.

Burroughs was clever and designed its mainframe series (B6700 etc) to use 48-bit words consisting of either 8 6-bit or 6 8-bit bytes. The hardware could handle either (when dealing with character strings).

Quite a few years later I was working on a Control Data Cyber series which still used 6-bit characters, in a 60-bit word. Text processing on that was so painful I wrote my own, in Pascal, which handled everything internally as ASCII.

The B6700 had 52 bit words, the extra bits were for flags and parity!
see: http://www.vcfed.org/forum/arc...

We had one when I was at University: https://www.cs.auckland.ac.nz/...

The best and brightest among us tend to scoff at such people, or more specifically at their stumbling and crutches, with all sorts of plausible-sounding but not actually helpful counters like "good people know what their code does", conveniently forgetting that most programmers aren't very good at all. So perhaps "patterns" are a useful crutch to keeping a lid on the damage from the inevitable Dunning-Kruger effects in business programming. I don't know, maybe.

Self-referential. You're taking the same approach, but softer: "some of us are smart enough to not need this."

Some of us are engineers and can build a house without adhering to national and international building and electrical standards and codes. That house will be structurally-sound. We'll understand how each part works and how to maintain it or build additions so it doesn't crumble.

That doesn't help every other professional who touches our stuff.

But it was only until very much later that I found this writeup

Essentially, yes. The thing he should also notice is all the complex garbage around the sensible stuff needs to be of a fixed form: it's no longer complex if it's recognizable.

Let me give you an example.

Walk over to your bookshelf, pick up a book, and open it to page 173. Read the third paragraph aloud.

Walking involves activating neurons, determining your spatial relationship with objects and the floor, tracking your velocity, checking your balance, and shifting the non-rigid form of your body (not just tilting back and forth) to redistribute your weight. It's one of the most bizarrely-complex things you can do.

Talking involves pulling multiple muscles in your throat in various ways in a pattern, while modulating your breathing and mucking about with several muscles in your mouth to change resonance cavity shape. It's ridiculous.

Picking up the book and opening to a page requires fine motor control. Reading is unbelievably-complex.

You've already internalized all of these things and do most of it based on expectations. When something unexpected happens, you respond quickly based on what you expect this new change to produce.

We could argue this all day; although I'd rather ask Peter Gutmann, who once made an observation about why we all use SSL instead of something much better we designed this morning over coffee. If you're really onto something, you should teach everybody else this new methodology so we can all benefit.

That is bad information that's been circulating for decades, from back when that was not really bad information. It originates from a paper by Peter Gutmann during a time when hard drives didn't do the insane signal processing they do today. One zero pass on a drive is sufficient today. This was brought up on Slashdot ten years ago.

It literally requires no effort.

This is completely untrue. Given a strong desire to eat unhealthy food, do you really believe that constantly fighting against that desire requires no effort? Does it also require no effort to forego other pleasures in your life? There are books on this subject.

Calories in - calories spent = weight gained/lost

This is clearly true, and almost completely irrelevant. As should be clear from the post by friesofdoom, some people simply want to eat more. They need to eat more before they feel similarly full to another person who may have eaten less. This means that those people, in order to remain thin, must fight a constant never-ending battle against themselves, that no human being can ever be expected to win. Of course if you eat more, you get fat, and if you eat less, you get thin. But imagine you were in a situation where if you didn't eat more than your body technically required, you felt hungry. Now imagine being hungry every day, for the rest of your life. Imagine that hunger, present, all the time. Imagine that if you gave in to that hunger, you would gain weight. Now imagine trying to remain thin in that situation. Perhaps if you were in that situation, you would not be so glib about 'thermodynamics'. And, of course, I am not the only person who understands this

As soon as you actually dig into it (like with this, from a well-known name in the industry), you'll find out that PKI is... flawed, deeply flawed and on just about every level. The worst isn't even the messy technology (openssl, anyone?), but the hierarchical design. That works very well in rigidly hierarchical organisations, like the military, but that doesn't scale to your entire life. For one because this sort of thing doesn't deal graciously with crossing organisational boundaries, but people don't have but one owner other than themselves. Supposedly, anyway. It's one of the things that we're apparently dead set to find out the hard way.

This is a real pity for the TM community. This is not the first chip with transactional memory support in hardware: The Sun Rock was announced to have hardware TM support, and the IBM Blue Gene/Q Compute chip also supports it. Unlike other proposals for unbounded transactional memory, all these systems employ Hybrid Transactional Memory (ref, ref, ref), in which restricted hardware transactions are designed to correctly coexist with unbounded software transactions, so a software transaction can be started in case a hardware transaction fails for some unavoidable issue (such as lack of cache size or associativity to hold speculative data from the transaction, not because of a conflict). Note that, in any case, very large transactions should arguably be very uncommon, since they would significantly reduce performance (similar to very large critical sections protected by locks).

The problem with the hardware implementation of transactional memory is that they are not simply a new set of instructions which are independent from the rest of the processor. HTM implies multiple aspects, including multiversioning caching for speculative data; allowing for the commit of speculative (transactional) instructions, which could be later rolled back (note that in any other speculative operation such as instructions after branch prediction, the speculation is always resolved before instruction commits because the branch commits earlier); a tight integration with the coherence protocol (see LogTM-SE for an alternative to this very last issue, but still...); a mechanism to support atomic commits in presence of coherence invalidations... From the point of view of processor verification, this is a complete nightmare because these new "extensions" basically impact the complete processor pipeline and coherence protocol, and verifying that every single instruction and data structure behaves as expected in isolation does not guarantee that they will operate correctly in presence of multiple transactions (and non-transactional conflicting code) in multiple cores. There are some formal studies such as this or this, and the IBM people discuss the verification of their Blue Gene TM system in this paper (paywalled).

As some others commented before, the nature of the "bug" has not been disclosed. However, since it seems to be easy to reproduce systematically, I would expect it to be related to incorrect speculative data handling in a single transaction (or something similar), rather than races between multiple transactions.

Regarding the alternatives, Intel cannot simply remove these instructions opcodes because previous code would fail. I assume that the patch will make all hardware transactions fail on startup, with an specific error (EAX bit 1 indicates if the transaction can succeed on a retry; setting this flag to 0 should trigger a software transaction). In such case, execution continues at the fallback routine indicated in the XBEGIN instruction, which should begin a software transaction. Effectively, this will be similar to a software TM (STM) with additional overheads (starting the hardware transaction and aborting it; detecting conflicts with nonexistent hardware transactions) that would make it slower than a pure STM implementation.

You cannot assume that.You don't know how long this vulnerability has been exploited, and it is reasonable to expect that some high-profile targets that use OpenBSD in their stack may have been compromised.

Netcraft reports BSDs as 1% or less of the servers out there, OpenBSD being a fraction of that, FreeBSD being another, NetBSD and other such probably being a smaller fraction than either. I would expect OpenBSD to be the bigger fraction--who uses BSD on a server?--but FreeBSD appears to be more popular as a desktop OS, and that may carry weight. Of course we're talking about the tastes of the 1% so who really knows?

Thing is we know a lot of high-profile targets are straight Linux or they have dedicated appliances that were vulnerable (FortiNet products, SonicWall products, Cisco and Juniper gear even). When making conjectures, I take the larger probabilities--look up Operational Risk Management and related analytical techniques--and draw likely conclusions. "OpenBSD isn't vulnerable" would not have convinced me (or likely anyone) that the situation is any different from a practical standpoint, except that a few machines somewhere would theoretically escape vulnerability, and even then you may be able to modify the attack (i.e. take less than 4k?).

The problem is, on top of the fact that no boundary check was performed on a copy operation, this passed a code review and was incorporated in the most widely used SSL library, that reads and process sensitive information.

Yes I've said this a few times about "better coding practices". Cleaner code would have helped, heartbleed was very self-contained, the process of review and clean code *may* have increased the likelihood of Heartbleed not making it past a review, but it did make it past several manual reviews as-is, etc etc. Part of my larger argument has been that Heartbleed isn't exposed by technical runtime countermeasures until exploited, and apparently nobody thought to look for this particular kind of bug, so it was never tested.

That actually sounds interesting. What happened to it?

Well besides that I am not the world's best programmer--I do have a certain strength in the area, but it's vastly outweighed by my weakness in larger architecture and I always had this perfectionist thing going on with no real code discipline so I was always frustrated with my own bad code--I could never get the allocator tested. You do understand why it might be hard to test a memory allocator as it's incrementally written, right?

The basic plan was to implement parts of malloc(), and fall back to glibc's malloc() for cases I don't handle. I used a staged design, with arbitrary object sizes based on some research papers I read--16 byte objects are common, so I have a "picoheap" or whatever I called it that's just a collection of mmap() areas for holding 16 byte objects. For larger (128 byte-256 byte?) objects I had separate mmap() areas which used canaries to detect write overflow (too much overhead to do that with 16 byte allocations, just made them 4k pages with a bitmap). And so on. I tried to implement one class of allocation, and fallback to malloc() otherwise... and the interposing wasn't something I knew how to do.

I'm sure Peter Gutmann would have something to say about me replacing malloc() with something much better I invented one morning over coffee (and the Web site part is now defunct... I still have the design docs somewhere, probably the schizophrenic rantings of a child).

Eg. acessing odd memory positions is a stall in most modern CISC cpu's (and some ancient ones too), so your code will actually run slower. In some cpu's, the stall is everything that is not 16-byte aligned.

What is it doing? Ask the engineers that built it

For one, it's polling the hardware looking for attacks against its DRM systems:
http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

So.. your CPU, video hardware, and audio hardware don't idle well.

Found it: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

"In order to prevent active attacks, device drivers are required to poll the underlying hardware every 30ms for digital outputs and every 150 ms for analog ones to ensure that everything appears kosher. This means that even with nothing else happening in the system, a mass of assorted drivers has to wake up thirty times a second just to ensure that⦠nothing continues to happen"

So there you go, your video and audio drivers have to poll the hardware repeatedly, which takes all of the CPU, video, and audio hardware out of low-power state when they could otherwise be idle.

As far as I know, this remains the spec for drivers, and does partially explain why Windows would use more power at idle than other operating systems.

Do one overwrite with zeros for magnetic media. They cannot recover that.

if "They" refers to Geek Squad, yeah maybe not. In reality however, overwriting magnetic storage with 0s doesn't actually remove the data*. I'm not saying everyone can afford, or get access to, the equipment below but there is some myth to the notion of "erasing" data by overwriting it.

using specialised circuitry it is possible to work out what previous "layers" contained. The recovery of at least one or two layers of overwritten data isn't too hard to perform by reading the signal from the analog head electronics with a high-quality digital sampling oscilloscope, downloading the sampled waveform to a PC, and analysing it in software to recover the previously recorded signal.

[*] - http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

It turns out, that especially when cooled, the RAM may in fact retain information for some period short enough to allow the device to be unpowered and repowered, and essentially retain all its data. (there may be a few errors).

Actually, the period can be quite significant. One of my projects involved a kernel that could only dump messages to RAM. To get it out, I'd reboot the board and dump the log buffer. At regular room temperature, but elevated board temperature (jthe CPU was running for a good tilt so the board heated up), a power cycle (under 1s) would let you read it out perfectly. After 10s off, you could see corruption but was mostly readable. After 30s or so, it was barely readable.

It appears the main physical phenomena is that the memory capacitors "distort" ever so slightly so the RAM doesn't completely powerup randomly, but is influenced by what was held there previously. It's a time related thing as well - a memory cell that was rapidly cycled would tend to have a lower time before corruption than a cell which held data staticly for a long time. Since encryption keys tend to fall in the latter, the memory tends to stay that way a bit longer (unless the code periodically switches memory buffers and scrubs the old one - it doesn't take much - just store a new pattern in then and it'll overwrite the old one).

Sections 7 and 8 of the famous Gutmann paper detail this effect in memory as well (you may recall the paper dealt with recovery of data off hard drives - but it also dealt with semiconductor nonvolatile memory as well).

A followup paper(PDF) goes into more detail on semiconductor memory including flash storage.

Yeah I still have no idea how to do logging well.

But what I like to do when performance is not an issue is to log everything (DEBUG etc) into a context ring buffer. Then normally only log messages above the configured log threshold will appear in the logs (e.g. INFO, NOTICE, WARNING). The DEBUG stuff won't appear. BUT if a log message above a log the context threshold occurs (e.g. ERROR, CRIT) the contents of the context buffer is logged followed by the actual triggering log. This way I don't have to turn debugging on. It can always be on BUT I don't have my logs full of the debug level logs unless "stuff happens".

This context logging stuff is bad for performance, but so far it's not a problem for the stuff I do (and can be turned off). It does make it easier to figure out what happened while creating less DEBUG noise.

As part of my log messages I also have hashes and dots, e.g.:
DEBUG = one hash = #........
INFO = ##......
NOTICE = ###.....

This way I can easily "grep" log files for logs above a particular threshold. If you're Google or Facebook scale you'll have to do things a bit differently because there'll be zillions of logs, you can't have half a million machines send logs to one log server ;). So you'd need a way to summarize logs.

It might also be nice if the CS lecturers spend some time discussing the merits of different exception handling approaches in various scenarios. Instead of just stuff like this: http://www.cs.auckland.ac.nz/compsci105s2c/lectures/adriana/Lecture06.pdf

Doesn't need to be as detailed and extensive as this: http://www.amazon.com/Advances-Exception-Handling-Techniques-Computer/dp/3540419527

Just some basics that might open up student eyes to how things work in the real world and more importantly how things could fail, and how one might deal with them.

FWIW I didn't do CS. I did EE. So maybe this stuff is actually covered in some CS courses. I doubt it was covered in my colleagues CS courses though ;).

Guttman has updated his original paper a few times, the last being around 2011. In his updated epilogue he says "In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, "A good scrubbing with random data will do about as well as can be expected". This was true in 1996, and is still true now." See http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html#Epilogue

A man named Gutmann showed us that you can use what is essentially an analog ghost of the previous information. Our digital 1 or 0 is actually represented by ranges of analog values not exact fixed voltage levels. If the previous value was a 1 and you write a 1 the resulting ANALOG value will be greater than if the previous value was a 0. If you use the same value or a predictable set of values of overwrite the drive it is easier deduce the previous values. This task becomes more difficult with multiple passes as each write will make the previous ghost more faint and add a new one. If you are writing a fixed pattern it is easier to filter out that pattern to detect the data you are really looking for.

People will be quick to point out how up to date they are and tell you that with modern drive densities this type of recovery isn't possible. If you are willing to trust that advancing technology had only applied to the drives and not the equipment you use to perform this operation be my guest. But SSDs are becoming common and they leave a much stronger analog residue that makes this old security precaution necessary again.

Gutmann found that 30 passes was needed to completely obliterate the traces on old drive technology. A two pass write with random data is a strong standard practice for modern drives.

You could read the paper:

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

But the technical overview on wikipedia will suffice.

http://en.wikipedia.org/wiki/Gutmann_method

Whenever I hear people toting the line that open source is equivalent to security, I immediately imagine Peter Gutmann unzipping his pants.

(Search for 'sound wave')

makes it possible to look for deleted or over-written information that might not exist on a duplicated disk.

Deleted stuff is never erased, just marked as "free space" by the OS.

Overwritten data, these days, is unrecoverable, even if only overwritten once. There has not been a single criminal case that I can remember where data was overwritten and then recovered on modern drives. The standard of multiple overwrites for true erasure is from the days when disks were physically huge, and the recorded area was huge, and head alignment wasn't always the greatest thing in the world.

Go read the epilogue to Peter Gutmann's paper

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

A simple dd of the original drives would have given investigators all the information that was available, including deleted files.

--
BMO

It's been proven that one pass is sufficient to make all data unrecoverable. Here's but one article:
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

The one thing that secure wipes don't handle are remapped bad sectors - those could still possibly be read with the right equipment.

Actually...that 'fish' in your sushi...is not what you think it is...

"report on genetic identification of ‘whale meat’ purchased in sushi restaurants in Los Angeles, CA (USA)"
http://rsbl.royalsocietypublishing.org/content/early/2010/04/08/rsbl.2010.0239.full

You can submit a DNA sample online to identify the 'fish' in your sushi :D
http://www.dna-surveillance.auckland.ac.nz/
Plenty of evidence out there that whale and dolphin meat from endangered species is sold as 'fish' both in Japan and exported to various countries in the world.

XML security is stupid. Peter Gutmann explained why way back in 2004.

I agree. There are a lot of myths regarding storage sanitization. I do think it is too simplistic to say one pass of zeros will do the trick every time, but i'd give it a high probability of doing the job.

More interesting reading for the inclined: http://www.cs.auckland.ac.nz/~pgut001/

A log splitter works 100% of the time. No doubt. No myths.

http://hostjury.com/blog/view/195/the-great-zero-challenge-remains-unaccepted
http://www.anti-forensics.com/disk-wiping-one-pass-is-enough-part-2-this-time-with-screenshots
(Key quotes: Secure Deletion of Data from Magnetic and Solid-State Memory by Peter Gutmann (35 pass wipe originated from Mr. Gutmann)

âoeAny modern drive will most likely be a hopeless task, what with ultra-high densities and use of perpendicular recording I donâ(TM)t see how MFM would even get a usable image, and then the use of EPRML will mean that even if you could magically transfer some sort of image into a file, the ability to decode that to recover the original data would be quite challenging.â)
(Article itself) http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

Certificates are good for encryption. That's it. With the insane amount of "trusted CAs"
that come pre-trusted with every browser nowadays, that's all that is possible.
Hoping to achieve anything beyond that is naive.

From a very insightful talk about the topic:

SSL certificates provide honesty-box security

Use a $495 Verisign certificate
– People will come to your site
Use a $9.95 budget CA certificate
– People will come to your site
Use a $0 self-signed certificate
– People will come to your site
Use an expired or invalid certificate
– People will come to your site
Use no certificate at all, just a disclaimer saying that you’re secure
– People will come to your site

It is important to note the section on feasibility in that Wikipedia link... Peter Gutmann did the original (public sector) research on recovering overwritten data on MFM hard drives with very low byte densities (by today's standards). Peter revisited the subject and found that a single overwrite pass, even if only zeroing out every bit, was sufficient to defeat the technique on "modern" drives (i.e. drives larger than 15GB and made in the past 5-7 years).

Well, I got the quote (which was originally from Gottfried von Leibniz) from G.J. Chiatin, who misspelled it exactly that way. Thanks for pointing this out. :)

But once that physical block is overwritten, the previous data is gone. Assertions to the contrary are nothing but urban legend and speculation. Nobody seems comfortable claiming that one pass with zeroes is sufficient, but I've seen no evidence that it isn't.

See Peter Gutmann's Secure Deletion of Data from Magnetic and Solid-State Memory from the 6th USENIX Security Symposium Proceedings, San Jose, California, July 22-25, 1996. It certainly surpasses the "urban legend" bar for me (it was peer-reviewed and academically vetted).

Available online here: http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

The whole paper is worth reading, and it certainly applies to hard drives and not cassettes or earlier meda. A relevant excerpt:
The problem lies in the fact that when data is written to the medium, the write head sets the polarity of most, but not all, of the magnetic domains. This is partially due to the inability of the writing device to write in exactly the same location each time, and partially due to the variations in media sensitivity and field strength over time and among devices.

In conventional terms, when a one is written to disk the media records a one, and when a zero is written the media records a zero. However the actual effect is closer to obtaining a 0.95 when a zero is overwritten with a one, and a 1.05 when a one is overwritten with a one. Normal disk circuitry is set up so that both these values are read as ones, but using specialised circuitry it is possible to work out what previous "layers" contained. The recovery of at least one or two layers of overwritten data isn't too hard to perform by reading the signal from the analog head electronics with a high-quality digital sampling oscilloscope, downloading the sampled waveform to a PC, and analysing it in software to recover the previously recorded signal.

That said, Gutmann later proposed a 2-pass overwrite method that should be sufficient with modern drives, and offered a discussion of why some of the things proposed in the paper are less relevant on modern, denser hard drives than previously:
http://www.forensicswiki.org/wiki/Epilogue_to_Gutmann's_1996_paper

I know that the security of CAs is not as it should be, but requesting forged certificates for *all* major websites will require a lot of work and more importantly, it will be noticed sooner or later.

Interesting thing about CAs is that many of them don't even require you to be the operator of a domain to request it in their terms. There is additionally nothing illegal about requesting a bunch of SSL for usage on domains that the government intends to monitor - after all, the government makes the laws. With regards to browsers not authorizing it, I don't think that would do much at all, just take a look at Security Usability Fundamentals.

Please... SSL is not optimal, but is is not circumvented by such devices. SSL proxys work if you accept them as CA. They are designed for corporate scenarios, where it is a realistic assumption that all clients trust the proxy and accept it as CA.

You're assuming that the Australian government couldn't afford the services of some CA to get a wildcard certificate.

In the given scanario, it is not plausible to assume that everybody will blindly accept those certificats. So the proxy will simply not work.

Under the assumption that users won't just click 'yes' to the certificate, maybe. But then they don't get access to their e-mail, so maybe they'll start using their ISP's e-mail instead or some Australian mail provider - it must be fine since they're not getting security prompts, right?

I doubt many users would even know about it, those that do would probably feel powerless anyway and many would not have the knowledge to get around it.

From what I understand implementing encrytion correctly is tricky business. This looks good: http://www.cs.auckland.ac.nz/~pgut001/cryptlib/

SFTP is not FTP over SSH if you did not understand, it is a proper FTP that happens to run over a secured link.

FTP over a secured link is FTPS (FTP over SSL/TLS), which is distinct from SFTP (SSH file transfer protocol).

http://en.wikipedia.org/wiki/Ftps
http://en.wikipedia.org/wiki/SSH_file_transfer_protocol

Performance note:

FTPS can stream files at full TCP speeds, while most SFTP implementations suffer from the SSH and SFTP protocol performance problems caused by having small application-level window and packet sizes (often 32 to 64KB) and requiring a fixed set of packets to be acknowledged before the next bunch is sent.

For details, see section 6.2, "The SSHv2 and SFTP Performance Handbrake" in http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf
and pages 27 to 30 in http://fasterdata.es.net/talks/Tierney-tutorial.pdf.

There's a real difference between Gutmann's early Vista analysis and this smear campaign. Gutmann was trying to peer behind a veil of secrecy to find what Vistas content protection looked like and sure he missed the mark but it was an honest attempt to evaluate what the future held based on MS, ATI and other presentations, press releases and patents.

Whereas this guy is clearly a shill out to smear MS based on blatant fabrication.

It seems everyone forgot the DRM and 'Trusted Computing' (aka distrust the user) introduced in Vista, one of the major criticisms (not look & feel).
You may recall this analysis: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html, (Schneier wrote something here: http://www.schneier.com/blog/archives/2007/02/drm_in_windows_1.html)

Not sure how 7 is now, but its not like the bashing against DRM/Trusted Computing/TCPA was not without reason, and might have worked. Also, since that time, complaining made music download websites turn their back to DRM.

True, although you could slide the tabs around and almost replicate the feature. Haiku has improved in this area and has a feature called Stack and Tile.

Talking about Windows, Format DOES NOT WIPE THE DRIVE. All a full format does is set up the file system, and does a read verify. It does not overwrite data portion of the partition.

A good tool is Eraser. http://eraser.heidi.ie/ Use it to securely wipe specific files when no longer needed. As well it allows you to wipe free space on the disk at any time, allowing you to wipe previously deleted files.

If the computer is deemed surplus, and you want to prepare the computer for resale, A PLAIN FORMAT IS NOT ENOUGH. That is how so much sensitive information is found on surplus computers. The data is still on the disk. Wipe it using a tool like DBAN http://www.dban.org/

As far as reading residual data, some people claim 35 passes blah blah blah. This is referencing Gutmann's work, which focused on old drives. It is not applicable on new drives with different encoding techniques and extremely high data densities, and he has said on new drives a single pass of pseudo-random is enough. Anything extra is a waste of time. http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html (read the epilogues)If there is truly confidential data on the disk, the only safe method is physical destruction to ensure nothing resides on remapped sectors, etc. Now, particularly if you have laptops, encryption of customer data is a good preventative measure, as overwriting of surplus hard drives does not help you when a laptop with customer data is stolen from an airport. Truecrypt http://www.truecrypt.org/ is a good encryption solution, though you need some 'workarounds' if you wish to be able to unlock users that have locked themselves out of their container file. It can also do full disk encryption (as can Windows Ultimate/Enterprise)

A little out of date, but I can't imagine things have improved since then:

A Cost Analysis of Windows Vista Content Protection.

I'd like to thank the OpenBSD project, as well, but I'd also like to point out a few issues.

OpenSSH still won't work with certificates signed by a CA.

Quite right, and we have no intention of incorporating x.509 support. X.509 parsing and verification exposes a large amount of attack surface and all of it is, by necessity, pre-authentication too (the type which, if buggy, allows worms). Read Peter Gurmann's X.509 style guide and see if you ever want to go near this horror again. We have actually written our own minimal RSA verification code to avoid the sort of ASN.1 parsing that is necessary to deal with X.509, and it has saved us from at least seven bugs - some probably exploitable for authentication bypass or remote code execution.

OpenSSH doesn't allow an unencrypted connection (after authentication). Not all CPUs can encrypt/decrypt at 1Gbps.

Yep, we are a _secure_ shell and we take a mildly patriarchal attitude to adding options that can lead to insecure use of OpenSSH. Note that the actual bottleneck in most cases is not the crypto anyway (at least when using arcfour256 as your cipher) but the MAC, and you wouldn't want to switch that off. We do have a very fast MAC though: umac-64

OpenSSH doesn't work - as advertised - with an exclamation point in a "Match" statement.

File a bug, we'll fix it.

Other than that, OpenSSH is possibly one of the most capable and reliable pieces of software I've ever had the privilege to use.

Thanks :)

a multi-billion dollar behemoth that likes to crush competition

To be more exact, they tend to half-kill things and then eat them.

I'm a bit of a noob when it comes to comprehending licensing and related issues, but as far as I can tell Microsoft's biggest contribution to the Open Source / Free Software Movement has been the continued tendency to obscenely restrict and retard peoples' ability to use their computers and software as they see fit (I'm thinking primarily of 'premium content protection' in Vista onward), thus waking more and more people up to the alternatives (by motivating them to look elsewhere).

Here's a link to an audio podcast of the article (actually starts at 5:52): Cost Analysis of Vista Content Protection by Peter Gutmann.
And the source site (please don't try to download the PDFs, the useful info all appears to be on the HTML page and the site seems to be speed throttled): HERE.

Who the hell modded this informative?

It's perpetuating a myth.

Even Guttman says that with modern hard disks it's impossible to retrieve data once overwritten.

http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

Epilogue
In the time since this paper was published, some people have treated the 35-pass overwrite technique described in it more as a kind of voodoo incantation to banish evil spirits than the result of a technical analysis of drive encoding techniques. As a result, they advocate applying the voodoo to PRML and EPRML drives even though it will have no more effect than a simple scrubbing with random data. In fact performing the full 35-pass overwrite is pointless for any drive since it targets a blend of scenarios involving all types of (normally-used) encoding technology, which covers everything back to 30+-year-old MFM methods (if you don't understand that statement, re-read the paper). If you're using a drive which uses encoding technology X, you only need to perform the passes specific to X, and you never need to perform all 35 passes. For any modern PRML/EPRML drive, a few passes of random scrubbing is the best you can do. As the paper says, "A good scrubbing with random data will do about as well as can be expected". This was true in 1996, and is still true now.

Looking at this from the other point of view, with the ever-increasing data density on disk platters and a corresponding reduction in feature size and use of exotic techniques to record data on the medium, it's unlikely that anything can be recovered from any recent drive except perhaps a single level via basic error-cancelling techniques. In particular the drives in use at the time that this paper was originally written have mostly fallen out of use, so the methods that applied specifically to the older, lower-density technology don't apply any more. Conversely, with modern high-density drives, even if you've got 10KB of sensitive data on a drive and can't erase it with 100% certainty, the chances of an adversary being able to find the erased traces of that 10KB in 80GB of other erased traces are close to zero.

Also:

http://sansforensics.wordpress.com/2009/01/15/overwriting-hard-drive-data/

What this means

The other overwrite patterns actually produced results as low as 36.08% (+/- 0.24). Being that the distribution is based on a binomial choice, the chance of guessing the prior value is 50%. That is, if you toss a coin, you have a 50% chance of correctly choosing the value. In many instances, using a MFM to determine the prior value written to the hard drive was less successful than a simple coin toss.

The purpose of this paper was a categorical settlement to the controversy surrounding the misconceptions involving the belief that data can be recovered following a wipe procedure. This study has demonstrated that correctly wiped data cannot reasonably be retrieved even if it is of a small size or found only over small parts of the hard drive. Not even with the use of a MFM or other known methods. The belief that a tool can be developed to retrieve gigabytes or terabytes of information from a wiped drive is in error.

--
BMO

Gutmann's paper was based on 1990-era technology. And even then you didn't need all 35 passes, just the ones that correspond to the encoding used on the disk. If I read the enhanced version of the paper correctly, restoring even plainly overwritten data from a modern disk is a hopeless task.

Actually, yes, there is such technology to degrade quality of some content when not using an HDCP-compliant display, to reduce quality of rips made by sniffing the monitor connection. (Of course, they're forgetting about LVDS. You can pop open an HDCP-compliant display, unplug the bare panel from the controller, and make a dummy panel that just gets the pixels decoded from the controller. Or, do it to a laptop with an HDCP-compliant GPU. Digital holes are a bitch like that, you can always get to whatever's driving the pixels, and IIRC, it's actually harder to decode TMDS than it is LVDS - hence why the panel is driven by LVDS.)

Take a look here: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html#quality

I just use VLC for everything, on any OS that supports and runs it well, so it doesn't affect me, but the issue is still there.

The DRM systems are only active when DRM-encumbered media is being played.

This is absolutely not true at all.

To take my (in my opinion overly-generous) estimate of a high-budget under your system - $10m - adjusting for inflation the only film in the IMDb top ten that would have been made is "12 Angry Men". It's not only Dark Knight that we'd have missed out on - no Star Wars, no Godfather, no Pulp Fiction. No One flew over the cuckoo's nest.

I think it's a mistake to assume that these films could only have been made with the budgets they actually had. Science fiction films had been made for decades before Star Wars came along, for instance. With a smaller budget, you might not have ILM's fancy effects, but you could still tell the story.

I loved the film Dark Knight - I've seen it multiple times, I own the DVD, and if a sequel comes out I'll almost certainly go to see it. But if I got a letter from the studio asking for $20 to fund production of that sequel? I wouldn't pay. For one thing, I would be skeptical paying for a film before I knew if it would be any good.

Then sir, you are not as much of a fan as you think you are.

If my favorite bands asked me for $20 to support the production of their next albums, I wouldn't hesitate. I know I'm going to buy whatever they release anyway, so why should I care whether I pay before or after it's released? Likewise, I know I'm going to see the sequel to Dark Knight, so it doesn't matter to me whether I pay for production or pay for a ticket.

For another, I don't much like the idea that I pay but everyone gets what I pay for, it doesn't seem fair.

I don't understand this zero-sum attitude.

When I pay for something, I consider the benefit that it provides for me, not for anyone else. For example, if I maintain my lawn and that raises my neighbors' property values, I don't feel like I'm being ripped off -- I'm maintaining the lawn for my own reasons, and any benefit my neighbors extract can't take away from the benefit I receive. In fact, I might even consider it a bonus.

Thirdly, I don't really like the idea of sending money away on the possibility that something might happen.

Ah, maybe I haven't been clear on this point. The money you send away is payment for a service, not a gift or a speculative investment. You would be legally entitled to a refund if the service was not performed as agreed.

What are those costs?

Loss of access to past works: there are thousands of existing works which are unavailable to anyone who lacks the means to pay for a access, even though in many cases the authors are dead or retired, which means the copyright on those works is serving only to restrict access rather than to provide any benefit whatsoever to anyone except the authors or their heirs.

Loss of access to derivative works: fan sequels, mashups, etc. Even derivative works made by large studios are frequently tied up because of this, whether it's filmmakers arguing over the rights to a book or an old TV series being released on DVD with a crappy new soundtrack (or not at all) because even the producers no longer had permission to release the show in its original form.

Technological restrictions: every computer comes with software to back up purchased audio CDs, but 12 years after DVD-R was invented, you still have to go underground to find software to back up purchased DVDs, and you'll be breaking the law if you use it. Standalone DVD recorders can't do it either. And remember how much overhead there is in Windows Vista simply to prevent you from viewing content in an unapproved fashion, not to mention all the other DRM you're paying for when you buy a computer, TV, disc player, or iPod.

The reason I don't feel my rights have been threatened by movie copyrights is that it has no effect on my speech. Comparing it to banning adverbs is ridiculous; not once in my life

How do you know this is the fault of the scientists?

Because they titled the paper, "Existence of collisional trajectories of Mercury, Mars and Venus with the Earth" and not "Long-term integration of inner-planet orbits including general-relativistic effects".

This one is on the scientists, not the press.

The previously wide-spread belief that the solar system is chaotic is no longer universally held, and there are significant parts of the community who believe that the chaotic results were due entirely to numerical instabilities in the simulations, not the physics at all. See for example: http://www.math.auckland.ac.nz/Research/Reports/Series/527.pdf which deals primarily with outer solar system dynamics.

So this is just someone pushing an idea that may well be false in the most sensationalistic way possible. I have to admit, the hype does do a pretty good job of distracting people from the more interesting scientific question, which is: is the inner solar system chaotic, or is that result too a numerical artifact?

...and any actual problems it might touch upon have been solved better by SSL certificates years ago.

Wow. Is DNSSEC that bad? It's hard for me to imagine any serious crypto protocol being worse than SSL certificates.

Try reading this.

The people that wrote the article in the story you mention had no idea what they are talking about.

Peter Gutmann, one of the experts in this area, specifically responded to that article (see further epilogue).

Have you slept trough the whole thing?

Here's the complete and thorough analysis, that was mentioned in an earlier /. article as well:
http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

I quote: "The Vista Content Protection specification could very well constitute the longest suicide note in history."

Not GTFO with your arrogant "think-you-know-everything while not knowing shit" mentality, before I come over.

http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html

If you've reviewed the document above, then I think you'll have to acknowledge that this is a fundamental flaw to the kernel of MS Windows.

Oh, and BTW, You're correct on one point - I do not use Microsoft products (by choice based on past experience).

And, FYI, I was not discussing the functionality of a shell (graphical or otherwise).

What, you think DRM-processing is somehow resource-free? The cycles and memory that must be allocated to do it come from magical land instead of system resources? Please. As talked about at length here, Flatout 2 plays 15% slower with DRM than without. DRM can also decrease battery life by 25% because of the additional processor load creating more heat.

The paper is an interesting read, but people must remember that this theorem still does not distinguish between Free Will or Randomness. It merely says that if a property X, is exibhited by the scientist conducting the experiment, then X would be present in the particles too.

As regard to whether X, is Free Will or randomness, Conway does not know. He gave it the provocative title of ``Free Will'' out of his own free will, or randomness, or what have you ;-)

See this page and go to the last section entitled ``Questions,'' where Conway admits to this in a seminar at the University of Auckland.