[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: shred bug? [was: Unidentified subject!]



On Sun, Feb 11, 2024 at 08:02:12AM +0100, tomas@tuxteam.de wrote:
What Thomas was trying to do is to get a cheap, fast random number
generator. Shred seems to have such.

You're better off with /dev/urandom, it's much easier to understand what it's trying to do, vs the rather baroque logic in shred. In fact, there's nothing in shred's documenation AFAICT that suggests it should be used as a random number generator. For pure speed, playing games with openssl enc and /dev/zero will generally win. If speed doesn't matter, we're back to /dev/urandom as the simplest and most direct solution.

FWIW, the main use for shred in 2024 is: to be there so someone's old script doesn't break. There's basically no good use case for it, and it probably shouldn't have gotten into coreutils in the first place. The multipass pattern stuff is cargo-cult voodoo--a single overwrite with zeros will be as effective as anything else--and on modern storage/filesystems there's a good chance your overwrite won't overwrite anything anyway. Probably the right answer is a kernel facility (userspace can't guarantee anything). If you're really sure that overwrites work on your system, `shred -n0 -z` will be the fastest way to do that. The docs say don't do that because SSDs might optimize that away, but SSDs probably aren't overwriting anything anyway (also mentioned in the docs). ¯\_(ツ)_/¯


Reply to: