Hi,

On Tuesday, Tuesday 11 February 2014 at 00:03, Kurt Pattyn wrote:
> On 10 Feb 2014, at 20:17, Thiago Macieira <thiago.macie...@intel.com> wrote:
> > Em seg 10 fev 2014, às 19:54:18, Kurt Pattyn escreveu:
> >> 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.
> > 
> > I don't think we need a class. We just need to make qrand() better.

Please don't go there. AFAIK qrand() is a function meant to be equivalent to 
the ANSI-C rand() function. I.e. it is supposed to be used by simple 
simulations, be fast and produce reproducable random numbers when seeded with 
the same value.

The requirements for secure random are different: supposed to be used by 
paranoid functions, be cryptographically secure, "fast" is defined as "just 
not so slow your key generation takes hours", and ideally never generate 
reproducable random numbers.

It is generally not a good idea to mix those two kinds of random in one 
function.

> I suppose you mean in Qt. I will use the following (fixed) implementation
> for QWebSocket, leaving the option open to add virtual methods or
> delegates or whatever in a later version (if ever needed).
> All in all, by running QWebSocket over SSL, then this potential problem
> does not occur.

I'm not sure whether I understand you right here. You need to add the 
"virtual" function in the first release, adding it later would break binary 
compatibility.

> //initialization
>  #ifdef Q_CC_MINGW
>     //cannot rely on the entropy method
>     //clang and gcc always return 0 even though the device is
> non-deterministic //Visual Studio always returns 32
>     //MingW gcc4.8 always returns 0; it uses rand() instead of the Windows
> CryptoAPI //(this is a bug)
>     //if (randomDevice.entropy() < 0.5) {
>         std::srand(std::time(0));
>         auto seeder = std::rand;
>     //}
> #else
>     std::random_device randomDevice;
>     auto seeder = std::ref(randomDevice);
> #endif
>     std::array<int, std::mt19937::state_size> seed_data;
>     std::generate_n(seed_data.data(), seed_data.size(), seeder);
>     std::seed_seq seq(std::begin(seed_data), std::end(seed_data));
> 
>     std::mt19937 randomizer(seq);
> 
> //effective use
>    quint32 randomNumber = randomizer();

Fair enough. We can improve it later.

> I also added the following warning in the documentation:
> 
>      \warning To generated masks, this implementation of WebSockets uses a
>     \l {http://en.wikipedia.org/wiki/Mersenne_twister}{Mersenne Twister
> 19937} pseudo random number generator, seeded by a sequence of numbers
> generated by a true random number generator. It uses the \l

Lose the bit about seeding. With a non-cryptographic RNG a secure seeder is 
just icing on the cake (it is just easier than compiling 32 bits of entropy 
yourself).

> {http://en.cppreference.com/w/cpp/numeric/random} {std C++11 random number
> generation facilities} and more specific \l
> {http://en.cppreference.com/w/cpp/numeric/random/mersenne_twister_engine}
> {std::mt19937} and \l
> {http://en.cppreference.com/w/cpp/numeric/random/random_device}
> {std::random_device}. If a random device is not present or if its entropy
> is lower than 0.5, it reverts to the cryptographically weaker \e

That should be "cryptographically insecure" - "weak" would imply that it 
offers at least a bit of resistance against attack.

> std::rand() function. For more information about the importance of good
> masking,
>     see \l {http://w2spconf.com/2011/papers/websocket.pdf}.
>     The best measure against attacks mentioned in the document above,
>     is to use QWebSocket over a secure connection (\e wss://).
>     In general, always be careful to have 3rd party script access to
>     a QWebSocket in your application.

I think that should be "careful to NOT have 3rd party script acceess"?

> Konrad, for people that are really paranoid, they can use SSL and disallow
> third-party scripts. Wouldn’t this be sufficient for now, knowing that we
> can always add functionality in a later version (when ever required)?

Absolutely correct.

Just make sure we don't have to break BC for that improvement (i.e. put all 
the "virtual"s in place).

I actually liked the idea with the QRng class, but I also think it could be 
improved by using a std::function instead:

class WebSocket{
 //...
 typedef std::function<quint32()>RandomFunction;
 void setRandomFunction(RandomFunction);
};


WebSocket mysock;
mysock.setRandomFunction([]{return 4;/*was a fair dice roll*/}


        Konrad

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to