log☇︎
48800+ entries in 0.407s
mircea_popescu: a... hm. a vandal ?
hanbot: meanwhile, what do you call a frenchman wearing sandals?
asciilifeform: if yer doing a great deal of hashing , straight asm could be a win
asciilifeform: returning to http://btcbase.org/log/2017-11-16#1739533 , i will point out that inline asm is ~likewise~ a gcc-specific syntax. so if you're marrying gcc you may as well use the existing ( as seen in ffa ) rotate intrinsic. ☝︎
asciilifeform: i'm a little surprised that any part of it worked.
mircea_popescu: aaand asm rotate is a straight asm item, it doesn't lock you etcetera.
asciilifeform: FG is a straight serial device tho, it doesn't lock you into any particular form ☟︎
mircea_popescu: as a forinstance.
asciilifeform: ('use asm' is not an answer, i want, as diana_coman wants, a PORTABLE proggy )
asciilifeform: result is a 4x slower ffa.
asciilifeform: gcc offers a built-in rotate 'illicitly', but not a portable access to carry flag. because ALSO run by wreckers. ☟︎
asciilifeform: motherfuckers, there is not a single comp made in 40 years that doesn't have a carry flag. WHY YOU HID IT
asciilifeform: it's a single fucking cpu instruction on ~all known cpu. and yet some wrecker saw it fit to exclude it from the language standard.
asciilifeform: afaik there isn't a proper solution.
asciilifeform: diana_coman: how do you propose to rotate without it ? as i see it, the language standard simply has a rotate-shaped hole in it
diana_coman: rho uses that Rotate_Left function which is imported from gnat; I'd rather not have it in a reference implementation tbh
diana_coman: mircea_popescu, well, he had those step functions private so initially inaccessible; so first I've tried a full test (i.e. input is this, do full keccak round, output should be this): it failed; so then I grunted through exposing the step functions at least at this stage and testing bit by bit;
diana_coman: PeterL, did you test your permutation step functions on that keccak implementation? when I feed rho a full-zero state it seems to end up with non-zero output ☟︎
mircea_popescu: if can be cleanned enough ; always a dubious proposition in english speakers.
asciilifeform: by refusing to add. 'i'm too clean to touch a shovel' is the likely pathology.
asciilifeform: http://btcbase.org/log/2017-11-16#1739454 << pretty deep lol , 'I chose a RSA key size of 3925 for my blog' and d00d dun seem to realize that it's exactly a 4096b modulus wit 171 leading zeros ... ☝︎
asciilifeform: http://btcbase.org/log/2017-11-16#1739455 << not so surprising, considering that bernstein himself is a quantumist ☝︎
asciilifeform not much into eccism, regards its presence in btc as a bug
asciilifeform: crypto in a gclang is an absurdity
asciilifeform: he has a buncha
mircea_popescu: the importance of a phuctor style primorial+commonkeyset gcding away is somehow easily overlooked by academic minds. but in practical terms it is the first line, degree (or even two!) ahead of haskelism a la gnfs
mircea_popescu: or consider something as simple as phuctor, that already has a lot of "special" primes, however you define special (small, common, whatevewr)
asciilifeform: http://btcbase.org/log/2017-11-16#1739429 << forget public nfsieve. consider ordinary bruteforce ('but how brute force for soomanybits??!' ) on novel physical substrate, or with a heuristic that lets you skip large chunks of space ☝︎
a111: Logged on 2017-11-14 15:01 mircea_popescu: http://btcbase.org/log/2017-11-14#1737387 << this is alternatively a perfectly acceptable approach ; expensive as all fuck though. prolly should be the standard for homemade keys.
mircea_popescu: this whole thing aside, the only objection to http://btcbase.org/log/2017-11-16#1739433 ie, "produce sets of 2048 bits, check them for primality, if they're prime multiply them and if the product is a suitable N keep them else start over" was http://btcbase.org/log/2017-11-14#1737682 ☝︎☝︎
mircea_popescu: there's no argument that informations about range of factors CAN be used. the point is minorily that a) a range of 2045 bits is sufficient and majorily that b) should this range NOT be sufficient, the correct response is to extend IT, rather than to introduce key-substitute mechanisms in the actual encryption scheme.
mircea_popescu: factors that are very small are trivially a vulnerability, as the 17 example shows. what is "small enough" is somewhat of an open question, but 512 BITS does conceiovably qualify.
a111: Logged on 2017-08-14 17:21 mircea_popescu: tmsr rsa standard key is 515 bits, made out of a 257 and a 258 bit long prime.
a111: Logged on 2017-11-16 11:27 apeloyee: ...factors differ only a few bits in length, it doesn't appear to be better than NFS.
mircea_popescu: http://btcbase.org/log/2017-11-16#1739432 << factors differing by only a few bits in length aren't particularily unsafe, which is why the original alt-rsa spec involved them (see eg http://btcbase.org/log/2017-08-14#1697613 and the eventual end of that discussion.) ☝︎☝︎
a111: Logged on 2017-11-15 23:59 asciilifeform: at any rate this is a quite pointless imho discussion, we will NOT be reintroducing normalized integer braindamage.
apeloyee: ...factors differ only a few bits in length, it doesn't appear to be better than NFS. ☟︎
BingoBoingo: This is a reduction of ~21.47% over number from last night taken through weekification and de-fxrisking transform.
asciilifeform: sooo they are also fraudulently pushing bch' ( or what it was) as a fork of bch ?
a111: Logged on 2017-07-18 03:17 mircea_popescu: the notion that bitcoin can somehow by stolen by name is so ridoinculous as to betray its ustardian origins. bitcoin is not a name.
asciilifeform: mircea_popescu: it's a pretty good olympiad problem, actually, to show why PeterL's scheme is still a bad idea even though '17' scenario is ruled out given as he capped the lower bitness at 512
a111: Logged on 2017-11-15 22:41 lobbes: i.e. it still uses someone else's code for the 'core' irc functionality. I'd rather that core functionality be ircbot, but of course this'll be a huge time investment migrating everything (and learning lisp). In the hopper, though.
mircea_popescu: http://btcbase.org/log/2017-11-15#1739330 << thjat works, can even make the archive item a vpatch when it's done for instance. ☝︎
a111: Logged on 2017-11-15 20:30 asciilifeform: but instead a rerun of the august item
a111: Logged on 2017-11-15 23:37 asciilifeform: let p be any 4096b prime, let q be any 4096b prime, throw out both if pq exposes a high bit of 0
asciilifeform: and the cost of the costliest operation is a cube of the bitness.
asciilifeform: at any rate this is a quite pointless imho discussion, we will NOT be reintroducing normalized integer braindamage. ☟︎
PeterL_: but isn't it easier to break knowing that they must be 2048b than if they could be anywhere within a wider range?
asciilifeform: in a 4096b rsa run, p and q are 2048b primes
asciilifeform: either is a legal bitness
PeterL_: I guess I was just trying to skip a few iterations of chucking out bad values?
asciilifeform: let p be any 4096b prime, let q be any 4096b prime, throw out both if pq exposes a high bit of 0 ☟︎
asciilifeform: not even to divide by a p that guaranteed to not equal 1
asciilifeform: not to mention that 2^4097 cannot be represented AT ALL in a 4096bit ffa
asciilifeform: how does it give a wider range ?!
PeterL_: gives a wider range of possible values than just using a set bitness for both p and q
PeterL_: http://btcbase.org/log/2017-11-14#1737536 << for key generation, why not pick a p between say 2^512 and 2^3584 (or whatever values) until you find a prime, then look for a q between 2^4096/p and 2^4097/p ? ☝︎
asciilifeform: meanwhile, in психушка noose, https://archive.is/5aOSp >> 'The U.S. Food and Drug Administration approved a pill Monday that has a digital ingestion tracking system which can tell if medication was ingested by a patient. ... to allow easier treatment of schizophrenia, bipolar disorder and some depression'
BingoBoingo: <asciilifeform> but i suppose is now a dried, rather than soft turd. << So you broom rather than mop
lobbes: i.e. it still uses someone else's code for the 'core' irc functionality. I'd rather that core functionality be ircbot, but of course this'll be a huge time investment migrating everything (and learning lisp). In the hopper, though. ☟︎
lobbes: http://btcbase.org/log/2017-11-15#1739265 << My ultimate goal with the thing would be to use trinque's ircbot and try and rebuild lobbesbot off of that. As it stands now, lobbesbot is nothing more than a suite of 'supybot modules' I wrote ☝︎
asciilifeform: and in every case to find a name. ~who~ broke $proggy. and what else has he shat into.
phf: shit my emacs greets me with iswitchb-mode is obsolete on boot, if i cared enough i'd patch it out, but it's a daily meditation on the general level of fuck
phf: well, in a sense that it's not a special wrong. they also run systemd and can't wait for wayland etc. etc.
phf: "The need for Harmony arose out of me not finding any suitably powerful sound solution in Lisp. I tried doing a pure Lisp solution at first, but was not able to figure out how to make things go fast without sacrificing design. So, in the interest of performance, I first set out to write a C library that does the essential sound computations for me. This library is called libmixed."
asciilifeform: but instead a rerun of the august item ☟︎
asciilifeform: 'Anyone who held Bitcoin at the time Bitcoin Cash Plus was created became owners of Bitcoin Cash Plus. This means that Bitcoin holders as of block 501407 ' << apparently, contrary to appearances, is NOT a fork of bch
a111: Logged on 2017-08-03 18:35 mircea_popescu: trinque i'll dare say it's something else. have you ever seen "a man for all seasons" ?
trinque: I proposed that as a better solution to portability a while back
trinque: better stated, I observe that nothing about having a continuous tree prevents naming particular runs of the tree, pointing at, using for different purposes.
mircea_popescu: and otherwise to cap a very productive morning... are there any neglected issues ?
mircea_popescu: so is this a regrind then ?
a111: Logged on 2017-11-15 18:43 diana_coman: and re peterl's keccak implementation trouble is that thoroughly testing it looks atm as much work as writing a new one in the process anyway so whatever version ends up with tests and everything is the one that will make it into v too I would say
asciilifeform: being a human diff, on other hand, is not great.
phf: mircea_popescu: it's actually a broken patch (i.e. it was published broken), i need to move it to deprecated, since *-corrected has been published since
trinque: then wrote a completely separate html viewer for the db logbot extrudes
trinque: logbot's a descendent class that puts log lines in a db
trinque: ircbot's a lisp class that sits connected to IRC
phf: mircea_popescu: there's a bit of confusion there with logbot, because ircbot and logbot were both published by trinque by they are not vtronic connected, they rely on lisp machinery to load each other. multichannel equivalents of both were publshed by ben_vulpes
mircea_popescu: diana_coman some bits of code, such as heavily linked against standard hash etc would normally take a zillion reimplementations rereads etc anyways.
mircea_popescu: inasmuch as logbot (bv item) has a genesis, it is not a branchoff. yes it imports from a different line.
diana_coman: and re peterl's keccak implementation trouble is that thoroughly testing it looks atm as much work as writing a new one in the process anyway so whatever version ends up with tests and everything is the one that will make it into v too I would say ☟︎
asciilifeform: mircea_popescu: actually i made a quite heavy use of phf's viewer, when linking to fg details in log
trinque: yes, logs.bvulpes.com is powered by a logbot
diana_coman: I get the feeling that v is not really seen as versioning in the sense of these are the steps I took, still mulling a bit on thiw
asciilifeform: also helps that my mpi builds a standalone static lib
mircea_popescu: this i confess is a fine way to read code.
mircea_popescu: anyway. my conclusion is ima do the eu-crypto as a new genesis, because really most of the koch crap in mpi (esp the prng crap) got dirtched
asciilifeform: but i suppose is now a dried, rather than soft turd.
asciilifeform: so it is still entirely a koch product
mircea_popescu: i meant, rather than make a genesis for eu-crypto, just make a branch of your mpi
mircea_popescu: will take a public comment blogpost pass first, so ideally early next year
phf: asciilifeform: it didn't, i just didn't realize that there was a proper genesis
mircea_popescu: well anyway, this'd be a great time to go through the slag, "items that didn't work list" see what other mpis are in there
mircea_popescu: phf do you have roughly the equiv of a "feed paste in here" slit for it ?
asciilifeform: and it's a perfectly legit ( manually ground, from mpi, just like trb genesis was from 0.5.3 ) genesis.
asciilifeform: a yes it is phf
phf: mpi-genesis.tar.gz is not a vpatch though
mircea_popescu: i had thought i saw a genesis too.
phf: but oftentimes when i post a patch something comes up anyway. like the recent mpi release by asciilifeform is a vpatch, but it lacks a genesis, which breaks all kinds of assumptions (e.g. the tree visualizer wouldn't work at all)