500+ entries in 0.048s

mircea_popescu: http://btcbase.org/log/2019-01-22#1889150 << there's no way to have a rsa-aware client without the corresponding server, yes ? it's a whole migration, just, i was hoping she'd only have to do the server side, was the point of http://btcbase.org/log/2019-01-05#1884608 comment. ☝︎☝︎

asciilifeform: or recall the scytale thing ( 'original rsa' )

asciilifeform: ( it's the motor that powers e.g. m-r , and also underpins the proof that rsa pub:priv pairing is unique )

asciilifeform: 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

asciilifeform: 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~

bvt: http://bvt-trace.net/vpatches/ffa_ch4_ffacalc.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch5_egypt.kv.vpatch.bvt.sig http://bvt-trace.net/vpatches/ffa_ch6_simplest_rsa.kv.vpatch.bvt.sig

mircea_popescu: (the view that gpg aka koch-rsa leaks bits via signature isn't entirely dispelled even today)

a111: Logged on 2017-10-09 16:39 asciilifeform: ... it follows that a 0.85sec 4096b modexp is all you need for a reasonable 'rsa phone' item.

mircea_popescu: 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.

asciilifeform: 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.

asciilifeform: 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.

asciilifeform: 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.

mircea_popescu: 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.

asciilifeform: 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.

asciilifeform: ( and at any rate we gotta have trad rsa working 1st, before any such side dishes can be considered )

asciilifeform: c-s actually has 1 interesting win over good old rsa -- it dun need a hash padtron

asciilifeform: ( 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 )

asciilifeform: ( why this is, is because for certain types of pubkeycrypto, you want to test adjacent nums for primality. rsa in particular. )

mircea_popescu: 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).

asciilifeform: simply so happens that it is also needed for rsa primegen.

mircea_popescu: cuz im not going to have non-2048 factors in my 4086 bit rsa key, wtf.

mircea_popescu: this wasn't a rsa genprime application ?

mircea_popescu: 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

mircea_popescu: 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.

asciilifeform: ( i suspect btw that if there were , you could nail rsa, thinkaboutit )

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: 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.

mircea_popescu: 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.

asciilifeform: ( otoh euloratron does not spend much cpu in rsa, as currently sewn )

asciilifeform: bitcoin dun use rsa at all, at least in classical variant of bitcoin

mircea_popescu: http://ossasepia.com/2018/03/01/eucrypt-chapter-12-wrapper-c-ada-for-rsa-oaep/#selection-133.1-133.132 << right, and you want to use ~constant time~ keccak

asciilifeform: rsa-oaep requires hashtronics for padding.

mircea_popescu: wait, when did we move off oaep for rsa padding ?!

asciilifeform: 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.

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.

asciilifeform: 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

asciilifeform: ( 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..)

asciilifeform: 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 )

asciilifeform: not exactly mega-surprise, eccism worx on small (by rsa-planet standards) numbers.

asciilifeform: if yer sending a probe to pluto, it'll actually rsa faster than the time of signal bounce, yes

asciilifeform: literally simplest possible (afaik) rsa.

asciilifeform: btw diana_coman since you read 1-6, you can nao rsa!11

asciilifeform: 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

asciilifeform: mircea_popescu: for added lulz, given http://btcbase.org/log/2018-12-07#1878844 , one actually ~could~, in principle, bake 'rsa pnoje' ( in the sense that, e.g., 2048 * (1/.296) ~= 7kbit/s , moar than enuff for voice ) ☝︎

diana_coman: create one rsa_sender or one s_sender

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

asciilifeform: 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.

mircea_popescu: if it gets, and it gets a rsa item ?

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.

asciilifeform: mircea_popescu: how wouldja, e.g., 'these 6 cpus for serpent, these 3 -- for rsa' if yer packets are in 1 queue ?

asciilifeform: ( i thought orig mircea_popescu spec was 'keep rsa packets in own queue, so clearly cap the resource that is spent on'em'

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 ?

asciilifeform: ( i.e. without the variant packet widths . instantiate one with rsa-width buffer, and 1 w/ serp.width )

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.

asciilifeform: ( i.e. starting with ch.6 can already rsa )

diana_coman: and for that matter I did not even mention rsa by name

asciilifeform: 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?' )

asciilifeform: 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 )

asciilifeform: i have a b00k like that here, 'учебное пособие по криптографии' somthing or other. which fails to contain rsa.

deedbot: http://ossasepia.com/2018/11/30/smg-comms-chapter-10-actions-and-rsa-keys/ << Ossasepia - SMG Comms Chapter 10: Actions and RSA Keys

asciilifeform: 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... )

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: http://btcbase.org/log/2018-11-27#1875133 << it's not clear to me why we have ssl AT ALL. the idea is to replace that whole pile with straight rsa, much like we're taking out dns (and touched upon in same piece) ☝︎

mircea_popescu: http://btcbase.org/log/2018-11-23#1874309 << "At 5.1 the public exponent e of the client's RSA key is fixed as an int64". first bit set, too, so 8 bytes. ☝︎

asciilifeform: i dun particularly see why unix needs to be happening on an airgapped rsa box.

asciilifeform: i'm willing to 'marry' rsa, but not oaep, oaep only willing to casually fuck

asciilifeform: 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 is )

asciilifeform: mircea_popescu: we have hashes cuz some thing simply cannot be done without'em ( short rsa sigs of GB inputs, etc )

mircea_popescu: http://btcbase.org/log/2018-11-14#1872257 << i am not aware something better than oaep for rsa padding ~could in principle be had~, let alone actually is known to exist. ☝︎

asciilifeform: ( cuz that's where most time spent when rsa )

diana_coman: http://btcbase.org/log/2018-11-12#1871477 - that was just another rsa key in the tests; meanwhile fixed once and for all, properly i.e. http://ossasepia.com/2018/11/04/smg-comms-chapter-6-packing-and-unpacking-rsa/comment-page-1/#comment-4457 ☝︎

asciilifeform: ( 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 )

asciilifeform: it's prolly the oldest chip, not counting 'heavies' like vax, that can rsa on sumthing like human timescale.

diana_coman: http://btcbase.org/log/2018-11-05#1869503 -> and done; asciilifeform and anyone else requiring strictly 80 cols - I've updated the post with a .vpatch to read the keys from file and thus keep them out of the fully-80-cols-now code itself: http://ossasepia.com/2018/11/04/smg-comms-chapter-6-packing-and-unpacking-rsa/#selection-157.0-159.591 ☝︎

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

mircea_popescu: importantly... what's the byteness of rsa ?

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.

asciilifeform: ( the width of the constants pictured in http://ossasepia.com/2018/11/04/smg-comms-chapter-6-packing-and-unpacking-rsa/#selection-121.192-121.4240 )

a111: Logged on 2018-11-04 13:38 deedbot: http://ossasepia.com/2018/11/04/smg-comms-chapter-6-packing-and-unpacking-rsa/ << Ossasepia - SMG Comms Chapter 6: Packing and Unpacking RSA

diana_coman: asciilifeform> http://btcbase.org/log/2018-11-04#1869188 << kilometre-wide lines, wai! -> because RSA keys are kilometre-wide! ☝︎

a111: Logged on 2018-11-04 13:38 deedbot: http://ossasepia.com/2018/11/04/smg-comms-chapter-6-packing-and-unpacking-rsa/ << Ossasepia - SMG Comms Chapter 6: Packing and Unpacking RSA

deedbot: http://ossasepia.com/2018/11/04/smg-comms-chapter-6-packing-and-unpacking-rsa/ << Ossasepia - SMG Comms Chapter 6: Packing and Unpacking RSA ☟☟

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.