-
Notifications
You must be signed in to change notification settings - Fork 135
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
Comments
Hi, Are you looking to do something certifiable with it? For example: MW |
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 :-).
|
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 |
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. |
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. |
@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. |
@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! |
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:
The text was updated successfully, but these errors were encountered: