Thanks, maybe I'll connect on #trilemma. is it logged same as #b-a? (or are the logs you shared on http://btcbase.org not #bitcoin-assets?) no it's not urgent or something, just a funny story. on the xor lemma, like this: http://www.wisdom.weizmann.ac.il/~oded/COL/yao.pdf ? ("on yao's XOR-lemma") top result when you google xor lemma, I also attach it. honestly, I can't exactly understand the abstract The fundamental lemma of Yao states that computational weak-unpredictability of Boolean predicates is amplified when the results ofseveral independent instances are XOR together. We survey two knownproofs of Yao=E2=80=99s Lemma and present a third alternative proof.The thirdproof proceeds by first proving that a function constructed byconcatenat-ingthe values of the original function on several independent instances ismuch more unpredictable, with respect to specified complexity bounds,than the original function. This statement turns out to be easier to provethan the XOR-Lemma. Using a result of Goldreich and Levin (1989) andsome elementary observation, we derive the XOR-Lemma. I think my way of thinking about it depends on the idea of the one-time pad: if the xor with 1 source didn't totally clobber the entropy of the other sources, it would be like a one time pad leaving SOME entropy recoverable. obviously not possible, then it's a shitty one time pad process or not random enough. if you apply it it has to clobber everything. so I thought of it in these OTP sense. I looked at the patch you showed me. I think it's cool. but man, this license: Should you use this software for any purpose, +// or copy and distribute it to anyone or in any manner, you are breaking +// the laws of whatever soi-disant jurisdiction, and you promise to +// continue doing so for the indefinite future I mean it's funny I guess but. meh. trollish. it's all just a game isn't it? maybe the poiint is to "commit to be a criminal" by using it, I don't know, that's what the grammar says (you promise to continue to break the laws of whatever so-called jurisdiction you are in). What language is this patch written in? I don't know any that have keywords like "always" or uses indentation or that case syntax like that. I'm not a very good programmer though. The code is really readable (even though I don't write in that language). Von Neumann's fair coin algorithm has an algorithmic bug: it hangs in an infinite loop not only if the coins do not have any entropy (if they land tails all the time) but also if outputs are doubled for some reason. I'm curious if you ever try unit testing or doing stuff like that. When I do write code I never use test driven development or even fuzzing, I just write what I think should happen and then I manually test it. For example here under the "Von Neumann's 'fair coin' algorithm" part I would have included a counter of how many we had to discard, something like: int NumberOfPairsWeDiscardedInARow =3D 0; // how many pairs we discarded because they matched. This is useful for debugging as averaging of these could show the approximate level of bias; however in this case we will just decide to stop working if this ever reaches 80 in a row, since in this case something must be SERIOUSLY wrong, a series of 80 matching pairs should only occur at 1 gigabyte / second after 4.7 million years. Google says (2^80 bits) / (1 gigabyte/second) =3D 4,788,670 years. For production maybe this should be increased to 200 bits to elude false positives in case our code makes it into 10 billion devices spitting 1 terabyte per second since then one of them would fuck up every 15 seconds: (2^80 bits) / (1 terabyte/second) / 10 billion =3D 15 seconds. Gotta scale yo. For now 2^80 is a decent place to stop. The reason I'd add that is if for some reason you're getting either all 1's or all 0's, you'd get 80 right away and then could start saying mayday mayday we're really fucking up here. If it's not *exactly *all zero's or all one's you shouldn't wait for the entropy to trickle out very very slowly - it is important to have some guarantees and to know that something is being very wrong. the loop could hang for a very long time. The independence of the fair coin flips for von neumann's algorithm is important but I don't see a problem there. The Serial UART code is impressive. I'm surprised you don't use a serial library or something (maybe I misinterpreted). I could never write serial uart code. maybe there are algorithm errors in the protocol that I don't know about or miss. I'd just use a tested library. I always have really high-level conceptual ideas, I often get lost in the minutiae. for example the usb stuff I told you a few years ago for a hardware wallet, I thought the solution should be a phone communicating over its camera reading LED's since then it's airwalled. and next I'd think of the out of band stuff the led's give off. for example is it possible that certain devices use a fake LED with two different light spectrums, depending on the power they receive? so that it looks like there's "nothing up one's sleeves" and we see everything in the naked eye, but meanwhile it's exfiltrating data to cell phones that know the encoding, which can be low-entropy. (if the phone that ostensibly is just looking at the pulses, in fact analyzes the spectrum too.) in this way it could exfiltrate the private key out of band even while seemingly only displaying a checksum and nothing else - someone else might "check the checksum" but secretly receive the private key from a compromised unit, while the user can't check it at all. it's really hard to harden against everything. if I wanted to influence your RNG I would attack it at the von neumann fair toss algorithm, by ensuring that I have control over pairs of outputs somehow. One specific protection you can introduce against this is to discard, without recording this fact anywhere, numbers continuously, turning it into a small clock that depends on the exact speed of the chip that's running it and that nobody could code for. perhaps it is not possible to influence the precise speed down to the herz anywhere, if it depends on crystals that depend on heat or something. I don't know. the code seems very clean and I like it. thanks for sharing! 10/10. On Tue, Jun 4, 2019 at 5:24 PM wrote: > Dear Rob, > > Re: MP: he quit using email entirely several years ago (rather like, e.g.= , > D. Knuth did in '89). The only way to reach him is in Freenode/#trilema o= r > in his www comments, if you must. > > Re: XOR: your observation is commonly known to maths folks as "the xor > lemma", and in fact used inside FG itself, take a look at the source, > http://nosuchlabs.com/fg/fg-genesis.vpatch . > > Yours, > -S > > > On Tue, Jun 4, 2019 at 11:09 AM Rob Whiz wrote: > >> Hey Stan, >> >> So I looked at the pictures on Trilema that you suggested. Okay. I di= d >> meet MP personally. Wow. I am a bit shell-shocked, I mean he's famous.= I >> was really rude to him because I totally misinterpreted the situation. >> dude, I pulled his beard and pranced around naked in front of him. I ca= n't >> believe it. (I thought it was just a sex party.) >> >> I'd like to send him an apology e-mail and share what I thought was goin= g >> on. (I guess I can include you on cc if you like). >> >> you said polymedia.us (the e-mail address I have) is down. could you >> share a current e-mail address where I can write to him? >> >> This is a really funny story. >> >> of course, I was totally wrong where I thought I didn't meet him. >> >> Rob >> >> p.s. congrats on eventually shipping the rng product, I saw it on your >> site. >> >> I don't know if I told you this before, but the cool thing about rng's i= s >> if they're independent, then if you xor any number of them, then if *eve= n >> 1 *is independent and actually random, you get a fully random source as >> long as just 1 is independent. The reason for this is because xor is a >> commutative operation and it acts like a one time pad, so let's say you >> have NIST 1 the NSA controls, NIST 2 the NSA controls, your RNG generato= r, >> and then the Linux built in one and the Linux one can also be predicted. >> >> If you do NIST_source 1 xor NIST_source 2 xor your hardware RNG xor Linu= x >> software rng, then these are equivalent: >> (src1 xor src2 xor src3) xor src4 =3D=3D >> (src2 xor src3 xor src4) xor src1 =3D=3D >> (src1 xor src3 xor src4) xor src2 =3D=3D >> (src1 xor src2 xor src4) xor src3 =3D=3D >> >> (you see the first line ends in xor src4, the second with xor src1, the >> third with xor src2, and the fourth with xor src3). >> >> So if ANY of src1, src2, src3, or src4 are independent and random, then >> the end result is like taking all the crap (it could be exactly the >> sequence 10101010101 produced by the other crap, totally non-random) and >> still, you can rearrange the equation so that the single actually >> independent, random source comes last. >> >> So as long as they're independent and random, you can keep adding them. >> >> The only problem is if they're not independent, for example if the NSA >> had access to the equation that was right about to be executed and *then >> *modifies nist1 to modify the end result to their desired or predictable >> sequence. >> >> *-> That's why the NSA works so hard to have NIST's backdoored rng's >> (such as this joke of a page used here: ) adopted directly!* >> >> This is a fucking joke: >> https://www.nist.gov/programs-projects/nist-randomness-beacon >> >> If the randomness beacon were ACTUALLY secure nobody would mind if you >> ALSO xor'd it by any other independent source since >> NistBeacon XOR maybebiased =3D=3D >> maybebiased XOR NistBeacon >> >> and if either maybebiased *OR *NistBeacon were secure and independent, >> then the end result would be like applying a secure OTP. >> >> But NIST tries to get you to use their nistbeacon directly. >> >> NIST is implementing a source of public randomness. The service (at >> https://beacon.nist.gov/home) uses two independent commercially >> available sources of randomness, each with an independent hardware entro= py >> source and SP 800-90-approved components. >> >> The Beacon is designed to provide *unpredictability, autonomy, and >> consistency. Unpredictability* means that* users* cannot algorithmically >> predict bits before they are made available by the source. *Autonomy* >> means that the source is resistant to attempts by outside parties to alt= er >> the distribution of the random bits. *Consistency* means that a set of >> users can access the source in such a way that they are confident they a= ll >> receive the same random string. >> >> I bolded a word: *users* can't algorithmically predict bits. It didn't >> say "nobody can" (not even the NSA can). Just users. >> >> I think the fact that they don't recommend xor'ing with any other >> entropy, biased or not, as long as it's independent, shows that it's a >> totally fucked up government program. >> >> on the flip side, you could add to your RNG page that people should feel >> free to mix it themselves with any number of other sources of entropy, n= o >> matter how biased (as long as they're independent of the equation and of >> your rng). >> >> It's a cool project. in my opinion letting people add as many sources o= f >> possibly biased randomness that they want is more important than trying = to >> come up with just 1 perfect, auditable source. (because you can rearrang= e >> the equation, xor is commutative.) >> >> after all if any of the sources are good enough, you can just think of >> the xor equation as putting them at the end, to arrive at uniform >> randomness with no information. like applying a high-entropy OTP. >> >> what do you think? :D >> >> Best regards >> Rob >> >>>