[HN Gopher] Three mistakes from Dart/Flutter's weak PRNG
___________________________________________________________________
Three mistakes from Dart/Flutter's weak PRNG
Author : gnabgib
Score : 66 points
Date : 2024-12-13 08:05 UTC (14 hours ago)
(HTM) web link (www.zellic.io)
(TXT) w3m dump (www.zellic.io)
| robin_reala wrote:
| I'm not a Dart fan so maybe I'm biased, but wow this (from the
| article) is a failure on many levels: https://github.com/dart-
| lang/sdk/issues/56609
| nickcw wrote:
| From the code in the issue // TODO: Make this
| actually random static int _initialSeed() =>
| 0xCAFEBABEDEADBEEF;
|
| Oops.
| orr94 wrote:
| That TODO was committed on 2022-02-16 and wasn't fixed until
| 2024-09-2. That is... a long time for something that
| critical.
| abenga wrote:
| Oops indeed. I like using FIXME for such to make it stand out
| it's a deficiency that should be fixed asap (usually before
| merging the change altogether) compared to TODOs that are
| improvements that can be implemented in a more leisurely
| fashion.
| swatcoder wrote:
| No, it's totally overblown. As discussed in the comments on
| that issue as an example, the failure was in whoever wrote
| Flutter's `uuid` feature.
|
| It's simply incorrect for them to have naively used a PRNG
| there, regardless of whether it has a static seed or not. They
| should have used Random.secure all along, and anyone working in
| a cryptographically sensitive module, like `uuid` should be
| familiar enough with the distinction to make the right choice.
|
| There's nothing especially harmful about having that static
| seed and there are even some diagnostic and debugging
| advantages offered by it. Shuffling the seed on init is a
| generous convenience for people who want to make sure there's
| more per-run variety in their randomness without setting a seed
| themselves, but (when using in a non-secure context) it quickly
| doesn't matter since anything but toy programs tend to have
| enough complexity, branching, and data-dependency that the
| sequence of invocations isn't consistent anyway.
| klooney wrote:
| New languages should make sure the default random() is
| cryptographically secure, and hide PRNGs behind weakrandom() or
| repeatablerandom() or something. Safe and slow defaults are
| better than fast and unsafe.
| tobyjsullivan wrote:
| sane defaults is always the goal. The only problem is people
| can't seem to agree on what behaviour is "sane".
| mjw1007 wrote:
| So don't have a default. Have securerandom() and
| insecurerandom() and make the programmer choose.
|
| That has the advantage of avoiding problems in a generation's
| time: if most platforms moved to random() being secure, it
| would be excusable if young programmers started assuming that
| would be the case on older platform too.
| benatkin wrote:
| It's already implied by the presence of secure_random and
| it isn't insecure when it's being used for the appropriate
| use case.
| gwbas1c wrote:
| Rust does this.
|
| IMO, it's not worth it: It makes working with random numbers
| very problematic when working on cryptographic use cases.
| ivanbakel wrote:
| Could you clarify this? What problems would you run into just
| from having the default RNG be secure?
| gwbas1c wrote:
| Performance / getting a seed
| ironhaven wrote:
| Why is the default thread_rng from the rand crate a
| dealbreaker for rust? There are other rngs to choose from
| with like `smallrng` that is a small fast unspecified
| default prng if you don't know what you want even for a
| prng. If the worst case 300 microseconds of the reseeding
| ChaCha12 default rng is measurable, then it is your job
| to make a decision about your random number generator.
|
| I don't think rng seeding has anything to do with the
| algorithm you choose? Seeding from the os rng is usually
| what you want even for a prng. If you want to use use the
| current time there is a `seed_from_u64` if you want.
| gwbas1c wrote:
| Too late to edit: I meant non-cryptographic use cases
| goodburb wrote:
| 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)
|
| [1] https://api.dart.dev/dart-math/Random/Random.secure.html
| zamadatix wrote:
| 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.
| cryptonym wrote:
| Or avoid ambiguity and remove the default random().
|
| - randomWeak() - randomSecure()
| dgroshev wrote:
| There is nothing wrong with PRNGs, they are perfectly
| cryptographically secure when used correctly. In fact, AES-CTR
| is just XORing the plaintext with a pseudo-random generator
| (AES'd counter + initialiser). The problem is bad and misused
| PRNGs.
| SAI_Peregrinus wrote:
| In context I read PRNGs as being compared to CSPRNGs. CSPRNGs
| should be the default.
| loeg wrote:
| GP is using "PRNG" to mean "the subset of PRNGs that are not
| CSPRNGs."
| goodburb wrote:
| Why did Proton and SelfPrivacy use Random instead of
| Random.secure?
|
| DTD is local host or over SSH due to the unecrypted websocket.
|
| Browsers block unsecure WS over HTTPS. The key generated is for
| tagging multiple instances per IDE not security.
|
| Random is instant and is used for _runtime_ collision prevention
| and performance especially UI, not uniqueness, PRNG is not truly
| random anyways.
|
| Random.secure has a large overhead accessing OS entropy and isn't
| always supported. [1]
|
| Go 'math/rand', python 'Random', C# 'Random' to name a few are
| also not unique or safe for crypto.
|
| Their secure equivalents: Go 'crypto/rand', Python
| 'SystemRandom', C# 'RNGCryptoServiceProvider'.
|
| This isn't a Dart or Flutter issue [0]:
|
| "A generator of random bool, int, or double values.
|
| The default implementation supplies a stream of pseudo-random
| bits that are not suitable for cryptographic purposes.
|
| Use the Random.secure constructor for cryptographic purposes."
|
| [0] https://api.dart.dev/dart-math/Random-class.html [1]
| https://api.dart.dev/dart-math/Random/Random.secure.html
| swatcoder wrote:
| Yeah, it's a weird critique.
|
| The author acknowledges early on that `Random.secure` is there
| to provide randomness where it _needs_ to be secure, but then
| spends the entire article fretting over how the _other_ source
| of randomness isn 't. But it's not supposed to be!
|
| Applications have plenty of reason for cheap, stable, or
| otherwise controlled forms of randomness and shouldn't have to
| pay the penalty for -- or face the reproducibility limitations
| of -- secure randonmness when that's not what they need. It's
| both useful and traditional for standard libraries to either
| include both forms, or to leave the secure form for other
| libraries to contribute.
|
| If an application uses the wrong supply of randomness for their
| needs, that's an application error. And if developers writing
| security-sensitive code don't know to think anticipate this
| distinction and avoid the error, then that sounds like there
| was a project management error in assigning them such a
| sensitive task.
| ivanbakel wrote:
| Well the article still has a point in that the insecure PRNG
| is neutered for seemingly no reason, contrary to developer
| expectations.
|
| But I think we should, as language developers and users, be
| well beyond the point of pushing out and accepting insecure
| defaults with a little documentation disclaimer - especially
| if even the Dart developers themselves can't catch misuse of
| their own insecure APIs in widespread tools.
|
| At the end of the day, we don't live in a computing world
| where true randomness is that resource-intensive anymore, and
| user-facing applications should basically always be relying
| on it. Non-randomness should really be the opt-in, when
| developers can actually justify that the performance penalty
| is a problem. Otherwise, I don't need library authors
| prematurely optimising my programs at the cost of security.
|
| (There is a similar related discussion to have about the
| pervasiveness of floating points in programming languages
| when most applications would be better served by a more
| expensive, but more precise, numerical representation - since
| they rarely do _that_ much calculation.)
| orf wrote:
| It's not random, that's the point. If you neuter it so much
| that it's only useful for a specific use case then make sure
| it's named something relevant and specific related to that
| use case!
| colmmacc wrote:
| When I wrote a Random class for use at Amazon, I made
| SecureRandom (which couldn't be seeded, and was a multi-source
| DRBG) the default, and you had to intentionally choose
| InsecureRandom. This is how it has to be, and in this case
| there should only be Random, and Random.insecure IMO.
| SSNLF wrote:
| I'd say it's because Proton does not employ actual
| cryptographers or security engineers. They do seem to have a
| lot of marketing folk, interns, and particle physicists,
| allegedly.
| rumori wrote:
| PRNG = pseudo-random number generator. I think it would have made
| sense to spell it out in the first sentence and go with the
| acronym from then on. Like the author does it with multiply-with-
| carry (MWC). Makes it more readable and consistent throughout the
| article.
| tptacek wrote:
| This is weird, since it reads as a critique of the insecure
| random number generator in a language that has a secure random
| number generator. What does it mean for the insecure random
| number generator to be insecure? That's the point: it's the one
| you use when security doesn't matter, because you need speed or
| determinism.
| matthewdgreen wrote:
| With any question like this, the path to an answer follows
| three intermediate questions:
|
| 1. Was there a security problem that resulted from the use of
| this insecure generator?
|
| 2. Were the developers who encountered this problem completely
| unreasonable and in the wrong, or were they simply
| non-(security)-experts who developed software that happened to
| have a security vulnerability?
|
| 3. If the latter, did the language/toolkit strongly encourage
| developers to use an insecure generator -- e.g., by making an
| insecure generator the default or "simpler" option (such as
| Random() instead of Random.secure()).
|
| 4. Is there some broad and general understanding that this
| toolkit is _only_ intended for applications, such as monte-
| carlo testing or graphics rendering, where performance at the
| cost of security will _always_ be the correct solution?
|
| Given that the authors are able to offer several examples of
| real security vulnerabilities caused by developers using an
| insecure PRG, I'm going to read the answers as (1) Yes, (2) not
| unreasonable, (3) Yes, (4) I don't think so.
|
| The decision to make _insecure_ RNGs the default creates
| security vulnerabilities. This is demonstrable and has broad
| and unpredictable effects, given that developers are not
| security experts. The decision to make _secure_ RNGs the
| default (easier path) has exactly one implication, which is
| that a small number of specialized applications will have
| slightly worse performance, performance that can easily be
| improved by making a conscious decision to remove the secure
| RNG.
| tedunangst wrote:
| Wait. Developers consciously chose to use this random because
| they believed it had a 64 bit seed? That's still wrong. It's
| irrelevant that it was truncated to only 32 bits.
| tptacek wrote:
| That may be, but having the default generator be non-
| cryptographic has been the conventional design choice in
| languages since the dawn of time. I would get the willies
| seeing security-sensitive code using "Random()" even if you
| told me in your language "Random()" was a CSPRNG.
| swatcoder wrote:
| I think most very experienced engineers would strongly
| disagree with you on (2) and would laugh at the usage
| characterization you make in (4).
|
| On #2: The difference between a PRNG and a cryptographically
| secure random number generator is foundational knowledge for
| software engineers, and there's (finally) a strong trade
| consensus that writing security-sensitive code has a higher
| bar of preparation and shouldn't be done naively. It's
| _entirely_ unreasonable that someone writing a `uuid`
| implementation that 's meant to be a cryptographically secure
| library for use by application developers wouldn't anticipate
| that their standard library would offer both and would
| prioritize the PRNG as its basic and most accessible
| generator.
|
| On #4: It's very rare that an application developer _needs_
| direct access to a cryptographically secure random number
| generator, especially because of that trade consensus that
| security-sensitive applications deserve expert care. In
| contrast, application developers are building test data
| pools, shuffling arrays, adding noise to signals, adding
| surprise to gameplay, writing and running reproducible tests,
| etc _every day_ and naive use of a cryptographically secure
| random number generator in those contexts is easily
| paralyzing and catastrophic. The overhead can be order of
| magnitude in measure (which matters quite a lot in typical
| highly-repetitive /looped usage), and in some implementations
| it can introduce non-deterministic and potentially indefinite
| blocks on execution. And because they specifically can't be
| made deterministic by design, they significantly frustrate
| debug and test efforts that benefit from reproducibility.
| They're an essential tool in modern standard libraries, when
| they're needed in unusual cases, but are not suitable for
| naive everyday use at all.
| tptacek wrote:
| The person you're responding to is pretty familiar with the
| space you're commenting on, for whatever it's worth to you
| to know.
| swatcoder wrote:
| Hah! Thanks for bringing that to my attention. :)
| tptacek wrote:
| I missed it too (sorry, Matt) --- I wrote my comment in
| bed half awake (I have a problem) and without glasses
| (I'm old) I can't see for shit.
| matthewdgreen wrote:
| I think the following statements are entirely compatible
| with one another:
|
| * Most software developers (let's say, 95-99%+) _are_ smart
| enough to avoid using insecure PRGs in their code.
|
| * The remaining 1-5% have contributed to a litany of
| avoidable security disasters, nonetheless.
|
| * The impact of these disasters has been vastly outsized
| when you compare it to the number of bad developers.
|
| * If every developer understood that they needed security
| expertise (and indeed, that they were even writing
| _security critical code_ , the world would be a very
| different place than it is.)
|
| As Thomas mentioned below, I am something of a collector
| and obsessive when it comes to incidents of bad random
| number generation. What's fascinating to me about this
| Dart/Flutter story is not the result, it's that _I haven 't
| seen one of these stories in a long time!_
|
| By this I mean: this type of incident used to pop up on HN
| every month or so, and yet in the past few years they've
| become incredibly rare. And do you know why that is? It is
| _not_ because developers got better. It 's almost entirely
| due to the fact that development frameworks (particularly
| JS in browsers) have made a multi-year and systematic
| effort to reduce the availability of insecure default PRGs
| to bad developers. The result is that an entire bug class
| has gone from a common, monthly occurrence, to a relative
| rarity.
|
| The idea that we should use insecure default RNGs because
| _they 're good for reproducible testing_ is a new one on
| me. If you need reproducible random numbers for your
| application, but you are asking to use an interface that
| _does not explicitly include the fact that it generates
| non-random, reproducible numbers_ then you are doing both
| software development and testing wrong, IMHO.
| swatcoder wrote:
| > this type of incident used to pop up on HN every month
| or so, and yet in the past few years they've become
| incredibly rare. And do you know why that is? It is not
| because developers got better. It's almost entirely due
| to the fact that development frameworks (particularly JS
| in browsers) have made a multi-year and systematic effort
| to reduce the availability of insecure default PRGs to
| bad developers. The result is that an entire bug class
| has gone from a common, monthly occurrence, to a relative
| rarity.
|
| That's a fair take and worth considering.
|
| I suspect this whole dilemma speaks to a widening divide
| between those who see security as the top and inviolate
| priority in modern software and those still seeing
| software as something with much more varied and
| heterogenous concerns. And that gap gets most contentious
| when it comes to what things like what should be
| considered default, what capabilities should be available
| altogether, how convenient those features should be made,
| what emphasis should be made in
| education/training/mentorship, etc.
|
| Undoubtedly, (often sloppy) network-delivered and
| network-attached software has come to dominate the
| industry and with it the consequences of security-
| practice lapses have become be more severe than they once
| had been. But at the same time, we can watch as things
| like correctness, stability, resource-efficiency,
| performance-efficiency, maintenance/repair-ability, etc
| tumble away and turn much of the same software into
| byzantine garbage that barely runs on X-core YYY-ghz
| hardware with ZZ-gigabytes of RAM and faults have the
| time when it does.
|
| So I think there's a real tension, but I get where you're
| coming from. It may in fact be true that making a seeded
| PRNG less easily available would be a wise favor to the
| security-first-and-always people. :D
| sdenton4 wrote:
| Seems like a lot of grief could be avoided if the default was
| the secure rng... If the insecure one is faster or something,
| call it random.weak() or something.
| shwaj wrote:
| It's possible that the secure rng incorporates observed
| entropy; there might not be enough entropy available when you
| need it, if secure is made the default and therefore used
| unnecessarily.
| tptacek wrote:
| No, in this setting, this is not a thing: the secure
| generator, if it isn't literally just a wrapper around the
| OS secure RNG (which it ideally is) is seeded from that
| RNG. Userland code doesn't observe entropy at all; you are
| in a state of grave sin if your userland program is trying
| to do that.
| swatcoder wrote:
| No, they don't mean that that the application would need
| to be observing entropy on its own.
|
| They're acknowledging that cryptographically useful
| entropy is a limited resource for the system as a whole,
| and naive exhaustion can either causes starvation,
| unbounded blocking, or degradation depending on the
| implementation.
|
| Having a casual array shuffle seize up because there's
| not enough secure entropy available might just be an
| absurd nuisance in many cases. But having an session key
| or uuid generator seize up because somebody burnt all the
| entropy on casual array shuffles can be a real problem
| for users. (And much worse so if the implementation just
| silently degrades in quality instead of blocking or
| failing, as some have done.)
| loeg wrote:
| "Useful entropy as a limited resource" is just an
| incorrect meme that has somehow brainwormed a significant
| fraction of engineers. Once that secure RNG is seeded,
| you're golden. Randomness is not depleted.
|
| Every mainstream OS is trivially capable of seeding the
| system secure RNG by the time userspace applications need
| to consume it. There is no availability / depletion
| problem for userspace.
| swatcoder wrote:
| That's absolutely not true, and some of us have directly
| experienced what happens when it runs out. There are
| implementations that will keep producing output without
| an ongoing and sufficient supply of fresh entropy, but
| there are also implementations that do not. Generally,
| those that do keep producing output in those cases are
| formally weaker.
|
| When the supply is treated conscientiously, depletion
| broadly doesn't matter outside of weird race conditions
| during system startup. But if everybody naively consumes
| cryptographically secure randomness for every casual
| occasion, it becomes a much bigger problem.
| tptacek wrote:
| No, it's definitely true. A conventional OS CSPRNG can be
| effectively modeled as a stream cipher, where the key is
| a hash of observed entropy. As you encrypt more bytes
| with a stream cipher, you don't "deplete key". Real
| CSPRNGs are more complex than this, but that complexity
| is there to improve things from the baseline of "hash
| some interrupts and key ChaCha20 with it"; the argument
| gets weaker on real CSPRNGs, not stronger.
|
| The parent comment is correct: entropy depletion is a
| weird meme. Unfortunately, Linux encoded that meme into
| its legacy KRNG ("/dev/random"), so lots of people
| believe it to be real. It is not, and modern userland
| programs don't use "/dev/random" anyways.
| swatcoder wrote:
| > Unfortunately, Linux encoded that meme into its legacy
| KRNG ("/dev/random"), so lots of people believe it to be
| real. It is not, and modern userland programs don't use
| "/dev/random" anyways.
|
| It's not the only such system, nor has that "legacy KPRN"
| been eradicated from real-world use.
|
| Moreso, I can't understand how someone who seemingly has
| as much seasoning and experience as yourself can fathom
| making generalizing claims like "modern userland programs
| don't X".
|
| Application software and the platforms that it runs are
| insanely more diverse than that, especially now that we
| live in a world where people just paste in verbatim
| docker stacks that they read about in some blogspam
| tutorial written 12 years ago, and countless others are
| building on frameworks and dependencies that are
| themselves broken in ways they oughtn't be (like Flutter,
| in the article).
|
| While there _exist_ contexts where cryptographically
| secure randomness may be treated as inexhaustible, we 're
| decades away from being able to take that for granted
| across "modern userland programs" and its much safer to
| have people anticipate the dangers of exhaustion than it
| is to have them presume its universally inexhaustible.
| tptacek wrote:
| "KRNG" => kernel random number generator.
|
| "LRNG" => (idiosyncratic) shorthand for "Linux's KRNG".
|
| The LRNG _never_ had the problem you 're alluding to.
| It's not as if the literature eventually found
| "inexhaustible" designs. They were never exhaustible.
| There is no such danger. You can get to this
| axiomatically by looking at how a CSPRNG works (again:
| it's effectively a stream cipher construction), or
| empirically by reading about it. Either way: no, you're
| wrong here.
| swatcoder wrote:
| As a project rescue specialist whose had to diagnose and
| treat exactly this issue more than once, I feel like I'm
| being gaslit, although I know that's not your intent.
|
| As recently as node 16 or 18 or so, which is still in
| real-world use despite its age, reaning on the real-word
| docker images that these projects use, it happens. And
| when it does, you can rightly guess that all the client's
| javascript developers were utterly perplexed specifically
| because they'd never heard of such a concern. But you
| point to the stack trace for when their call to uuid
| never resolves and provide all the documentation from
| familiar bloggers to help them wrap their heads around
| it, and voila -- the mysterious and catastrophic issue
| that's been plaguing them is suddenly remedied.
|
| As I said, I appreciate that exhaustion doesn't _need_ to
| happen in anything with an appropriate design. That 's
| genuinely great. But even if it's just a certain and
| inappropriate way of using the linux RNG in a certain
| window of Linux versions (and I'm not strictly convinced
| its even so narrow a scenario), that's a actually a
| pretty common real thing that real developers will
| continue to encounter in the wild for longer than any us
| might want, and not some baseless myth or meme.
| tptacek wrote:
| You're not being gaslit by me, but rather by older Linux
| kernels. There's no such thing as exhaustion. But there's
| a legacy kernel interface that _pretends_ there is. The
| implication of using it is that your program will
| randomly stall, because the kernel is (was) galighting
| you. But that 's not a cryptographic security issue.
|
| Honestly it's kind of refreshing to see a thread like
| this. This was a live issue on HN like 10 years ago, when
| cryptographers started yelling at Ted T'so about how dumb
| "/dev/random" was, and generalist engineers on HN argued
| about it. But it has since become a settled matter ---
| here, I mean. Among cryptography engineers: never a
| doubt.
|
| There are KRNG security issues! You can come up with
| cases, especially with embedded software or older
| hypervisors, where code runs with an _unseeded_ RNG. That
| 's very bad. But those issues aren't relevant to ordinary
| userland code; if your system can't run with the
| assumption that "/dev/urandom" is seeded, you're fucked
| for other reasons, so distributions (and hypervisors) go
| out of their way to ensure that can't happen.
|
| At any rate: there is _no_ case where "exhaustion" comes
| into play, and there never has been, but there was an
| archaic kernel interface in Linux that thought there
| could be such a thing, so there's a whole generation of
| Linux developers who believe it's a big deal. It is not.
| loeg wrote:
| No, you are mistaken, as were the Linux engineers who
| embedded that assumption into /dev/random. (That has been
| resolved on the Linux side for some time now.) I will
| claim (without evidence) to be a subject matter expert on
| this topic.
| swatcoder wrote:
| "It was an issue in Linux for a while, but isn't in
| recent kernels" is not really sufficient grounds for
| acting like it's not an issue.
|
| A language designer or library developer, especially,
| generally can't assert that their code will only run on
| the most robust, modern, popular systems currently
| available. They need to work defensively, anticipating
| the issues that they may plausibly encounter --
| especially where those issues will not be apparent to
| less expert application developers.
|
| And those less expert application developers are in an
| even worse position, because many barely even know what
| they're doing in the first place, making all kinds of
| foolish decisions while they paste together their docker
| script and relying on inexpert devops/sre people (or end
| users!) who make their own choices about what things are
| running on.
|
| It's encouraging to learn that there are now established,
| widespread, inexhaustibly secure RNG's out there. But it
| remains irrelevant to a discussion of what developers
| need to keep themselves mindful of because there remain
| many implementations in the wild that don't behave like
| that and most developers aren't in a position to
| guarantee which their code will encounter.
| tptacek wrote:
| No, there's really no space for wriggling here. You use
| getrandom() or, in the worst case, /dev/urandom, and this
| kernel nit goes away. It was _never_ the case that the
| LRNG was "exhaustible"; there was only a broken
| interface to it.
| loeg wrote:
| Personally, I forgot that Linux only fixed /dev/random in
| 2020 in kernel 5.6. That's not _that_ long ago in terms
| of enterprise / LTS kernels. I'm sure this has been a
| surprising pain point for end-users for a long time, and
| perhaps still is in some environments.
|
| (Yes, I know, you have shared a workaround for a long
| time prior:
| https://sockpuppet.org/blog/2014/02/25/safely-generate-
| rando... . But that sort of presumes a clued-in user.)
| 999900000999 wrote:
| >November 1, 2024 -- The Google Bug Hunters team decided to not
| reward nor announce this security fix, because it only affects
| developers.
|
| Good to know Google doesn't care about my security. Long time
| Flutter user, but Google expresses disdain for it at every
| opportunity...
|
| Might see if the C# mobile frameworks have caught up...
| keepamovin wrote:
| For a PRNG you should probably be using something like a good
| hash function that passes the SMHasher3 tests to generate it
| (which funnily enough I just posted now after a long overdue
| enhancement: https://news.ycombinator.com/item?id=42409577).
|
| Alternately develop something that at least passes all the
| Dieharder tests.
|
| There are many good options for a variety of requirements.
|
| Maybe the following perspective is missing some key context here
| (?) but when I skimmed the code for this, I was stunned that such
| a low quality algorithm was used by Zellic (some kind of high end
| cyber genius cabal, it seems) and in cryptocurrency purposes. I'm
| rarely harsh on projects here but bloody hell that's utterly
| stupid. Especially when there are so many good options.
| dgrove wrote:
| This feels like MilkSad.info and the 2020/2021 Cake Wallet flaws
| all over again
|
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-3991...
|
| https://milksad.info/posts/research-update-10/
| cmovq wrote:
| PRNGs are insecure by design, why does this article frame the
| problem as the implementation being insecure? Applications
| shouldn't use PRNGs if they need a true random source to begin
| with.
| colmmacc wrote:
| The only true random sources in the universe are quantum. But
| it's not practical or performant to hook your workload up to a
| raw quantum measurement like the spin of a fundamental
| particle, or radioactive decay.
|
| Instead we take sources that are still believed to be
| statistically random and influenced by underlying quantum
| randomness. E.g. RF interference, clock phasing, or an
| avalanche amplifier that are measures of entropy that is
| considered to be random to the same extent as say the ideal gas
| laws. But even those measures can still be imperfect; a probe
| might have a bias or manufacturing error that shows up later
| than QC.
|
| To cope with this, we have PRNG designs that can use mixed
| sources in ways that will provably debias any such errors from
| a single source, and remain secure. All modern RNGs use these
| kind of PRNGs or DRBG/NRBG designs as a last stage. Far from
| being insecure, they are what give us more confidence in the
| overall system.
| r2vcap wrote:
| Some missing timelines:
|
| December 11, 2024 - Dart SDK 3.6.0 has been released. December
| 12, 2024 - Flutter SDK 3.27.0 have been released.
___________________________________________________________________
(page generated 2024-12-13 23:01 UTC)