Git Product home page Git Product logo

Comments (6)

BenWiederhake avatar BenWiederhake commented on July 24, 2024

What's the difference between using 32 bytes of random data (thus seeding it from the OS's PRNG) and your proposed method? The only difference I can see is removal of the seed-through-file feature, and the bare minimum guarantee (time, PID, and hw counter which you didn't mention).

from tgl.

nopjmp avatar nopjmp commented on July 24, 2024

Sorry for my lack of detail as I'm not a cryptographer, but from what I've read, you should never use the time, PID or a hw counter to seed PRNG. The systems PRNG system is able to take in more random sources such as Ethernet interrupt timing and keyboard / mouse input. This isn't very good on embedded hardware, but its better than using the time and/or pid.

from tgl.

majn avatar majn commented on July 24, 2024

From the OpenSSL documentation:

OpenSSL makes sure that the PRNG state is unique for each thread. On systems that provide / /dev/urandom, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling RAND_add(), RAND_egd or RAND_load_file.

So basically, there is no point in seeding with /dev/urandom, OpenSSL already uses that device to ensure that the randomness source is properly seeded.

from tgl.

nopjmp avatar nopjmp commented on July 24, 2024

Is there any reason we should be using RRAND_add() with PID and time data then? I'm not aware of any modern systems without /dev/urandom.

My point is tgl has a function tgl_prng_seed that calls RAND_add with data from PID, time and /dev/random. Almost all systems with a /dev/random will have a /dev/urandom.

from tgl.

majn avatar majn commented on July 24, 2024

I'm not aware of any modern systems without /dev/urandom

Windows, but OpenSSL handles that case too ;)

My point is tgl has a function tgl_prng_seed that calls RAND_add with data from PID, time and /dev/random. Almost all systems with a /dev/random will have a /dev/urandom.

I guess that those are still fine for additional strengthening, since add_random only adds to the entropy and doesn't "replace" the old random values. Even when they can be guessed it won't do any harm. If we propose any change, we should just remove the pointless calls to /dev/random and /dev/urandom.

from tgl.

BenWiederhake avatar BenWiederhake commented on July 24, 2024
but from what I've read, you should never use the time, PID or a hw counter to seed PRNG

Nearly. There is one extremely important detail, as in "this-is-the-thing-that-might-break-your-neck":

You should never use only the time, PID or a hw counter to seed a PRNG.

Since we use "secure" sources (explicit entropy from /dev/{,u}random and implicit from crypto-library boot), it doesn't really matter whether we also throw in the PID and time in addition to these other sources.

For completeness, let's analyze each part:

  • The not-guessable-but-low-entropy stuff like time, PID, hw counter gives a lower bound, even though it would be too low if we were to use it stand-alone. I think it's nice-to-have.
  • The thing that I called "implicit entropy" (done during boot of the crypto lib, either OpenSSL or gcrypt) is everything we need, and there is no point in going beyond that if you trust that this code is called properly. However, I don't trust that it is called at the right time. OpenSSL is weird, gcrypt is never initialized explicitly from tgl nor telegram-purple, and it would need a lot of documentation to even prove that this initialization should happen with out way of using it.
  • The thing that I called "explicit entropy" (copying from /dev/{,u}random) is again everything we need, and there is no point in going beyond that if you trust the OS PRNG. I do so, because otherwise you can't trust anything.

The only thing I would modify is the reading of /dev/random: It's pointless. There is exactly one difference between urandom and random, and that is: One device always returns something of high-quality (/dev/urandom!), the other one only if some arbitrary counter feels like it (/dev/random).
And that's only a few lines and not really worth the trouble.

So if you really want to change anything from here, you'd have to convince @vysheng to fully trust the crypto library; both OpenSSL and gcrypt! Only then we can talk about completely removing /dev/{,u}random and pid/time/hw counter.

from tgl.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.