[Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

Kurt Pattyn pattyn.kurt at gmail.com
Mon Feb 10 19:54:18 CET 2014


On 10 Feb 2014, at 08:58, Konrad Rosenbaum <konrad at silmor.de> wrote:

> Hi,
> 
> I'll have to read and analyze this code in more detail to give you a qualified 
> opinion. I'll do this later...
> 
> On the surface it looks a bit complicated and I'm not entirely sure about the 
> seeding, but I'll have to study the API first to make sure.
> 
> On Sunday, Sunday 09 February 2014 at 22:40, Kurt Pattyn wrote:
>> If the above implementation suffices, then a virtual method would not be
>> needed anymore.
> 
> Please use the virtual method anyway. Yes, it adds about two more instructions 
> and a memory access for every call to this method, but security-wise it is 
> worth it.
Well, this is what I propose: use a delegate class that handles the creation of
a random 32-bit number. This would avoid having to subclass QWebSocket
just to overwrite the randomiser.

class QWebSocket
{
…
    void setRNG(const QRng &rng);
};

When setRNG is not called before opening the socket, a default implementation
will be used, based on std::random_device and std::mt19937.
This avoids a virtual method AND gives complete control over the RNG to the
user of the class.

class QRng
{
…
    virtual quint32 nextNumber() const;
};

A user that wants some very specific randomiser functionality, can subclass
QRng and override the nextNumber() method.

What do you think? I will work out a proposal.
Thiago do you think QRng would be a good name? I can imagine that sooner or
later Qt will provide a generic (P)RNG implementation, and then QRng could be
a good candidate for one or the other class name.

> 
> You can never assume code to be absolutely secure, just secure enough for a 
> particular purpose that you can envision under the constraints of the 
> knowledge you currently possess. Providing an overridable virtual method gives 
> users with stronger requirements (or with more paranoid bosses) sufficient 
> freedom to implement those requirements.
> 
> Incidentally it gives you an excuse to cop out of security discussions... ;-)
THAT is what I call an argument! J
> 
>> Should I fall back to the ordinary qrand() when the other methods fail?
> 
> Yes.
> 
Cheers,

Kurt
> 
> 
> 
> 	Konrad




More information about the Development mailing list