log☇︎
348 entries in 0.606s
diana_coman: ... of mpi_fix_copy_incr
diana_coman: well, there IS on one hand the FFA gem that has however come after the initial projection that he'll do consulting for smg and so I'll have what to use rather than write eucrypt with the salvaged-mpi (though he salvaged that at least)
asciilifeform: asciilifeform was able to cut several MB from ye olde gnu mpi (which today lives in diana_coman's 'eucrypt') simply by beheading the #ifdef dec_vax... and #ifdef xenix... etc
mp_en_viaje re-read ye olde http://ossasepia.com/2017/12/21/eucrypt-correcting-mpi-implementation/ ; pretty lulzy still.
asciilifeform: diana_coman back in the day posted old-style mpi timings but i do not know on what irons so cannot readily compare .
asciilifeform: a la mpi etc
asciilifeform: it's at the mpi confiscation stage atm.
mircea_popescu: ada-musl will have to get its own backend, even if it's mpi-style confiscation.
diana_coman: but hm, the underlying stuff that takes most time is the mpi c/cpp anyway
asciilifeform: it took asciilifeform 2y ( 3, if you count the mpi dead ends ) to build ~that~ deathray. and it's just about ready to fire..
diana_coman: asciilifeform, re m-r: I implemented it using mpi as per http://ossasepia.com/2017/12/28/eucrypt-chapter-3-miller-rabin-implementation/ ; ofc I'd rather use ffa ct-time implementation but it's not a sticking point per se i.e. I can switch my implementation from relying on mpi to relying on ffa, no?
diana_coman: asciilifeform, thing is: from eucrypt and eulora pov, mpi is used for "big num arithmetics" only so I CAN in fact switch to ffa even without ct-time miller-rabin esp if ffa turns out to be...faster than mpi
asciilifeform: mircea_popescu: mpi is subset of gmp that koch cut ( and ate $mil of microshit payola to do it, somehow ) , aha.
mircea_popescu: what we call mpi is closer to gmp than what the retard crowd does anyway.
asciilifeform: i've been referring to mpi and gmp interchangeably as 'koch rsa', but this is unscientific, i must remind that they are diff items.
asciilifeform: mpi had only (ugly as fuck) karatsubatron.
asciilifeform: mircea_popescu: possibly i ought add : ~mpi~ dunhave strassen. ~gmp~ (the older, 'uncut' gnu thingie) has strassen.
asciilifeform: diana_coman: i described in this log what currently stands between 'throw out mpi' . lemme know if needs moardetail.
diana_coman: and yes, I'm eating up ffa with an eye on "maybe I can finally get rid of MPI!!"
mircea_popescu: esp because correctly written, with tests etc. so can meaningfully do ffa-eucrypt vs mpi-eucrypt as a benchmark.
mircea_popescu: right. a mpi-eucrypt vs ffa-eucrypt head-on will be interesting to see.
mircea_popescu: in the sense eucrypt uses mpi you mean ?
mircea_popescu: still, gpg itself uses mpi to do the mathing
asciilifeform: gpg itself is substantially moar crippled than koch's mpi lib
asciilifeform: incidentally, it's a 'fair fight', i.e. both ch14 ffa and mpi-koch lack asmism
feedbot: http://www.loper-os.org/?p=2906 << Loper OS -- Finite Field Arithmetic vs MPI.
asciilifeform: http://btcbase.org/log/2018-12-03#1877916 << to date we've had both types of regrind ( e.g. diana_coman reground 'mpi' into 1 genesis, for use in smg ; ffa on other hand had a 'history-preserving' regrind , http://www.loper-os.org/?p=2743 ; and iirc mod6 is baking a 'history' regrind for trb ; diana_coman had 'history' regrind for eucrypt; and possibly i missed somebody in this list ) ☝︎
asciilifeform: mircea_popescu: ikr ? the mpi thing, straight from my garbage can
a111: Logged on 2018-11-12 15:48 mircea_popescu: http://btcbase.org/log/2018-11-12#1871447 << an ada mpi, however, would be a most interesting item.
a111: Logged on 2018-11-12 15:42 mircea_popescu: bvt http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/#selection-37.321-37.374 << basically, some lines got arbitrarily truncated and everything went to shit subsequently ?
asciilifeform: mircea_popescu: what exactly is an 'ada mpi' ? ( i.e. i assume it's diff from what i'm baking )
a111: Logged on 2018-11-12 12:13 bvt: also, i think that pushing gcc-6 patches to frozen system (mpi) defeats the purpose of the standard republican compiler, so the post and vpatch is more of
mircea_popescu: http://btcbase.org/log/2018-11-12#1871447 << an ada mpi, however, would be a most interesting item. ☝︎☟︎
a111: Logged on 2018-11-12 15:42 mircea_popescu: bvt http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/#selection-37.321-37.374 << basically, some lines got arbitrarily truncated and everything went to shit subsequently ?
mircea_popescu: bvt http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/#selection-37.321-37.374 << basically, some lines got arbitrarily truncated and everything went to shit subsequently ? ☟︎☟︎
deedbot: http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/ << bvt's backtrace - GNAT2017 GCC breaks SMG_Comms MPI: extern inline function issues.
a111: Logged on 2018-11-12 08:59 bvt: meanwhile, http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/
bvt: also, i think that pushing gcc-6 patches to frozen system (mpi) defeats the purpose of the standard republican compiler, so the post and vpatch is more of ☟︎
diana_coman: bvt, http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/comment-page-1/#comment-4
bvt: meanwhile, http://bvt-trace.net/2018/11/gnat2017-gcc-breaks-smg_comms-mpi-extern-inline-function-issues/ ☟︎
a111: Logged on 2018-10-26 21:02 diana_coman: asciilifeform, I guess mircea_popescu has a point: one can choose just *what* has to go through the MPI swamp and what not
diana_coman: asciilifeform, in some sense MPI lib is a very good illustration for all sorts of things - "make a call and be surprised" sort of things, especially re memory allocation
diana_coman: more of a hack to accommodate the stink of MPI - not sure it's something we want in there; if anything, I guess I can see more the point to just walking the octets in the array and basically doing the comparison in Ada
diana_coman: asciilifeform, theoretically yes; practically since one calls stuff from mpi lib to create the MPIs, there are all sorts of things going on in there
diana_coman: and yes, the mpi-variable-buffer-returned gives me some headaches
diana_coman: yes, c_wrappers that I wrote have a wrapper for precisely that mpi_compare thing among other stuff
diana_coman: but...it wants MPI!
diana_coman: asciilifeform, it even has mpi_compare
asciilifeform: mpi has a signed subtract, iirc
diana_coman: but the comparison is iffy since either a. call c-wrapper and so do conversion from ada's oaep array of octets to C's MPI shit
diana_coman: but it's true that doing the whole conversion to c and conversion back *just for the sake of an MPI comparison* might be uglier than just walking the arrays and seeing which one has a bit set first
diana_coman: asciilifeform, it shits a shit: there is get_mpi_buffer and set_mpi_buffer that theoretically do that
asciilifeform: diana_coman: until you wrote the recent piece, i actually forgot that mpi ~didnt~ shit out ordinary octet arrays as-supplied
diana_coman: asciilifeform, I guess mircea_popescu has a point: one can choose just *what* has to go through the MPI swamp and what not ☟︎
diana_coman: but going that route ...can implement the mpi arithmetic too, right?
mircea_popescu: diana_coman http://ossasepia.com/2018/10/25/smg-comms-chapter-4-c-wrappers-for-rsa-and-mpi/#selection-45.2-45.209 << couldn't just test top bit ?
a111: Logged on 2018-10-25 19:28 deedbot: http://ossasepia.com/2018/10/25/smg-comms-chapter-4-c-wrappers-for-rsa-and-mpi/ << Ossasepia - SMG Comms Chapter 4: C Wrappers for RSA and MPI
deedbot: http://ossasepia.com/2018/10/25/smg-comms-chapter-4-c-wrappers-for-rsa-and-mpi/ << Ossasepia - SMG Comms Chapter 4: C Wrappers for RSA and MPI ☟︎
diana_coman: mircea_popescu, once this is in place, it should be relatively painless to swap at a later stage (whenever available) the C rsa/mpi for an Ada implementation since it's basically kept well separate
diana_coman: will probably cut it in 2 parts two, namely the wrappers first and then the whole big .vpatch bringing in everything needed (mpi, keccak, oaep-but-this-time-from-ada-only)
diana_coman: yes, but preparing for that: wrappers in C for the methods so they don't export "mpi" shit but simply octets
diana_coman: in other news from the smg comms front: the rsa pack/unpack turned a bit nastier than the nice serpent because (of course!) of the C element; basically the rsa operations are in C (mpi mess) while the oaep is in Ada and the current eucrypt wrapper is fine but doing the ugly dance of C to Ada *and back*; my solution to this is to decree that there will be only ONE direction of calls namely from Ada to C (because Ada is the main, desired par
asciilifeform: even from existing gnu liquishit, it is fairly easy, turns out, to remove ( e.g. as i did with the mpi that diana_coman made into the 1st half of eucrypt )
asciilifeform: recall , similarly, koch's 'fix' for his mpi bug.
asciilifeform: i've read some possibly asciilifeform-able selections from it ( diana_coman's mpi ) , to date that's iirc all
esthlos: right. but are you suggesting to pull in all of eucrypt, including mpi, etc.?
asciilifeform: consider why asciilifeform removed the #ifdefolade ( and consequently, ALL asm inlines ) from mpi.
asciilifeform: mircea_popescu: right. ( keep in mind, currently asciilifeform knows very little re subj, aside from diana_coman's mpi works )
spyked: mircea_popescu, I'm not sure what you mean. lemme explain: the rss bot depends on ircbot and other pieces (some imported from heathenlands, some written by scratch from yours truly). from my reading so far, (e.g. diana_coman's use of MPI in Eucrypt) I dun see this as a strictly solved problem. I could a. make a new genesis consisting of ircbot + rss bot + all dependencies, or b. genesis rss bot alone (and mention ircbot + all others as
deedbot: http://blog.esthlos.com/a-brief-overview-of-eucrypts-mpi-library/ << esthlos - A Brief Overview of Eucrypt's MPI Library
esthlos: aha, so if I want to patch "as close to genesis as possible" the mpi lib, AND I want this patch to be used in diana_coman 's proggy, the ONLY choice is to patch current leaf of diana_coman 's proggy
diana_coman: esthlos, well, it ultimately depends on your vpatch (what it does *exactly*), neh? chopping off some unused and moreover useless parts is valuable but a. it needs to be done making sure that nothing breaks b. mpi is and will still be a pile of shit
esthlos: so let's say I remove the "secure" bits of MPI code for the sake of honesty. is this a needless complication of the eucrypt vpatch tree?
asciilifeform: esthlos: it was gonna, then barfed and abandoned mpi 4evah
esthlos: asciilifeform diana_coman: are the secure memory portions of MPI useful/worth their weight?
asciilifeform: ( tldr : it's a demo of a guaranteed-cure for the infamous ' moving mpi dir ' misery . )
mircea_popescu: or possibly everyone regarded trb as a messy pile which isn't properly v-ified even today. like mpi, or like gentoo
ave1: diana_comon, Yes, I read the test and the code and your text (also played with the test a little). So I was a little suprised that rsa_oaep_encrypt used mpi code. I will write an alternative.
ave1: diana_coman: could the input parameter of rsa_oaep_encrypt be a character array? it is now an MPI this will discard any leading zero's of a message an exclude binary stream/file encryption. (same goes for decrypt)
ben_vulpes: douchebag: i dunno man, i'm going to weary of picking things for you in short order but maybe try to sidechannel the mpi lib?
a111: Logged on 2018-03-21 14:38 mircea_popescu: http://btcbase.org/log/2018-03-21#1788339 << i can't tell you how annoying it is that mpi starts with mp.
a111: Logged on 2018-03-21 13:47 diana_coman: I feel your pain: it's insane-mpi for sure
mircea_popescu: http://btcbase.org/log/2018-03-21#1788339 << i can't tell you how annoying it is that mpi starts with mp. ☝︎☟︎
diana_coman: I feel your pain: it's insane-mpi for sure ☟︎
diana_coman: ave1, and the trouble with changing stuff in mpi is that one needs to track afterwards ALL calls/uses of that code; I was rather avoiding changing mpi unless I really really needed
diana_coman: trouble with the future is that it is...the future; I'd have gladly avoided C all together but unfortunately mpi is in C and then eulora relies on a lot of C code still
ave1: Well the nice code comment was not about the MPI part!
diana_coman: heh, there is that slippery slope; and note that in all that there, it's still that darned mpi that is the biggest part and I am absolutely not convinced it has to be THAT big
diana_coman: fwiw the footprint of eucrypt with default runtime is 215K (separate components: mpi 109K; bit_keccak 17K; keccak 42K; rsa 19K; serpent 20K - 31K (depending on level of optimisation chosen)
a111: Logged on 2018-03-03 07:58 diana_coman: mod6, thank you for the detailed write-up on the vpatch issue; I'm not sure it makes sense or even helps to name as "chapters" fixes so people don't miss them in the future since this happened with the mpi_fix before just the same
diana_coman: mod6, thank you for the detailed write-up on the vpatch issue; I'm not sure it makes sense or even helps to name as "chapters" fixes so people don't miss them in the future since this happened with the mpi_fix before just the same ☟︎
diana_coman: mircea_popescu, the first error I find in my published code, yes; there was the mpi error I corrected, previously
asciilifeform: well yes, recall where i bulldozered out the autoconfism in mpi
a111: Logged on 2018-01-16 03:18 esthlos: I can imagine it being very cool in eulora. mpi in js sounds hairy
esthlos: I can imagine it being very cool in eulora. mpi in js sounds hairy ☟︎
mod6: Going back to the issue exposed by the eucrypt mpi_fix_copy_incr vpatch, you can see now that the press path is calculated by including all of the given HEAD's antecedents recursively.
asciilifeform: i threw away mpi after attempting a very similar exercise to what diana_coman is doing now, and realizing that i'ma prolly never find all of the mines.
asciilifeform: though it'd be hilarious if there were a subtle bug in mpi fdiv etc.
shinohai: ^ neat asciilifeform ... I'm a bit slower learning these bits (like debug flag 2 didn't work on gpg2 because mpi) but patience.
asciilifeform: PeterL: the result is that the only way for PeterL to use something asciilifeform wrote, is to turn his house into an exact duplicate of asciilifeform's; or alternatively to cut-and-paste, eulora-mpi-style, destroying all record of the copied item's history. but i already said this. try reading log ?