348 entries in 1.074s
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)
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
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 mircea_popescu: what we call
mpi is closer to gmp than what the retard crowd does anyway.
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.
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
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
☟︎ 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 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
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?
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
esthlos: right. but are you suggesting to pull in all of eucrypt, including
mpi, etc.?
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
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?
esthlos: asciilifeform diana_coman: are the secure memory portions of
MPI useful/worth their weight?
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 13:47 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
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.
shinohai: ^ neat asciilifeform ... I'm a bit slower learning these bits (like debug flag 2 didn't work on gpg2 because
mpi) but patience.