monero/contrib/epee
anonimal cd57a10c90
epee: abstract_tcp_server2: resolve CID 203919 (DC.WEAK_CRYPTO)
The problem actually exists in two parts:

1. When sending chunks over a connection, if the queue size is
greater than N, the seed is predictable across every monero node.

>"If rand() is used before any calls to srand(), rand() behaves as if
it was seeded with srand(1). Each time rand() is seeded with the same seed, it
must produce the same sequence of values."

2. The CID speaks for itself: "'rand' should not be used for security-related
applications, because linear congruential algorithms are too easy to break."

*But* this is an area of contention.

One could argue that a CSPRNG is warranted in order to fully mitigate any
potential timing attacks based on crafting chunk responses. Others could argue
that the existing LCG, or even an MTG, would suffice (if properly seeded). As a
compromise, I've used an MTG with a full bit space. This should give a healthy
balance of security and speed without relying on the existing crypto library
(which I'm told might break on some systems since epee is not (shouldn't be)
dependent upon the existing crypto library).
2019-09-08 01:14:39 +00:00
..
demo default initialize rpc structures 2019-03-04 22:38:03 +00:00
include epee: abstract_tcp_server2: resolve CID 203919 (DC.WEAK_CRYPTO) 2019-09-08 01:14:39 +00:00
src epee: connection_basic: resolve CID 203916 (UNINIT_CTOR) 2019-09-06 23:18:00 +00:00
tests default initialize rpc structures 2019-03-04 22:38:03 +00:00
CMakeLists.txt Update 2019 copyright 2019-03-05 22:05:34 +01:00
LICENSE.txt year updated in license 2015-01-02 18:52:46 +02:00
README.md year updated in license 2015-01-02 18:52:46 +02:00

epee - is a small library of helpers, wrappers, tools and and so on, used to make my life easier.