Results 1 ... 54 for 'entropy'...

Results 1 ... 54 found in asciilifeform for 'entropy'

cgra: otoh, the locking idea would make selfchains reliably distinguishable (assuming proper 'S-turd' entropy). instead, would somekinda chain claiming convention, where you send a standard message with a random string in it, similarly guarantee distinguishable selfchains?

thimbronion: I do my best to ensure max entropy

phf: signpost: but i've already i believe communicated why i don't agree with that finer point. specifically i just don't believe in eternal solutions, i think specifically that any system for controlling entropy will have upper bound on its operation, and it ought to be judged from the perspective of how well it did and how long it lasted. it sucks that we were born on the tail end of effective christianity though, perhaps get to enjoy

asciilifeform: phf: the folx who threw in the towel and 'entropy wins' have already wagnered & cyanided, asciilifeform aint there

phf: asciilifeform: i'll take a page from verisimilitude book and say that i reject the picture of the world you're painting. on blind faith and with no supporting argument. i simply do not accept that the entropy wins :)

dulapbot: Logged on 2022-03-28 13:48:46 signpost: huh, does this mean early entropy is degraded on old platforms with this patch?

signpost: huh, does this mean early entropy is degraded on old platforms with this patch?

asciilifeform: ( the analogue entropy source aint clocked )

signpost: yep, not for nothing my mind went to "can the net entropy of the universe be decreased"

dulapbot: Logged on 2022-01-18 22:48:20 verisimilitude: Regarding a sane computer with an FG, it would be interesting to use volatile RAM to cache the FG output, up to some limit, so that it may temporarily be used at a greater rate than it can be produced. None of this would, or should, be backed up to disk, so there wouldn't be any issue. The only issue is it may result in a system not recovering from power failure as quickly as a lightbulb, were it needing heavy entropy.

verisimilitude: Regarding a sane computer with an FG, it would be interesting to use volatile RAM to cache the FG output, up to some limit, so that it may temporarily be used at a greater rate than it can be produced. None of this would, or should, be backed up to disk, so there wouldn't be any issue. The only issue is it may result in a system not recovering from power failure as quickly as a lightbulb, were it needing heavy entropy.

asciilifeform: this way : 1) neither A nor B can impose an arbitrary (possib. weak) key 2) the entropy of the new key is the max of sA, sB, and the old key.

dulapbot: Logged on 2021-09-07 14:59:14 asciilifeform: punkman: i.e. neither side must be able to force the new key to a constant value. or, if you like, to reduce its entropy below that of the better of the two xor halves.

asciilifeform: punkman: i.e. neither side must be able to force the new key to a constant value. or, if you like, to reduce its entropy below that of the better of the two xor halves.

asciilifeform: cgra: per 'xor lemma', distillation via xor cannot subtract entropy under any circumstances (aside from feedback!) -- hence if you have the time, it doesn't hurt.

cgra: asciilifeform: now that we're on topic, i've been for a while wanting to ask a q. at the bottom of nosuchlabs.com front page, you say "We recommend at least 24 hours of entropy distillation (solely via XOR-in-place !) if generating mission-critical, long-term cryptographic keys."

dulapbot: Logged on 2021-07-30 08:25:03 adlai: as for the old entropy question: working almost entirely off my readings of the past conversations on this, I'm surprised ~any~ peripheral built as an input device, in this case optical, is considered a good entropy source

adlai: as for the old entropy question: working almost entirely off my readings of the past conversations on this, I'm surprised ~any~ peripheral built as an input device, in this case optical, is considered a good entropy source

punkman: their blog post about the their rng https://medium.com/vault12/how-to-get-true-randomness-from-your-apple-device-with-particle-physics-and-thermal-entropy-a9d47ca80c9b

punkman: https://pthree.org/2017/12/22/the-entropy-of-a-digital-camera-ccd-cmos-sensor/ "when putting the generated binary files through the Dieharder tests, it comes out pretty bad. I get 20 "PASSED", 13 "WEAK", and 81 "FAILED" results."

raw_avocado: asciilifeform: i dont need a source of entropy for my use rn. i want to understand how these various methods would work, and how good they would be.

asciilifeform: raw_avocado: lemme get this straight, you simply need what, 256bits of entropy ? once ?

asciilifeform: raw_avocado: camera, in fact, is a fairly good source of entropy. but it gives great temptation to user, to pipe it directly through a hash, so to resemble a MB/s+ rng; but in reality it gives approx. same actual entropy as FG ( < 10kB/s )

