600+ entries in 0.081s
a111: 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).
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).
☟︎ stratum: 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.
diana_coman: you don't have to deploy
rsa sender on s box
diana_coman: "as asciilifeform describes" aka 1 item put/get at a time; 2 different queues, one for
rsa one for s
diana_coman: 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
mircea_popescu: yes. diana_coman mind explaining how this works ? so, queue has 55 elements, 22 of which
rsa packets. now what happens ?
diana_coman: 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
mircea_popescu: but re your q : these 6 workers pick
rsa from queuer ; and these 3 pick serpent from queue.
mircea_popescu: this machine for serpent, this machine for
rsa, is the model here.
mircea_popescu: "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 ?
diana_coman: mircea_popescu, that was my current idea: 2 sockets, one for
rsa and one for serpent, with different ports too
mircea_popescu: 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) ?
mircea_popescu: 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.
diana_coman: and for that matter I did not even mention
rsa by name
mircea_popescu: we made our own keccak, we made our own serpent, you made / are making our own
rsa -- time for our own ecc.
mircea_popescu: why does there not exist a
rsa-sized specialist processor widely available now ?
mircea_popescu: and so in order to
rsa on a commercial processor, you gotta do a mountain of switching
mircea_popescu: well, we use 4096 bit keys, therefore as asciilifeform well points out, the native byte of
rsa is 8192.
Mocky: I don't know
rsa maths well enough to say
a111: 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.
mircea_popescu: 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.
a111: 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.
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.
☟︎ mircea_popescu: they didn't discuss factored keys re
rsa, everything and anything but that -- we went ther,e it yielded.
mircea_popescu: in which case yes, it'd seem at least one workable method is for parties to declare F=
RSA-n1n2(x) and then use its spew as otp pad for all their stuff.
mircea_popescu: asciilifeform in fact, as eulora comms mandate the parties know at least one
rsa key of each other, it becomes eminently possible to use (session-based!) n1*n2 for this purpose.
mircea_popescu: nothing wrong with using the
RSA as the f, but idea remains.
mircea_popescu: anyway, back to it : "blockcipher takes 10 bits of P and no more ; spits out 16 bits of E exactly" a) needs entropy and b) probably reduces to
rsa-with-oaep.
mircea_popescu: i suppose that could be the backup alternative then : if we end up ditching serpent, we use a
rsa packet to move ~1.4kb of entropy for initializing the mt, and then use mt generated pads for a cipher.
a111: Logged on 2018-10-30 16:53 asciilifeform: ( tho the reason why
rsa is based on exponentiation, rather than straight multiplication-of-'plaintext'-prime-by-seekrit-prime is that in the latter variant you could trivially extract seekrit-prime with gcd )
a111: Logged on 2018-10-30 16:51 asciilifeform: the closest thing i can think of to a working variant of mircea_popescu's device, is where you keep the carries, and use primes... and we know it as..
rsa