[prev in list] [next in list] [prev in thread] [next in thread] 

List:       botan-devel
Subject:    [Botan-devel] S2K::new_random_salt
From:       lloyd () randombit ! net (Jack Lloyd)
Date:       2008-07-13 19:35:04
Message-ID: 20080713193504.GB9989 () randombit ! net
[Download RAW message or body]

On Sat, Jul 12, 2008 at 06:30:33PM +0800, Joel Low wrote:
> Hello all,
> 
> If you all remember, the old prototype for new_random_salt simply
> took a length argument. Now that the global RNG has been removed, it
> has been replaced with one that takes an RNG object. Thing is, would
> it not be good to have an overload which just uses the old behaviour
> (ie create a new RangomeNumberGenerator object and immediately
> delete it when done?) and just takes one argument (length?) I???m
> not too sure if I remember if this was discussed before; if it has,
> my apologies ??? please point me in the right direction.

This doesn't feel like a good idea to me, for several reasons:

Creating and seeding a RNG is rather expensive, computationally (in
particular seeding might involve things like fork/exec, blocking
reads, or large number of file accesses, depending on the platform).
This is ultimately a somewhat minor point but I do feel that something
like this is rather unexpected. Obviously if the application is only
going to call new_random_salt once, and is not going to use an RNG for
anything else, then it doesn't matter, and there is a syntactical
advantage in not having to explicitly create the object.

The reason I really don't like the feel of this is that it couples S2K
and RandomNumberGenerator far stronger than I would like. Eventually
(ie, whenever I feel I can get away with starting to use TR1), many of
the places taking RandomNumberGenerator& will eventually take
something like std::function<byte ()>, representing a completely
abstract source of bits, allowing using a KDF or what have you. This
also has the advantage of faceting [1] the behavior of the
RandomNumberGenerator - after all, there is no reason for
S2K::new_random_salt to be able to, for instance, clear the RNG's
internal state and then add a completely deterministic 'entropy
source', but by passing a non-const RandomNumberGenerator& we are
implicitly allowing just that.

-Jack

[1] http://c2.com/cgi/wiki?FacetPattern


[prev in list] [next in list] [prev in thread] [next in thread]