[RFC] Support for /dev/urandom in kdelibs

[Brad Hards]

On Thu, 30 Dec 2004 21:14 pm, Michael Buesch wrote:
> I designed a first class API to provide random data through QIODevice.
> I'm not completely sure if QIODevice is the right choice. Maybe
> QFile is even better. So currently the class is derived from QIODevice
> but it's likely to change to QFile.
What do you want to use the random data for? Alternatively, what is the 
intended application? Is it for crypto? What sort of application?

> The goal of this is to provide a well known standard interface for
> random data. Also note that I'm saying "random data" as a generic
> term and not "random numbers" or "random strings" here. The long term
> goal is to get the class working with QDataStream, so that it is
> absolutely generic. It won't be easy to get it working as far as I can
> see, yet. But maybe it's possible and worth the effort.
I don't see what would be so useful about a QDataStream, although I don't see 
it would be particularly hard to implement (not having tried it, of 
course :-) The hard part is the details, like how to avoid having someone 
snoop your precious entropy as you read it out.

> Example pseudo code for the class usage:
>
> KEntropySource es(KEntropySource::source_auto);
What is the argument? Is it meant to be a quality of the source, or a specific 
source?

> es.open();
> MyDataType t0;
> /* The user has defined the >> operator for this data-type somewhere. */
> int t1;
> QDataStream stream(es);
> stream >> t0;
> stream >> t1;
> es.close();
In  QCA2, the t1 part would just be
t1 = QCA::Random::randomInt();
which looks easier than opening a QDataStream for a single use.

I'm not sure what the t0 case would be, because I don't know MyDataType.
If it is a simple variable, then you could generate a (secure memory) array of 
the required length (using QCA::Random::randomArray(sizeof(MyDataType)) ), 
and then memcpy the contents of the secure array to the MyDataType variable. 
If it is a complex structure, why would you want to fill all the members with 
random data?

Please note that I'm not trying to be difficult - I'm always looking to 
understand potential users, and this sound like a case I haven't really 
considered, so it could be a problem with the QCA::Random design, and I'd 
like to fix that sooner if I can.

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041230/45a68ce5/attachment.sig>