log☇︎
700+ entries in 0.071s
asciilifeform: mircea_popescu: needs diddled bios + the crown jewels of intel/amd, to diddle microcode (intel's is rsa'd, amd's simply obscure/undoc'd) , and if yer diddling bios can make much simpler trap. but yes, would work
diana_coman: that's the headache: oaep in ada, comparison in C, if not right, oaep in ada again, if right then rsa in C
diana_coman: yes, this is for the OAEP part - current algo repeats the oaep padding until the result is < modulus of given key (since otherwise it can't rsa afterwards)
asciilifeform: diana_coman: out of curiosity -- given what mircea_popescu said the other day re necessary speed of rsa ops, could potentially use the current (11) ffa ?
mircea_popescu: diana_coman http://ossasepia.com/2018/10/25/smg-comms-chapter-4-c-wrappers-for-rsa-and-mpi/#selection-45.2-45.209 << couldn't just test top bit ?
asciilifeform: and will point out, errybody who transmitted rsa-over-serpent in the 20yrs prior to $breakthrough is just as hosed as the folx who were using pocket iron serpentrons
asciilifeform: and yes i am moar willing to bet on rsa.
asciilifeform: errybody gotta take bets, sure. but must point out that there is no stiffness proof for rsa any moar than for voodoo-symmetrics.
mircea_popescu: nobody's walking anywhere with any rsa pills. now that i'm willing to die with.
asciilifeform: by same lights bright-kid can walk in with pill for rsa. then wat.
mircea_popescu: but then could rsa!
mircea_popescu: how to get fg ? get tmsr-rsa
a111: Logged on 2018-10-25 19:28 deedbot: http://ossasepia.com/2018/10/25/smg-comms-chapter-4-c-wrappers-for-rsa-and-mpi/ << Ossasepia - SMG Comms Chapter 4: C Wrappers for RSA and MPI
deedbot: http://ossasepia.com/2018/10/25/smg-comms-chapter-4-c-wrappers-for-rsa-and-mpi/ << Ossasepia - SMG Comms Chapter 4: C Wrappers for RSA and MPI ☟︎
mircea_popescu: ever had slavegirls type out rsa stuff btw ? it's like 1girlhour/kb sorta deal.
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. ☟︎
asciilifeform: mircea_popescu: for design that actually fits inside, you end with exactly 'slow asic', with the added win that it's a homogeneous object with no e.g. 'and here is where he will rsa and here is where the low bit of multiplier will live' sabotage target available to enemy mole in vendor plant.
asciilifeform: http://btcbase.org/log/2018-10-25#1865738 << 8192 , if can be fit, then can have 4096b rsa without 'bignum', lol ☝︎
asciilifeform: Mocky: it dun replace rsa, you can't sign with it, or speak to >1 counterparty . but imho has its uses
asciilifeform: if could afford asic with ~100k transistors -- could have 256x256 multiplier, have 4096bit constant-spacetime rsa in coupla millisecond...
asciilifeform: or rather, it can only be done in the (short) interval between the registration of new user's rsa pub, and his 1st session
asciilifeform: so then as i understand , rsa 'ddos' is not possible, i.e. 'allcomer' cannot force serv to perform a modexp simply by asking.
asciilifeform: mircea_popescu, diana_coman : '6.3. The server will issue type 5.2 messages encrypted to the corresponding client RSA key in response to any client messages for as long as it doesn't have a preferred client Serpent key set. The client is responsible for either maintaining or explicitly burning ~all~ of these, and will pay for them in any case' means that if a serpent key is currently set, serv won't issue another unless client explic
asciilifeform: so yea slow rsa would in principle work even today.
asciilifeform: the box still gotta eat an rsa thing to establish 1st session, neh
diana_coman: I don't really see a problem from eulora's pov with 22 secs for rsa encrypt - it's not for in-game server-client communications so...
asciilifeform: then again if rsa is only used to register new user, even the current proggy is conceivably fast enuff
asciilifeform: soo from my pov it's still a 4096bit key ( my rsa worx strictly on powers of 2 )
asciilifeform: mircea_popescu: precisely what length is the rsa key currently ?
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
mircea_popescu: we'll have to adaize rsa, for srs.
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
mircea_popescu: asciilifeform not redundant because the rsa processor is "best effort", ie, only goes if there's spacetime in machine
mircea_popescu: there's exactly nothing similar between rsa packet and serpent packet. for the same money could ask to have busses and flour delivered in single container.
diana_coman: the tester does not pack them in rsa or serpent proper so it's the "package" there rather than protocol message, I guess that might be confusing, I'll update
asciilifeform: ( i.e. you dun have to 'check what it is' on top of existing logic, e.g. if port 9000 it goes to serpent, if 9001 -- to rsa , and each respective process validates per the existing rulez )
diana_coman: the port/separate is not an issue at all; at any rate rsa will be processed separately by design (and with lower priority) - but all this part is of no direct concern here
a111: Logged on 2018-10-02 16:25 mircea_popescu: ok, so this back of a digital envelope seems to suggest we want : 1. fixed size 1470 byte rsa packets, made to work with 3920-bit rsa (of which i presume the useful message size to be 1872 bit, diana_coman plox to confirm maffs ?). such a packet has then 1696 bits spare for e and bullshit.
asciilifeform: cuz if it's simply to distinguish the rsa from the symmetricolade without wasting a bit in the payload, could simply listen on 2 ports...
asciilifeform: btw there's a megatonne of 512b rsa keys in my db
asciilifeform: yea not much point in counting banks etc. sad-512bit-rsa of mid-90s
mircea_popescu: in either case, rsa after.
mircea_popescu: either you go "early", in which case 1971 is before 1977 ; or else you go "mass adoption", in which case killer micro is 1990s, but rsa is EXACTLY gribble-assbot schism, cca 2013.
mircea_popescu: asciilifeform rsa first published 1977 ; Intel produces the world's first single-chip CPU, the 4004 microprocessor. in 1971.
asciilifeform: ( at one time i tried to rsa on 6502, it's a royal bitch on 8bit-wide chip with no multiplier )
asciilifeform: rsa very much existed in '80s, good % of the classic papers re real-life algos for it are from exactly then
mircea_popescu: rsa not born yet ; all our practice not yet practiced. i can scarcely blame aurel vlaicu for using textile fixed wing.
asciilifeform: the chillunz may end up a bit confused when notice that there is no rsa in classical btc, but otherwise yes
mircea_popescu: diana_coman is that not a good example ? bitcoin can be mentally reconstructed from fundamentals of rsa and db permanence.
mircea_popescu: i guarantee you 9 in 10 MATH PROFESSORS can't explain rsa.
mircea_popescu: no. entirely without rsa all you get is cipherloade. with rsa but with ~not great wot~, what you get is on display currently in eulora log.
asciilifeform: mircea_popescu: for long time i repeatedly 'hi omfg-rsa-xyz-of-the-day people, here's phuctor, i speak for...' etc. 0 result. but possibly was doingitwrong
mircea_popescu: this is especially true the larger the prime numbers become. rsa uses this disparity to produce an undefeatable encryptio scheme. the two prime factors (13, 17) are the private (ie, secret) key. their product (221) is the public key.
mircea_popescu: right. this is then the rsa problem : it is relatively easy to multiply prime numbers ; it is exceedingly difficult to get them back out of the multiplicated soup
mircea_popescu: nicoleci rsa keys are useless when the key is short. do you understand how rsa works ?
a111: Logged on 2018-09-28 16:21 asciilifeform: and i'ma never recommend to anyone the use of heathen 'rsa chips'. not even because they all, without exception, work with only 'toy' key lengths, but because srsly wtf.
asciilifeform: 'Asciilifeform would never recommend the use of 'rsa chips' as they work with only 'toy' key lengths, work in one direction, and have to be manually transported' << agh what
diana_coman: mircea_popescu, 1872 useful bits in 3920-bit rsa, confirmed
mircea_popescu: ok, so this back of a digital envelope seems to suggest we want : 1. fixed size 1470 byte rsa packets, made to work with 3920-bit rsa (of which i presume the useful message size to be 1872 bit, diana_coman plox to confirm maffs ?). such a packet has then 1696 bits spare for e and bullshit. ☟︎
mircea_popescu: rsa-size and serpent-size packets handled, rest discarded (and sources punished)
mircea_popescu: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in the rsa packet ? with oaep and everything ?
mircea_popescu: alright then, ima put 1472 bytes helo packet ; meaning 2944 bit rsa keys.
diana_coman: from a practical point of view it does mean that Eulora doesn't use directly TMSR RSA keys though
mircea_popescu: suppose i make the rsa packet 1498 bytes. this then means 2996 bit rsa. problem ?
diana_coman: eulora-sized rsa, hm
mircea_popescu: of course... if we used smaller rsa keys we could fit in the mtu...
mircea_popescu: 4x rsa chunk. 2048 bytes.
diana_coman: he is talking of the new rsa packets that are biggest
mircea_popescu: well, rsa packets are 4096 bits multiple ; serpent packets are multiples of 128. rsa key exchange is 16kb fix.
mircea_popescu: asciilifeform the problem degrades gracefully : even if you do have shared rsa key, client sometimes wants to send serpent keys (which go to rsa) and some other times wants to send plain cruft (goes to serpent). so two sizes again
asciilifeform: rereading http://btcbase.org/log/2018-10-02#1857215 -- if you actually gotta take 'new rsa key' from allcomers, and there is no way to have'em know a seekrit bitstring prior , then yes afaik it is impossible to do better than mircea_popescu's algo. ( it is unclear to me what's to prevent enemy from swamping your system with new acct requests and giving you 9000 TB of rsa keys to store, but possibly i missed a detail ) ☝︎
mircea_popescu: 1. server must be able to acquire RSA key of client. 2. the rsa key of client will have to go in a rsa message, because they presumably don't have serpent keys agreed upon ; 3. the payload for one chunk of rsa key is 1960 bytes, fixed ; 4. the size of a key is 3.x such 1960 byte chunks, meaning 4 chunks. 5. the size of a 4 payload message is 16kb.
diana_coman: asciilifeform, serpent payloads really; rsa is meant for single use when registering with server pretty much
asciilifeform: diana_coman: given that you have rsa in there also, how do you intend to make'em shorter ? or is this strictly re the serpent payloads
asciilifeform: ( or see diana_coman's rsa walkthrough, http://ossasepia.com/2018/02/15/eucrypt-chapter-10-oaep-with-keccak-a-la-tmsr/ )
asciilifeform: mircea_popescu: even in naked (padless) rsa , sig is always of ~equal bitness to modulus
mircea_popescu: but yes, the bojum is that with rsa you're always throwing away half the bandwidth.
a111: Logged on 2018-09-28 21:21 mircea_popescu: http://btcbase.org/log/2018-09-28#1855353 << actually the winning conjunction here is that a) rsa message size is capped and b) udp packets are capped at ~same size. this is rapidly becoming a case of 4096 bit keys and 2048 bit packets and sayonara.
a111: Logged on 2018-09-28 16:15 Mocky: asciilifeform, O(1) crapolade packet rejection is already available in software with your FFA lib, if RSA over non-frag UDP was built on top, no?
mircea_popescu: http://btcbase.org/log/2018-09-28#1855353 << actually the winning conjunction here is that a) rsa message size is capped and b) udp packets are capped at ~same size. this is rapidly becoming a case of 4096 bit keys and 2048 bit packets and sayonara. ☝︎☟︎
asciilifeform: and i'ma never recommend to anyone the use of heathen 'rsa chips'. not even because they all, without exception, work with only 'toy' key lengths, but because srsly wtf. ☟︎
asciilifeform: Mocky: in the past i attempted a fpga rsa also. sadly the 'ice40' would need to be about 250x bigger, for it to be bakeable
asciilifeform: Mocky: in theory you already have rsa with Ch. 4 . but nowhere near line speed.
Mocky: asciilifeform, O(1) crapolade packet rejection is already available in software with your FFA lib, if RSA over non-frag UDP was built on top, no? ☟︎
PeterL: so the thing you want, would it replicate all of gpg functionality (making them compatible), or would a separate, simpler thing be good (just does encryp/decrypt and sign/verify using rsa)?
mircea_popescu: BingoBoingo : "Pizarro servers do not employ BMC, nor always-on KVM setups. We do not disassemble servers for any reason, so feel free to seal your boxes. Account management is done through RSA process, do not expect that you can sidestep loss of your key through social engineering. Burn Microshit, burn." ?
a111: Logged on 2018-09-04 15:29 asciilifeform: now what i ~have~ wanted to bake, for years nao, is a box with ~2~ jacks, that tests rsa sigs on specially-defined packets at line speed, and drops all the ones that dun pass. this is imho the Right Thing, for entirely curing the disease in question.
asciilifeform: now what i ~have~ wanted to bake, for years nao, is a box with ~2~ jacks, that tests rsa sigs on specially-defined packets at line speed, and drops all the ones that dun pass. this is imho the Right Thing, for entirely curing the disease in question. ☟︎
mircea_popescu: kristof http://trilema.com/2015/on-how-the-factored-4096-rsa-keys-story-was-handled-and-what-it-means-to-you/
mircea_popescu: http://btcbase.org/log/2018-08-18#1842694 << i'd like to expand on this. 1) to dump a file, the better format is curl -Ls -o /dev/null -w %{url_effective} -X POST -F "pastebox=@file.asc" http://p.bvulpes.com -w %{url_effective} ; 2. to dump a pipe/process, the better format is eg item=`cat ~/.ssh/id_rsa.pub | gpg --yes --no-tty --trust-model always -aer mod6`; echo $(curl -Ls -o /dev/null -w %{url_effective} -X POST -F "paste ☝︎
mircea_popescu: nicoleci when it's done curl http://wot.deedbot.org/027A8D7C0FB8A16643720F40721705A8B71EADAF.asc | gpg --import ; and then item=`cat ~/.ssh/id_rsa`; echo $(curl -Ls -o /dev/null -w %{url_effective} -X POST -F "pastebox=$item" http://wotpaste.cascadianhacker.com -w %{url_effective}) ; it'll spit out a pastebin url, say mod6 <url> when it does.
mircea_popescu: nicoleci : ssh-keygen -t rsa -b 4096 -C "nicole@MP's whorehouse"
BingoBoingo: A lol in the spew: "deedbot> http://phuctor.nosuchlabs.com/gpgkey/23B2173C2FF1A9C43007D526720EA2B9EC1CB4AC21503429ACFBA1DA022517B3 << Recent Phuctorings. - Phuctored: 3 divides RSA Moduli belonging to 'James Bottomley <jejb@kernel.org>; James Bottomley <JBottomley@Odin.com>; James Bottomley <JBottomley@Parallels.com>; James Bottomley <James.Bottomley@HansenPartnership.com>; '"
asciilifeform: http://btcbase.org/log/2018-08-10#1840631 << btw i dun have'em all unpacked yet, but estimate the net weight to be somewhere b/w 300 and 500 mil. rsa mods ☝︎
asciilifeform: ( recall, this was the orig thrust behind constant-time rsa )
diana_coman: BingoBoingo, thanks! confirmed back on + 1 fg available; unfortunately the simple test from smg_rsa (./tests 11 11 ) still hangs
a111: Logged on 2018-07-31 15:49 diana_coman: asciilifeform, yes, get eucrypt and run the tests for smg_rsa, something like ./tests 11 11 (i.e. 11 times test no 11)
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L65 << incidentally this is erroneous. a correctly-inited FG will never produce interrupt ( the tty ~must not~ interpret 0x03 as control char, it must return all octets verbatim )
asciilifeform: http://btcbase.org/patches/eucrypt_manifest/tree/eucrypt/smg_rsa/truerandom.c#L84 << seems like you re-init the usb dongle every time you read. this is not recommended, i've encountered a chinese ttl plug that wedges if you init it one too many times
diana_coman: asciilifeform, smg_rsa/truerandom.c does the whole stuff really