raw_avocado: I am thinking, that cameras reduce noise when taking pictures, and thus reducing entropy, no?

raw_avocado: asciilifeform: some people telling me that selfies are a good source of entropy, and of course they hash these images

raw_avocado: asciilifeform: i read in some of your posts that you dont think whitening entropy is a good idea. Why?

raw_avocado: asciilifeform: what are good household sources of entropy? like coin tosses and stuff or lava lamps?

asciilifeform: bonechewer: you understand that the difficulty is actually coming up with a physical process which yields multi-MB/s of actual entropy, right ? not usb etc

adlai: shinohai: my guess, from having read similar papers, and the bit in the archive.is snapshot, is that the paper says absolutely nothing about sources of entropy, and deals only with proving the behavior of the function that it introduces.

asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2020-09-27#1022559 << btw that piece is epic, goebbels-level job, btw. damn near ~all~ of the assertions in it were outright lies ( from '256bits from urandom contain 256bits of entropy' to 'impossible to predict outcome from previous bits' to (implicit!) 'ALL rng must whiten' , etc )

shinohai: "I have these special dice, you see, that are injected with extra entropy. Not sold in stores, get them here exclusively for the low price of $99.95!"

adlai: regrettably Tel Avivis seem to think that you can just leave electrotrash either on the curb, or in the bin, and the entropy fairy will take care of it

trinque: asciilifeform: tell you what, to this day I mega-appreciate being able to generate bitcoin keys with a reliable source of entropy.

snsabot: Logged on 2020-02-05 17:08:54 asciilifeform: shinohai: i sincerely hope that mp et al actually try to bake this, it'll be hilarious to watch ( where signing e.g. linux kernel will need coupla 10,000s of rsa invocations, auto-recognition of 'what lang' so to get the comment & demarcation syntax, and coupld 10MB of entropy.. )

asciilifeform: trinque: correct. and no i dun expect it will 'bestseller' , but so happens that i need a MB/s+ source of entropy for certain other planned experiments. and so will be produced (and published.)

adlai: the method being one using only a single high-entropy ring, or alternating between a small set of high-entropy rings from likely-nonconsecutive units?

adlai: Apocalyptic: why would a high-entropy factor from an arbitrary garbage modulus containing small factors be any more likely to recur in other sabotage attempts?

asciilifeform: ( tho in verification you dun have to wait for entropy gen, unlike in signing. but do have to do a hash & modexp for each signature )

asciilifeform: this of course also assumes that generation of entropy is instantaneous..

asciilifeform: shinohai: i sincerely hope that mp et al actually try to bake this, it'll be hilarious to watch ( where signing e.g. linux kernel will need coupla 10,000s of rsa invocations, auto-recognition of 'what lang' so to get the comment & demarcation syntax, and coupld 10MB of entropy.. )

snsabot: Logged on 2020-01-21 03:36:17 Apocalyptic: while I can see how a proggy like peh could benefit from reading directly fg output, if you want to provide entropy for multiple non-critical programs, having a /dev/random-like pool isn't that wrong imo

Apocalyptic: while I can see how a proggy like peh could benefit from reading directly fg output, if you want to provide entropy for multiple non-critical programs, having a /dev/random-like pool isn't that wrong imo

mike_c: asciilifeform: have you written up how you envision crypto-routed net? I wonder if key rotation with FG as entropy source would be sufficient

asciilifeform: mike_c: naturally would integrate 'reliable entropy' into any such.

mike_c: a piece of hardware with reliable entropy, another with reliable math, that's a couple of strong building blocks!

snsabot: Logged on 2020-01-07 00:27:12 shinohai: WARNING: The '?' command will use DEFAULT entropy source : /dev/random !

shinohai: WARNING: The '?' command will use DEFAULT entropy source : /dev/random !

asciilifeform: if one insists, for whatever reason, on manipulating rng output via e.g. hashes, do it on software end. but don't lie to the purchaser of the iron and say that sha(whatever) is 'entropy', sha(1234....infinity) will fool 100% of mathematical 'entropy test' while being cryptographically worthless just the same.

verisimilitude: You're very convincing, with your criticism of ``whitening''. So you rightfully believe the device should return the entropy directly, which is easier to audit.

asciilifeform: in general, if you can't physically pull off the analogue end (i.e. the part that actually gathers entropy) & replace w/ own, it's rubbish

asciilifeform: being an entropy collector, FG ~likes~ heat. put'em near warm things, like e.g. raid card as shown in latter link