[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