Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FortunaRandom implementation #75

Open
vdeurzen-bux opened this issue Jan 21, 2021 · 7 comments
Open

FortunaRandom implementation #75

vdeurzen-bux opened this issue Jan 21, 2021 · 7 comments

Comments

@vdeurzen-bux
Copy link

I was curious about my usage of the FortunaRandom class and wanted to check if I used it correctly. I did a bit of digging and read through a fair part of the description by Bruce Schneier (https://www.schneier.com/wp-content/uploads/2015/12/fortuna.pdf) as well as the implementation in PointyCastle.

From what I can tell, the implementation in PointyCastle does not (entirely) follow the algorithm as described by Schneier. I'm wondering if this is intentional or whether I'm missing something?

Things I'm missing specifically:

  • Different pools of entropy from where the block cipher is reseeded (re-keyed).
  • Updating the pools of entropy.
@mwcw
Copy link
Collaborator

mwcw commented Jan 22, 2021

Hi,

Are you looking to do something certifiable with it?

For example:
https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final

MW

@vdeurzen-bux
Copy link
Author

Hi,

I'm not entirely sure I fully understand your question in this context. My main question is effectively, why is the name FortunaRandom used, when (at least to me) it looks like it does not implement the Fortuna algorithm?

I'm working on an application that needs to generate the seed for a key which will be used to co-sign requests. I don't expect it will be certified, but I do want to ensure I use and implement the best security practices I can reasonably achieve. The name implementation mismatch is unexpected, so I want to check if there is a rationale that explains it :-).

  • vdeurzen

@mwcw
Copy link
Collaborator

mwcw commented Jan 26, 2021

Ok, sorry,

Honestly I cannot answer that, we have only just adopted the project that was started by someone else.

Myself or someone else will try to get to it when we can.

MW

@vdeurzen-bux
Copy link
Author

No worries, I guess this issue then simply serves to ask that someone at some point looks at this. Thank you for answering my questions, feel free to close the issue if you think that makes sense :-)

vdeurzen.

@AKushWarrior
Copy link
Contributor

AKushWarrior commented Feb 5, 2021

As far as I can see, you're right. The implementation follows the Fortuna instructions for generation, but accumulation/seeding are using some completely foreign construction. I'm not even sure how initial seeding is handled; it looks like the algorithm isn't even using a source of entropy (which is, of course, absurd, considering that it does produce keys that are pseudo-random at some level).

Fortuna itself seems to be a low-level algorithm, primarily designed for systems which have direct mechanical access to sources of entropy. I don't see its application to a high-level compiled language like Dart (especially as Dart does not have a dedicated host around which the accumulator can be designed).

I think the best method going forward is to implement Ansi X9.17, HMAC-DRBG, or some other construction with proven security properties and less implementation ambiguity. In fact, just using ChaCha20's keystream with a source of entropy (Dart Random.secure()) has provable security properties.

@AKushWarrior
Copy link
Contributor

@vdeurzen-bux I did some more digging. The algorithm is mis-named (and one could argue only a single building block in the larger Fortuna algorithm). The algorithm currently labeled Fortuna is actually the Fortuna generator, and does not handle seeding at all. Essentially, users have to pass in the seed (which would ideally be accumulated using Fortuna's accumulator, but realistically will be gathered using Dart's Random.secure() class), and then results will be produced based on Fortuna's (proven, cryptographically secure) PRNG.

I don't think there's a fundamental algorithmic issue with the implementation so much as there is as a branding issue with calling it the "Fortuna algorithm" (when it's really a subset of that). Regardless, providing more standardized algorithms can't be a bad thing, so I'll still work on implementing HMAC-DRBG.

@vdeurzen-bux
Copy link
Author

@AKushWarrior Thank you for confirming it's indeed incorrectly named. As far as I could tell, thank you for expanding on this, if the user seeds the generator properly (using Random.secure() in this case) then at least the first value that's generated should behave as expected from Fortuna and should be 'OK'.

I agree it's a good idea to have more standardized and appropriate algorithms in place, glad to hear you will pick that up!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants