Re: sort -R: a more-conservative approach

[Frederik Eaton]

On Mon, Dec 12, 2005 at 09:26:41PM -0800, Paul Eggert wrote:
> Frederik Eaton <address@hidden> writes:
> 
> > Well, I guess it's only a factor of two, but there's a difference
> > between bugs that cause a segfault in a tool that many people use, and
> > bugs that might cause a new feature with 0 existing users to not be
> > 100% cryptographically secure.
> 
> I'm sympathetic to this argument, and in fact had toyed with the idea
> of using something much simpler and faster like buzhash
> <https://www.se.auckland.ac.nz/courses/SOFTENG250/archive/2004/lectures/hamer-5.pdf>,
> perhaps at the user's option.  buzhash is not cryptographically secure
> but should work well with any data that is not designed by an
> attacker.
> 
> For a cryptographically secure function, a good choice might be a hybrid
> CW/UHASH approach, as suggested by Crosby and Wallach
> <http://www.cs.rice.edu/~scrosby/hash/>.
> 
> But all this can wait until somebody has more time....

Perhaps the next step is to put some cryptographic randomness and
hashing functions in libc, to eliminate the whole question of whether
effort should be expended to make things cryptographically secure or
not - stuff would just be secure by default. Then 'sort' and 'shred'
would just be clients to this API and things would be much simpler. 
Maybe the user could even indicate his paranoia to libc via an
environment variable.

Frederik