500+ entries in 0.048s
: ( it's the motor that powers e.g. m-r , and also underpins the proof that rsa
pub:priv pairing is unique )
: i'll add , for completeness of thread, that if yer ~sending~, rather than receiving, rsa
packets, your bottleneck will be ~rng~ long before it could ever be the arithmetron per se
: helps to recall that the problem which originally prompted asciilifeform to write ffa, is a (currently hypothetical) application where rsa
sigs are carried in ~individual packets~
: (the view that gpg aka koch-rsa
leaks bits via signature isn't entirely dispelled even today)
: Logged on 2017-10-09 16:39 asciilifeform: ... it follows that a 0.85sec 4096b modexp is all you need for a reasonable 'rsa
: ad interim the draft is, that the client stores all the keys (rsa
, serpent, whatever) one per line, the rsa
ones in republican format, the rest unspecified as of yet, in a file called keys.tmsr encrypted by the rsa
key of the client.
: take for example diana_coman's system , where 16 witnesses are used. ( i'd use moar, but let's go with the example. ) so if we're generating 2048b primes (for 4096b rsa
mod), per ch.14b timings on asciilifeform's iron this costs ~2.9s per modexp, and thereby ~93sec per m-r procedure.
: let's say yer baking one of the p, q of a 4096bit rsa
mod. it needs 2048bit , i.e. 256byte of FG. a standard FG at room temp shits out 7kByte/s. therefore 256 / (7 x 1024) ~= 0.0357 sec., for a fillup of candidate register.
: i can picture, for instance, that some folx will have a pubkey where 'well, first you gotta decrypt via these 2 rsa
keys, and depending on the low 4 bits of the plaintext, the rest is via 1 of these 4 c-s' or the like.
: just note that eucrypt having rsa
does in no manner hurt your serpent-only-phonecrypto putative app ; just like it having serpent dun hurt a "this is my pgp implementation" usecase, and so on.
: i'm carrying out mircea_popescu's orig spec, where 'i want a peh key with my rsa
modulus that i carved on the mountain' or how it went.
: ( and at any rate we gotta have trad rsa
working 1st, before any such side dishes can be considered )
: c-s actually has 1 interesting win over good old rsa
-- it dun need a hash padtron
: ( as for the other thing -- much of asciilifeform's oddball 'must work for all integers!' thrust, is on acct of his interest in cryptosystems other than classic rsa
, e.g. c-s and variations on theme )
: ( why this is, is because for certain types of pubkeycrypto, you want to test adjacent nums for primality. rsa
in particular. )
: i thought this entire discussion was a) specifiucally as to daykin (not to stein) and b) specifically as to primegen for rsa
secret key baking, (not "in general math functions).
: simply so happens that it is also needed for rsa
: cuz im not going to have non-2048 factors in my 4086 bit rsa
: had you instead used 32 bit rsa
, you'd have had two 16 bit primes you'd have daykin'd with 2×3×4×7×11×13 aka 0x5DD8
: consider the simpler case of 16 bit rsa
. you thus make two 8 bit primes. you daykin each of these with 210, which happens to be the 8 bit primorial, aka 11010010.
: ( i suspect btw that if there were , you could nail rsa
, thinkaboutit )
: i've been referring to mpi and gmp interchangeably as 'koch rsa
', but this is unscientific, i must remind that they are diff items.
: tbh i'm not sure what kochtronic rsa
will be good for once i have the keygenning ( it apparently dun win on speed anywhere, even tho it gets to skip 0s in modexp.. ) but this time not yet come.
: asciilifeform it doesn't ; nor will it, because what truly brings serpent in is the ~space~ not the time problem. ie, because of padding, straight rsa
doubles message bulk, which is a major problem for online game.
: ( otoh euloratron does not spend much cpu in rsa
, as currently sewn )
: bitcoin dun use rsa
at all, at least in classical variant of bitcoin
: what remains is 1) prime-baking 2) rsa
(and similar cryptosystems, tho c-s dun need it) padtron -- requires constant-spacetime keccak 3) optional asmistic speedups.
: Logged on 2019-01-05 14:22 mircea_popescu: finally, asciilifeform is working on rsa
-based ssl-ism replacement (notwithstanding he ~seems to be~ working on any and all wank on the "side" during spare time he doesn't have and all that), which we want so we can finally move bitcoin off sheer cretinity and into cuntoo (and which is principally why we want sane db also, but as i said -- yet immature).
: finally, asciilifeform is working on rsa
-based ssl-ism replacement (notwithstanding he ~seems to be~ working on any and all wank on the "side" during spare time he doesn't have and all that), which we want so we can finally move bitcoin off sheer cretinity and into cuntoo (and which is principally why we want sane db also, but as i said -- yet immature). ☟
: I do not recall any skeptical talk about rsa
, though, I do think https
can be valuable in attempting to mitigating some issues one may encounter, this is true.
: mircea_popescu: re 'homebrew crypto', there actually was a 1990s plague of commercial shitware folx who flunked arithmetic and then went to 'implement rsa
', with exponent = 1 and so on
: ( if not for irc line char # cap, could even make it do 2048bit widths, rsa
etc. will still fire faster than ping lag on typical day..)
: turns out, the entire justification for use of branching in rsa
at all, is bogus. ( and 'short exps' aint a justification -- if you know the max length of your e in advance, you can use fixed exponentiator , same as i do )
: not exactly mega-surprise, eccism worx on small (by rsa
-planet standards) numbers.
: if yer sending a probe to pluto, it'll actually rsa
faster than the time of signal bounce, yes
: btw diana_coman since you read 1-6, you can nao rsa
: mircea_popescu: there's a reason i wrote the thing that way, with 'what's the minimum for rsa
modexp without ANY accelerations', and only then with
: you don't have to deploy rsa
sender on s box
: "as asciilifeform describes" aka 1 item put/get at a time; 2 different queues, one for rsa
one for s
: q1 has 22 elements all of which are rsa
packets; q2 has 33 items all of which are s packets ; rsa
processor eats from q1 , s processor from q2
: what happens is that nothing behind the 22 rsa
items is eaten until they are. as one'd expect from an ordinary fifo. hence asciilifeform's nitpick.
: yes. diana_coman mind explaining how this works ? so, queue has 55 elements, 22 of which rsa
packets. now what happens ?
: mircea_popescu, that's precisely why I made it that way; I suppose it's not clear there at all but yes - because processing of rsa
/s is meant to be easily and entirely separated physically, aka machines
: but re your q : these 6 workers pick rsa
from queuer ; and these 3 pick serpent from queue.
: this machine for serpent, this machine for rsa
, is the model here.
: mircea_popescu: how wouldja, e.g., 'these 6 cpus for serpent, these 3 -- for rsa
' if yer packets are in 1 queue ?
: ( i thought orig mircea_popescu spec was 'keep rsa
packets in own queue, so clearly cap the resource that is spent on'em'
: "this is needed for the same reason as the generic at UDP lib previously - to allow one to store Serpent messages or RSA
messages while maintaining them clearly differentiated" << why are you putting ducks and geese in the same line though ?
: ( i.e. without the variant packet widths . instantiate one with rsa
-width buffer, and 1 w/ serp.width )
: mircea_popescu, that was my current idea: 2 sockets, one for rsa
and one for serpent, with different ports too
: diana_coman does it then make sense to have a process that has a socket open and handles the serpent queue, and one proces with a different socket open handling the rsa
queue (with a view that these :6666 and :6667 ports then get moved to separate machines if need be) ?
: so, i hear from cto the comms spec's mostly implemented. now, we're at the point where we wanna make a rsa
and a serpent sender.
: and for that matter I did not even mention rsa
: diana_coman: the only immediate gotcha that stands out to asciilifeform's lens is that the public crypto example was rsa
( did anyone ask 'but prof. coman, bitcoin dun use rsa
: if you can build it, potentially quickest pill is to transplant the trad fs logic from uboot to it ( google's shitware demands that the kernel lie on a custom googlistic partition, and be 'signed' with their sad-rsa
in custom format etc )
: i have a b00k like that here, 'учебное пособие по криптографии' somthing or other. which fails to contain rsa
: in unrelated lulz, $ wc -l libffa/* >> 3930 , $ wc -l ffacalc/* >> 1184 ; and story not even finished yet. ( tho ch1's 'RSA
occupies around 3000 lines, incl. comments' was not a lie, it's exactly what the minimal rsa
of ch9 weighs... )
: we made our own keccak, we made our own serpent, you made / are making our own rsa
-- time for our own ecc.
: i dun particularly see why unix needs to be happening on an airgapped rsa
: i'm willing to 'marry' rsa
, but not oaep, oaep only willing to casually fuck
: but if it were possible to have straight rsa
, rather than rsa
and hash,would be stronger system ( no hash ever was proven strong, even in the sense rsa
: mircea_popescu: we have hashes cuz some thing simply cannot be done without'em ( short rsa
sigs of GB inputs, etc )
: ( rsa
on z80, 6502, etc. is ~nonstarter, even if one 'banks' the address lines to give enuff mem, the 8bit buggers lack a multiplier, so you get 'egyptian' speed )
: it's prolly the oldest chip, not counting 'heavies' like vax, that can rsa
on sumthing like human timescale.
: why does there not exist a rsa
-sized specialist processor widely available now ?
: and so in order to rsa
on a commercial processor, you gotta do a mountain of switching
: well, we use 4096 bit keys, therefore as asciilifeform well points out, the native byte of rsa
: I don't know rsa
maths well enough to say
: Logged on 2018-10-25 15:44 mircea_popescu: now, a 4096 bit native fpga, specifically for rsa
-ing and rsa
-likes-ing, THAT might be very useful, because there the s-o-d item is major win.
: standard line length may not be shorter than common lines. which among other things will be rsa
keys. so it'll be, willy nily, over 80.
: Logged on 2018-11-01 20:48 mircea_popescu: asciilifeform speaking of "taking suggestions" : suppose you bake me a proper drop-in gpg replacement. in ada, constant time, does FG-aware keygen, signing, verification, and encryption/decription. 100% rsa
, none of the "cipher" bs as per current.
: asciilifeform speaking of "taking suggestions" : suppose you bake me a proper drop-in gpg replacement. in ada, constant time, does FG-aware keygen, signing, verification, and encryption/decription. 100% rsa
, none of the "cipher" bs as per current. ☟
: they didn't discuss factored keys re rsa
, everything and anything but that -- we went ther,e it yielded.