log☇︎
700+ entries in 0.424s
mircea_popescu: should i need entropy i'd rather wotbuy it than os-"make" it
mod6: put up 1.5Gb of entropy... start the bidding at say 1mn ecu
mircea_popescu: might be a market in "Certified entropy" simply because of how bureaucracy works.
asciilifeform: neither will create entropy from thin air. but one destroys, other -- not
mircea_popescu: if they're happy with hash(x) can get entropy right now by curl google.com > sha512sum.
asciilifeform: esp. considering that we aren't speaking of cryptographic (noshit!) entropy, but, for, e.g., montecarlo
asciilifeform: mod6: and the folx who didn't pay, cannot distill entropy from your ciphertext because ..?
mod6: http://btcbase.org/log/2017-05-25#1661674 << was thinking there, for those who would want it, a model where guy asks for N bytes of entropy via FG. would generate N bytes. base64 encode the binary entropy file (similar to trb deps), place the sha512 output hash of the base64 decoded file along with the ent & dieharder output in a clearsigned message, then PGP encrypt it to the requester. ☝︎
a111: Logged on 2017-05-25 03:08 mod6: !~later tell gabriel_laddel_p Let me know how much entropy you'd like, I'll run ent test & dieharder against it, let you decide if you want it. I'll ask 0.1 BTC per Gb. What is your bid?
a111: Logged on 2017-05-25 03:08 mod6: !~later tell gabriel_laddel_p Let me know how much entropy you'd like, I'll run ent test & dieharder against it, let you decide if you want it. I'll ask 0.1 BTC per Gb. What is your bid?
mod6: !~later tell gabriel_laddel_p Let me know how much entropy you'd like, I'll run ent test & dieharder against it, let you decide if you want it. I'll ask 0.1 BTC per Gb. What is your bid? ☟︎☟︎
asciilifeform: the only improvement currently in the worx is the scintillator thing, which should give 1000x entropy debit ( and consequently 1000x faster testing, which is significant to asciilifeform who assembles and tests EACH UNIT BY MOTHERFUCKING HAND ) but that's really it.
mircea_popescu: it's so easy to make perfectly balanced faux entropy, only some very inept usg-ians would use anything else.
mod6: Here's the third entropy collection from FG #5: http://www.mod6.net/fg/fg-test/fg5.ent_run3.txt http://www.mod6.net/fg/fg-test/fg5.dieharder_run3.txt
Framedragger: asciilifeform: checked, yeah pretty amazing, damn; obviously lots of memory overhead depending on noise/entropy, but point is that it was actually something new, as you say, not just any optimisation
asciilifeform: 'purpose' in this sense is not an attribute of the object, but of the object-and-maker system. see also the thread re 'rng entropy'
mod6: Here's the results from the first entropy collection of FG #5: http://www.mod6.net/fg/fg-test/fg5.ent_run1.txt http://www.mod6.net/fg/fg-test/fg5.dieharder_run1.txt
mod6: Here's the results from the second entropy collection from FG #4: http://www.mod6.net/fg/fg-test/fg4.ent_run2.txt http://www.mod6.net/fg/fg-test/fg4.dieharder_run2.txt
mod6: Here's the results from the first entropy collection from FG #4: http://www.mod6.net/fg/fg-test/fg4.ent_run1.txt http://www.mod6.net/fg/fg-test/fg4.dieharder_run1.txt
a111: Logged on 2017-05-08 14:14 Framedragger: asciilifeform: are you planning on building an entropy source based on them, then? :) need a good uv light reader, or something?
Framedragger: asciilifeform: are you planning on building an entropy source based on them, then? :) need a good uv light reader, or something? ☟︎
mod6: Hi all: Ok 3rd run of entropy collection & `ent` & `dieharder` tests are done on FG #3: http://www.mod6.net/fg/fg-test/fg3.ent_run3.txt http://www.mod6.net/fg/fg-test/fg3.dieharder_run3.txt
mod6: at the end of the page it says "distill a days worth of entropy and xor in place"
asciilifeform: mod6: xor is the 1 operation where entropy is guaranteed-additive ( supposing the two items are independent! X xor X = 0 ! )
a111: Logged on 2017-05-04 03:12 mod6: here's the results from FG #3, second run of entropy collection1.1Gb worth. `ent` && `dieharder` results: http://www.mod6.net/fg/fg-test/fg3.ent_run2.txt http://www.mod6.net/fg/fg-test/fg3.dieharder_run2.txt
a111: Logged on 2017-05-04 03:12 mod6: here's the results from FG #3, second run of entropy collection1.1Gb worth. `ent` && `dieharder` results: http://www.mod6.net/fg/fg-test/fg3.ent_run2.txt http://www.mod6.net/fg/fg-test/fg3.dieharder_run2.txt
mod6: here's the results from FG #3, second run of entropy collection1.1Gb worth. `ent` && `dieharder` results: http://www.mod6.net/fg/fg-test/fg3.ent_run2.txt http://www.mod6.net/fg/fg-test/fg3.dieharder_run2.txt ☟︎☟︎
mod6: mircea_popescu, asciilifeform, et. al: Third FG, first run of entropy collection & testing of `ent` && `dieharder` complete: http://www.mod6.net/fg/fg-test/fg3.ent_run1.txt http://www.mod6.net/fg/fg-test/fg3.dieharder_run1.txt
shinohai goes back to filling his box with malicious entropy ....
Framedragger: check out alf's javascript http://www.loper-os.org/bad-at-entropy/manmach.js :) but yeah, good tool
mircea_popescu: but yes, i agree there's a huge difference between "spit out string hunter2 half tyhe time" and entropy eh
mircea_popescu: and check out the "min-entropy" "best strategy" thing on slide 10.
mircea_popescu: basically this tribe thinks that what shannon entropy is, is when P takes value "hunter2" in 50% of the cases and a random in the remainder of cases and therefore this is "no good for crypto because i can guess what your password will be".
mircea_popescu: can entropy in the physics sense predict anything ?
phf: afaiu shannon's entropy being a probability is descriptive, rather than prescriptive. so it can categorize a sequence of events, but it can't really say anything about how those sequence of events come about. so i'm not entirely sure how it even applies to engineering problem of event generation..
mircea_popescu: nobody is going to take the entropy bait are they.
mircea_popescu: <eightyeight> he clearly doesn't understand the differences between shannon entropy and entropy as defined by the 2nd law of thermodynamics
mircea_popescu: well, the guy is evidently not in the mood to indulge, but let's try this. "<eightyeight> his "Is there such a thing as better or worse entropy ?" paragraph is equally as painful to read
Framedragger: nice one mod6, entropy still at steady 8.0 bits per byte i see :D
a111: Logged on 2016-08-18 12:32 mircea_popescu: asciilifeform since we're on this btw, the way i want tmsr-rsa key generation to work is as follows : a contains a number of entropy bytes specified by user in tmsr-rsa.conf read whenever tmsr-rsa.conf specifies (such as urandom); b contains a base-tmsr string specified by user. c = base-tmsr(a).b ; p = nextprime(cut(sha512(c),257)) ; process is repeated for q = nextprime (cut(sha512(c'),258));
asciilifeform: (several min. on pc with no entropy bottleneck (i.e. FG present))
mod6: Ok update here... 2nd FG first entropy tests are in; collected ~1.2Gb. http://www.mod6.net/fg/fg-test/fg2.ent_run1.txt http://www.mod6.net/fg/fg-test/fg2.dieharder_run1.txt
mod6: I'm also running ent/dh against 1.2Gb of collected fg entropy, but this time I did it with: `dd iflag=fullblock if=/dev/ttyUSB0 of=fg1.fg4.bin`
asciilifeform: and each one is good for, by my current reckoning, a coupla MB/s of entropy.
mod6: Alright asciilifeform, mircea_popescu, et. al. Here's the 3rd run of the dh & ent against the third collection of ~1.1Gb of entropy. http://www.mod6.net/fg/fg-test/fg1.dieharder_run3.txt http://www.mod6.net/fg/fg-test/fg1.ent_run3.txt
mod6: third collection of ~1Gb of entropy is complete from my first fg. running ent & dh now...
mod6: also, collected another 1.1Gb of entropy from fg since yesterday.
mod6: not sure if I mentioned yesterday, but I did start a collection of another ~1Gb of entropy from the same fg as I wrote up the blog post about.
mircea_popescu: http://btcbase.org/log/2017-04-13#1642982 << such lulz that thing. really, looping over the entropy ? ☝︎
Framedragger tried fg last weekend, was all good, (very) small sample (2.7MB) had 7.999936 bits of entropy per byte. but yet to test more thoroughly, including removing shields, etc.
mircea_popescu: obvious example : does monotonous temperature variation result in more 1's ? something along the lines of "batch 1 we kept at 20, batch 2 we took from 0 to 40 over one hour, batch 3 we took from 40 to 0 over one hour. out of the 10gb worth of entropy recorded in that hour, batch 1 is 50-50 split, batch 2 is 75% 0s, batch 3 is 74% 1s.
mircea_popescu: did you do a mapping of temperature -> entropy or anything like that ?
BenBE: What's the entropy source used in those Cardano RNG?
asciilifeform: *max entropy from
asciilifeform: now the other, moar exotic, approach, is that you can try to extract mass entropy from background gamma
Framedragger: bots autoup folks there, use channel as funnel of good material into #trilema; or, bots calculate entropy of nicks outputting there, creating automatic pipeline.. horrible idea i know
Framedragger: heh, this is close to entropy (and inequality as 1/entropy)
asciilifeform: '(S//NF) All tools must utilize OS provided cryptographically secure sources of entropy (e.g., /dev/random on *nix, Microsoft CryptoAPI, etc) and should be a source compliant with NIST SP 800- 90. If a non-800-90 mechanism is used, the output from the source of entropy must be hashed with SHA-256 prior to use. Deviations from this must be justified and accepted by the OCRB.' -- 'Network Operations Division Cryptographic Requirements'
veen: how is /dev/fg not centralized entropy pool?
veen: seems gpg tried to sovereignty-wash a source of entropy and here it is bearing your criticism anyway
asciilifeform: veen: specificity-of-diddling. by using one centralized entropy pool that the os knows about, you make enemy's work slightly easier.
thestringpuller: "RAND_poll seeds the random number generator using a system-specific entropy source, which is /dev/urandom on UNIX-like operating systems" << so openssl default is PRNG??? RE: "The urandom device may lack sufficient entropy for your needs, and you might want to reseed it immediately from /dev/random. On Unix and other operating systems that provide the block device, you can use RAND_load_file to load directly from /dev/random."
mircea_popescu: openssl can't be trusted to actually use entropy in the first place.
a111: Logged on 2016-12-24 01:46 asciilifeform: mircea_popescu: all schemes where the transform is of 'payload itself' and 0 entropy, suffer from immediate 'penguin problem', https://blog.filippo.io/content/images/2015/11/Tux_ecb.jpg .
ben_vulpes: asciilifeform: can ssl or gpg be beaten into eating a specific file of entropy without patching them?
ben_vulpes: would be neat to dispense with linux' entropy estimates, etc
asciilifeform: frag-entropy, like other systemic problems with traditional bitcoin, is simply a result of misaligned incentives.
ben_vulpes: i'm down for scarification, but only the high-entropy kind that comes of abrading self against road
a111: Logged on 2017-01-04 08:14 davout: asciilifeform: lamport parachute generation hanging == not enough entropy available from /dev/random ?
davout: asciilifeform: lamport parachute generation hanging == not enough entropy available from /dev/random ? ☟︎
Framedragger: simple, high-entropy fingerprint of a computer. In fact, the hash of the rendered image can be used almost identically to a tracking cookie by the web server."
asciilifeform: Entropy = 7.965176 bits per byte.
asciilifeform: one of the hidden evils of 'of course generating key takes 10 minutes!' traditional entropy starvation -- is that nobody expects to be able to do the test where you generate 10 billion keys and make sure that the resulting keys have gcd of 1
asciilifeform: 3x was ~minimal inescapable bloat with no entropy~
mircea_popescu: pretty wasteful use of entropy.
asciilifeform: cheap entropy makes several interesting things possible, this is only 1 of'em.
asciilifeform: possibly we no longer bottleneck on entropy gather ?
mircea_popescu: i now have to a) generate 4kb of entropy (roughly enough for 8 4096bit rsa keys) ; b) complete 16k operations to pad ; c) execute a 5kb rsa exponentiation. so i'm looking at what, about an hour ?
asciilifeform: you gotta have the actual entropy.
asciilifeform: mircea_popescu: all schemes where the transform is of 'payload itself' and 0 entropy, suffer from immediate 'penguin problem', https://blog.filippo.io/content/images/2015/11/Tux_ecb.jpg . ☟︎☟︎☟︎
asciilifeform: the added entropy has to be ~genuine~ to do the job.
asciilifeform: which of course you don't want, it is quite obvious that there is no entropy in there if it only got 3x longer.
asciilifeform: take the bitstring to be 'padded' (that is, mixed with entropy in such a way that it destroys enemy's ability to know any part of the structure of a plaintext inside ciphertext.)
asciilifeform: mircea_popescu: and at what bitrate does user consume entropy to steer his harvester ?
a111: Logged on 2016-08-18 12:32 mircea_popescu: asciilifeform since we're on this btw, the way i want tmsr-rsa key generation to work is as follows : a contains a number of entropy bytes specified by user in tmsr-rsa.conf read whenever tmsr-rsa.conf specifies (such as urandom); b contains a base-tmsr string specified by user. c = base-tmsr(a).b ; p = nextprime(cut(sha512(c),257)) ; process is repeated for q = nextprime (cut(sha512(c'),258));
mircea_popescu: did you see the guy who had a "for free just as good version" consisting of buying a software radio thing (for slightly more than what FUCKGOATS costs) and you know, listening to man made "entropy"
ben_vulpes: and a pike of entropy sitting in the corner
asciilifeform: 'I thought that /dev/random (as opposed to /dev/urandom) was already based on entropy from physical noise, as recorded by sensors (I think including mouse, keyboard and temperature). Sounds like they're trying to make a big deal out of addressing a theoretical vulnerability, which is irrelevant in practice.' << glorious
mats: i remember now, there was a lack of entropy source
a111: Logged on 2016-08-18 12:32 mircea_popescu: asciilifeform since we're on this btw, the way i want tmsr-rsa key generation to work is as follows : a contains a number of entropy bytes specified by user in tmsr-rsa.conf read whenever tmsr-rsa.conf specifies (such as urandom); b contains a base-tmsr string specified by user. c = base-tmsr(a).b ; p = nextprime(cut(sha512(c),257)) ; process is repeated for q = nextprime (cut(sha512(c'),258));
shinohai: Entropy works in mysterious wayz
asciilifeform: in other ( https://archive.is/WOLLO ) lulz, 'When you take a look at the implementation of /dev/random in [freebsd] 11.0 you will notice that with the support of the new random algorithms (fortuna has replaced yarrow), there is also support to feed the entropy with a write call to /dev/random. The 10.x releases do not support this write call. The man page previously said for 10.3 that writes will be silently ignored and in the 11.0 m
mircea_popescu: asciilifeform i can't, not really. as pissed off as i/anyone can be, "What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has. What do you people think about removing those 2 lines of code?
phf: despite the schadenfreude, the amount of entropy is disconcerting
adlai: it should be ~unique each time you run the rng, but if your 'entropy' source is a piece of data (public key), doesn't your rng turn into a p-rng?
a111: Logged on 2016-09-27 16:39 mircea_popescu: this doesn't matter so much, future cryptosystem will be made on the basis of rng ; rng can work with pubkey as entropy source.
mircea_popescu: t2+epsilon : i publish key J in cryptosystem ? which was created with entropy = privkey.K
mircea_popescu: this doesn't matter so much, future cryptosystem will be made on the basis of rng ; rng can work with pubkey as entropy source. ☟︎
asciilifeform: in other 'news', heathen 'rng design' folk write what aaaaaalmost looked like good intro to subj, https://forum.stanford.edu/events/2016/slides/iot/Ben.pdf , until the mindfuck 'Want to keep generating entropy bits without needing to keep powering the HWRNG Use HWRNG to seed a PRNG (AES counter mode)...'
asciilifeform: macro ~removes~ pattern. as in increasing the entropy (per, say, kolmogorov, or even chaitin's criterion) of the program.