348 entries in 0.606s
: 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)
: ada-musl will have to get its own backend, even if it's mpi
: but hm, the underlying stuff that takes most time is the mpi
: it took asciilifeform 2y ( 3, if you count the mpi
dead ends ) to build ~that~ deathray. and it's just about ready to fire..
: 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
: mircea_popescu: mpi
is subset of gmp that koch cut ( and ate $mil of microshit payola to do it, somehow ) , aha.
: what we call mpi
is closer to gmp than what the retard crowd does anyway.
: i've been referring to mpi
and gmp interchangeably as 'koch rsa', but this is unscientific, i must remind that they are diff items.
: mircea_popescu: possibly i ought add : ~mpi
~ dunhave strassen. ~gmp~ (the older, 'uncut' gnu thingie) has strassen.
: diana_coman: i described in this log what currently stands between 'throw out mpi
' . lemme know if needs moardetail.
: and yes, I'm eating up ffa with an eye on "maybe I can finally get rid of MPI
: esp because correctly written, with tests etc. so can meaningfully do ffa-eucrypt vs mpi
-eucrypt as a benchmark.
: right. a mpi
-eucrypt vs ffa-eucrypt head-on will be interesting to see.
: gpg itself is substantially moar crippled than koch's mpi
: incidentally, it's a 'fair fight', i.e. both ch14 ffa and mpi
-koch lack asmism
: mircea_popescu: ikr ? the mpi
thing, straight from my garbage can
: mircea_popescu: what exactly is an 'ada mpi
' ? ( i.e. i assume it's diff from what i'm baking )
: 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
: 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 ☟︎
: 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
: 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
: 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
: 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
: and yes, the mpi
-variable-buffer-returned gives me some headaches
: yes, c_wrappers that I wrote have a wrapper for precisely that mpi_compare thing among other stuff
: 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
: 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
: asciilifeform, it shits a shit: there is get_mpi_buffer and set_mpi_buffer that theoretically do that
: diana_coman: until you wrote the recent piece, i actually forgot that mpi
~didnt~ shit out ordinary octet arrays as-supplied
: asciilifeform, I guess mircea_popescu has a point: one can choose just *what* has to go through the MPI
swamp and what not ☟︎
: but going that route ...can implement the mpi
arithmetic too, right?
: 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
: 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)
: yes, but preparing for that: wrappers in C for the methods so they don't export "mpi
" shit but simply octets
: 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
: 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 )
: i've read some possibly asciilifeform-able selections from it ( diana_coman's mpi
) , to date that's iirc all
: right. but are you suggesting to pull in all of eucrypt, including mpi
: consider why asciilifeform removed the #ifdefolade ( and consequently, ALL asm inlines ) from mpi
: mircea_popescu: right. ( keep in mind, currently asciilifeform knows very little re subj, aside from diana_coman's mpi
: 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
: 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
: 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
: 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?
: esthlos: it was gonna, then barfed and abandoned mpi
: asciilifeform diana_coman: are the secure memory portions of MPI
useful/worth their weight?
: ( tldr : it's a demo of a guaranteed-cure for the infamous ' moving mpi
dir ' misery . )
: or possibly everyone regarded trb as a messy pile which isn't properly v-ified even today. like mpi
, or like gentoo
: 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.
: 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)
: douchebag: i dunno man, i'm going to weary of picking things for you in short order but maybe try to sidechannel the mpi
: Logged on 2018-03-21 13:47 diana_coman: I feel your pain: it's insane-mpi
: 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
: 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
: Well the nice code comment was not about the MPI
: 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
: 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)
: 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
: 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 ☟︎
: mircea_popescu, the first error I find in my published code, yes; there was the mpi
error I corrected, previously
: well yes, recall where i bulldozered out the autoconfism in mpi
: Logged on 2018-01-16 03:18 esthlos: I can imagine it being very cool in eulora. mpi
in js sounds hairy
: I can imagine it being very cool in eulora. mpi
in js sounds hairy ☟︎
: 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.
: 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.
: though it'd be hilarious if there were a subtle bug in mpi
: ^ neat asciilifeform ... I'm a bit slower learning these bits (like debug flag 2 didn't work on gpg2 because mpi
) but patience.
: 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 ?