3 ms·

Arguably, rolling your own crypto (in this case AES which is customizable) requires a very careful implementation, beyond RNG. Since dart/flutter is multi plat

Arguably, rolling your own crypto (in this case AES which is customizable) requires a very careful implementation, beyond RNG. Since dart/flutter is multi platform, using Random.secure for animation has it's own performance issues with interfacing host entropy RNG. The majority of Dart/Flutter users are creating UI apps. Few browsers with security policies and OS combination does not allow access to the entropy with Flutter Web in which Random.secure will fail, this isn't exclusive to Dart/Flutter. [1] NaCL [0] offloads these concerns for developers, especially indie/startup. [0] https://en.wikipedia.org/wiki/NaCl_(software) https://en.wikipedia.org/wiki/NaCl_(software) [1] https://api.dart.dev/dart-math/Random/Random.secure.html https://api.dart.dev/dart-math/Random/Random.secure.html

zamadatix 2y ago
Rolling your own security requires nothing more than gumption and willingness to deploy. That doesn't mean it's good security but it means people will do it whether they know all the golden rules. After all, rolling insecure security requires missing 1 small thing in a haystack of thousands and it doesn't matter you reviewed the language defaults when OS version blah blah from vendor xyz defaults to something insecure "because you should have checked the defaults". The same goes towards "this library does these kinds of things so there is no value in languages having secure defaults too" type thinking, they aren't convincing arguments for what security posture of other things should or shouldn't be. I'm more a fan of "make the defaults as secure as you can reasonably expect to get away with for each step of the way". It'll never be as secure as everyone wants but if you but up against "it's as secure as people would want to put up with by default" then things are at least at a good starting point for others to build from. The hard part is finding out what people are willing to put up with and which tradeoffs are worth it. That default random number generators "only" go at GB/s on most PCs because they produce really good random numbers is probably an easy tradeoff though.

zamadatix 2y ago

Rolling your own security requires nothing more than gumption and willingness to deploy. That doesn't mean it's good security but it means people will do it whether they know all the golden rules. After all, rolling insecure security requires missing 1 small thing in a haystack of thousands and it doesn't matter you reviewed the language defaults when OS version blah blah from vendor xyz defaults to something insecure "because you should have checked the defaults". The same goes towards "this library does these kinds of things so there is no value in languages having secure defaults too" type thinking, they aren't convincing arguments for what security posture of other things should or shouldn't be. I'm more a fan of "make the defaults as secure as you can reasonably expect to get away with for each step of the way". It'll never be as secure as everyone wants but if you but up against "it's as secure as people would want to put up with by default" then things are at least at a good starting point for others to build from. The hard part is finding out what people are willing to put up with and which tradeoffs are worth it. That default random number generators "only" go at GB/s on most PCs because they produce really good random numbers is probably an easy tradeoff though.