log☇︎
66200+ entries in 0.027s
asciilifeform: no reason to lose that 1bit of entropy.
asciilifeform: rinse, repeat.
asciilifeform: the way i'd implement the whole shebang, is simply to reject both primes if the highest bit of pq is not 1 . ☟︎☟︎☟︎☟︎
asciilifeform: ( by 'last' here is meant, of course, leftmost )
asciilifeform: (last digit of a product is not a straight product of the last-digit-of-p and last-digit-of-q )
asciilifeform: you don't actually get a 10x10=0100 because carry bits ripple up
asciilifeform: ( and why not then 111, 1111.... )
asciilifeform: i can actually see the 1. but why 11
asciilifeform: hmm
asciilifeform: if only 1 -- then high bits of p,q remain seekrit
asciilifeform: mircea_popescu: the only case where this is a problem is 0-led p + 0-led q
asciilifeform: it's an answerable question, euler could have made short work of it
asciilifeform: mircea_popescu: i made a stab of computing a lower bound of bitness for hypothetical '4096b of possible prime' but ran out of juice.
asciilifeform: these are always on hand
asciilifeform: fella oughta chat with his cto, vizier, etc before becoming a public clown.
asciilifeform: gensec is also managerial position. hruschev and his corn speeches remain lulzy.
asciilifeform: it is if he opens mouth re robots
asciilifeform: moar spectacular tho, candle burns at both ends
asciilifeform: exactly same item
asciilifeform: 'The Chinese miners were instructed to continue mining the coin, even at great financial loss, to support a pretension of value and use, minimally sustaining its life. When the price troughed, those who were in the know about the plan accumulated it in large quantities' etc.
asciilifeform: https://archive.is/Gr8Rf << in other agitprop.
asciilifeform: meanwhile, in very vintage lulz, https://archive.is/I5JC0 >> 'Secretary of State Baker said Washington would not object to military intervention in Romania by Soviets or the Warsaw Pact.'
asciilifeform: ^ pheeature idea : why not have ticker autofire when the number moves >10% from last tick ☟︎
asciilifeform: as i understand, ordinary keccak suffices for this scheme
asciilifeform: makes sense then
asciilifeform: yea that's hash-as-blockcipher
asciilifeform: aaa
asciilifeform: tbh i dun expect to live to see such a thing
asciilifeform: ( we dun have a scientific approach to symmetric ciphering. )
asciilifeform: the boojum is that neither i nor anybody else knows of any rational way to quantify the compromise. ☟︎
asciilifeform: if you use actual one-time -- you then dun have to reinvent symmetric ciphering
asciilifeform: how atrociously slow does the 'never reuse' variant look ?
asciilifeform: for so long as you're actually using otp (i.e. 1 byte of key used for exactly 1 byte of payload) it's the only logical option
asciilifeform: what's hard re using otp ? it's a xor
asciilifeform: iirc you were gonna use mircea_popescu's algo ( use rsa to send otp pages, then later use'em )
asciilifeform: well yes but moar specifically
asciilifeform: diana_coman: what are you contemplating making ?
asciilifeform: keccak is immune to length-extension attack so it is pretty straightforward to convert it into a cipher
asciilifeform: diana_coman: iirc it was in the original paper
asciilifeform: meanwhile, in world of ancient fpga, http://www.geekdot.com/category/hardware/transputer/avm-b1 .
asciilifeform: but sure.
asciilifeform: if 'machine' i'd rather have handwritten 32kb asm thing, than whatever 'best effort' gcc shits out.
asciilifeform: but i already described why.
asciilifeform: imho it dun particularly make sense to have gc in this application
asciilifeform: to put it in libctronic terms, the resulting linux binary will call setbrk() ~exactly once~ in its life
asciilifeform: and not 'as much as you want' but up to B bytes, with B given on commandline and stackframed on warmup. ☟︎
asciilifeform: aha. free with death.
asciilifeform: ( there is however the http://btcbase.org/log/2017-11-12#1736844 pov ) ☝︎
asciilifeform: right
asciilifeform: aa
asciilifeform: ( though they are useful for cache locality )
asciilifeform: no particular reason why it needs custom 'regions' support
asciilifeform: *off
asciilifeform: phf: you can run your entire heap of a mmap'd region , neh
asciilifeform: ( see also , http://btcbase.org/log/2017-07-13#1682511 ) ☝︎
asciilifeform: whole thing reads like straight translation from c ☟︎
asciilifeform: https://github.com/fitzgen/ada-scheme/blob/master/scheme.adb#L134 << the faux cons. observe, they use pointers for the car/cdr
asciilifeform: ( the operative difference is that indices are bounded , and you can reason meaningfully about'em )
asciilifeform: indices. as seen in ffa.
asciilifeform: ( there's no particular reason why you can't have a schemetron use strictly arrays and integer indices into same )
asciilifeform: and get rid of the pointers. ☟︎
asciilifeform: and rewrite the parser per se in scheme ( have it be present as commented bytecode constant ) ☟︎
asciilifeform: phf: ideally i'd get rid of Ada.Strings , full stop ☟︎
asciilifeform: also you don't want to cons. at. all.
asciilifeform: but if you want to make a fast mphftron, for experimentation, the recipe is 1) compute upper bound of the scratch space length and preallocate. NEVER realloc 2) NEVER flip-all-the-bits, flip a 'did-we-flip' bit instead, and the latter always get xor'd with whatever bit you read from the flippablespace.
asciilifeform: though asciilifeform will admit to still being at a loss re what the appeal is , after these...
asciilifeform: http://btcbase.org/log/2017-11-13#1737245 << if you apply the bound we found in http://btcbase.org/log/2017-07-06#1679483 thread, and the http://btcbase.org/log/2017-08-15#1698509 trick, mphf a not-especially-slow hash ☝︎☝︎☝︎
asciilifeform: lobbes: does this mean that you can mirror the whole zip collection nao ? ☟︎
asciilifeform: http://btcbase.org/log/2017-11-13#1737238 << this is very neat ☝︎
asciilifeform: ( it uses implicit heaptronics for everything )
asciilifeform: use Ada.Strings.Unbounded; << mno ben_vulpes this is ~specifically~ a Do Not Want ☟︎
asciilifeform bbl, teatime
asciilifeform: ( 1 caveat is that this is a leaking operation , theoretically )
asciilifeform: but yes you can use each of the 2 discarded bottom bits to double the primespace available
asciilifeform: ignore the 5step thing
asciilifeform: aha, koch does
asciilifeform: there is no legitimate reason to do it. ☟︎
asciilifeform: the shaving of the ~highest~ bits is an idiot kochism on the other hand,
asciilifeform: because you gotta have odd p and q
asciilifeform: they are the only ones you MUST set to 1 (i.e. lose the entropy of)
asciilifeform: lowest
asciilifeform: it will do exactly same thing as traditional one, but take 1000x as long.
asciilifeform: actually yer not missing anything, above algo is an absurdity
asciilifeform: hm?
asciilifeform: 5) you have a winner: a prime selected from 2^4096 possibles.
asciilifeform: 4) if log2(k) > 4096 goto 2
asciilifeform: 3) if composite(k) goto 2
asciilifeform: 2) generate a random k, k < 2^b
asciilifeform: 1) calculate what a certain b is, such that there are likely to be 2^4096 primes below 2^b-1
asciilifeform: tho here's a somewhat barbaric method :
asciilifeform: ( it's a 3000yr unsolved megaproblem )
asciilifeform: but nobody's gonna.
asciilifeform: nao ideally one would have a http://btcbase.org/log/2017-11-07#1733382 i.e. 4096b of ~possible prime~ phase space ☝︎
asciilifeform: but you can trivially show that using the bottom bits in this way lets you actually get 4x as many possible primes ☟︎
asciilifeform: mod6: noshit koch doesn't do this
asciilifeform: as i see it, this circle is satisfactorily squared nao.
asciilifeform: thinkaboutit.
asciilifeform: re the rsa key entropy, it is possible to trivially regain the lost bottom bits' worth of entropy -- you save the discarded bits and use them later as triggers for 'take nextprime(p) instead of p' and 'take nextprime(q) instead of q' . there may be other possible algos
asciilifeform: ( in re yesterday's thread where http://btcbase.org/log/2017-11-13#1737159 ) ☝︎
asciilifeform: 'Tesla’s CEO seems to be fully unaware of why industrial robots have limits, affecting actuators, speed and precision when handling heavy parts reliably and minimal downtime. Air friction is certainly no constraint, but moments, acceleration and deceleration. '