500+ entries in 0.047s
asciilifeform: http://btcbase.org/log/2019-03-14#1902463 << limonov had entire b00k on subj, with slightly different twist ( tldr : the 'free world' built 'disciplinary sanitarium' (his term) where ideas-dun-matter-even-if-you-somehow-come-across-one cuz they all get http://trilema.com/2015/on-how-the-factored-4096-rsa-keys-story-was-handled-and-what-it-means-to-you/ ) ☝︎
asciilifeform: constanttimeized stein's o(n^2) gcd ( http://www.loper-os.org/?p=2963 ) is not only imho fast enuff (even a magical 100fold speedup in it, would not affect speed of rsa key gen measurably , consider above ) but fits-in-head and has no error terms.
feedbot: http://qntra.net/2019/03/rsas-shamir-did-not-receive-us-visa-for-rsa-conference/ << Qntra -- RSA's Shamir Did Not Receive US Visa For "RSA Conference"
mircea_popescu: aww. is this http://trilema.com/2015/on-how-the-factored-4096-rsa-keys-story-was-handled-and-what-it-means-to-you/ all over again ?
mircea_popescu: "working" nothing, this is nude and rude "we will whitewash over republic, http://trilema.com/2015/on-how-the-factored-4096-rsa-keys-story-was-handled-and-what-it-means-to-you/ style".
asciilifeform: in that e.g. it imposes ridiculously small bus widths, gimping rsa;
asciilifeform: mircea_popescu: i would not go so far as to say 'entirely useless', 2ce the bitness gets you 2ce the rsa speed for same clock.
asciilifeform: 4MB aint enuff to e.g. trb inside. tho 1 could rsa in it.
diana_coman: hm, it's all about what the task does so I suppose it's enough to plonk in there some rsa ops
asciilifeform: http://btcbase.org/log/2019-02-04#1892238 << possibly oughta include the tidbit re arithmetical part of ffa being 100% built (can gen rsa primez nao, can do so easily after ch17, where looping is introduced) ☝︎
asciilifeform: if you want to do , e.g., 4096bit rsa, needs iron with at least 256kB of ram . and 2 serial ports, 1 on which to hang FG, other for operator i/o. that's moar or less it, in re minimal iron req'd.
asciilifeform: dist. of primes -- until rsa. and so on.
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.
danielpbarron: also a fan of https and skeptic of rsa
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: http://www.loper-os.org/?p=2892#selection-4511.0-4595.6 << rsa timings.
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.