Forum logs for 02 Oct 2018

Monday, 16 March, Year 12 d.Tr. | Author:
BingoBoingo: https://i.imgtc.com/BXAAdct.jpg [00:36]
BingoBoingo: Session keep alive packet not recieved: BingoBoingo to sleep [01:06]
ben_vulpes: taking mimisbrunnr down for a spell [02:30]
mircea_popescu: i never heard of obesity miscarriage before. [02:54]
diana_coman: http://trilema.com/forum-logs-for-02-oct-2018#2480865 -> afaik obesity does increase risk of miscarriage [05:05]
a111: Logged on 2018-10-02 06:54 mircea_popescu: i never heard of obesity miscarriage before. [05:05]
diana_coman: http://btcbase.org/log/2018-10-01#1856931 -> today works anytime really, just let me know in the logs [05:44]
a111: Logged on 2018-10-01 21:14 asciilifeform: diana_coman, mod6 , lobbes , let BingoBoingo & asciilifeform know when is good day to take down yer units and copy contents to new drives. [05:44]
diana_coman: BingoBoingo, asciilifeform ^ [05:45]
ben_vulpes: http://p.bvulpes.com/pastes/2cESi/?raw=true << dns table update [05:45]
diana_coman: http://btcbase.org/log/2018-10-02#1857110 -> if it's anything like mine, it'll be mostly loud complaints from php because "time zone not set!!!" and similar (apparently php version on the RC is too new for its own good) [05:46]
a111: Logged on 2018-10-02 01:45 asciilifeform: btw lobbes in case you care, it's almost all apache error log... [05:46]
diana_coman: http://btcbase.org/log/2018-10-01#1856937 -> yes, please also yes, can leave the old disk plugged in to see when it dies, why not (iirc there should still be 1 usb2 empty slot on my RC as the other one has an FG) [05:48]
a111: Logged on 2018-10-01 21:17 asciilifeform: diana_coman, mod6 , lobbes , also give signal re whether you want the newer iptables-enabled kernel to go on your boot sd , when we take the boxen down ( iirc we already did mod6's ) [05:48]
diana_coman: the thing is though that at any rate, it won't get the same type of use as it did as main disk so I don't know whether much can be found out from that really [05:49]
ben_vulpes: those reluctant to diddle /etc/hosts without seeing signed material first may: curl --header 'Host: cascadianhacker.com' 216.151.13.77/dns_update.txt [05:49]
diana_coman: I suspect there might be more to find out from dissection of the thing [05:49]
mircea_popescu: i guess im behind the times in obstetrics. [09:38]
mircea_popescu: ben_vulpes updatered, thx [09:59]
asciilifeform: !Q later tell BingoBoingo lobbes's drive ready to plug [10:06]
lobbesbot: asciilifeform: The operation succeeded. [10:06]
BingoBoingo: asciilifeform: Ty, headed over [10:07]
lobbesbot: BingoBoingo: Sent 1 minute ago: <asciilifeform> lobbes's drive ready to plug [10:07]
asciilifeform: BingoBoingo: btw figure out when you want to do yours [10:08]
asciilifeform: http://btcbase.org/log/2018-10-02#1857127 << month and a half... whatcha moving it with , mod6? oxcart ? [10:09]
a111: Logged on 2018-10-02 03:10 mod6: Lords and Ladies of TMSR~: Update on 216.151.13.78 (The Bitcoin Foundation's 2nd node), this TRB machine will be shutdown tomorrow morning, to be packed up and brought to texas (it's new home). We anticipate this box to come back online on-or-around November 15th. [10:09]
mod6: ben_vulpes: I am shutting down 'lovelace' (the second tbf node) now. [10:09]
mod6: I have also pulled '216.151.13.78' off of the Advertised Node list. [10:09]
mod6: asciilifeform: ben_vulpes is bringing this with him to texas. He said he'd be able to have it up and running in a rack down there by mid-November. [10:10]
asciilifeform: aa rack not built yet. aite [10:10]
* asciilifeform pictures ben_vulpes's texan fort [10:11]
asciilifeform: meanwhile, in the trb observatory, http://nosuchlabs.com/pub/trb/10_2_ProcessBlock.txt [10:17]
diana_coman: http://btcbase.org/log/2018-09-27#1855101 -> it turns out Eulora actually needs precisely this since its communication protocol specifies different lengths of messages, hm [10:17]
a111: Logged on 2018-09-27 20:37 asciilifeform: yea i can't picture for what might need variable masses in production [10:17]
asciilifeform: diana_coman: http://btcbase.org/log/2018-09-18#1851192 [10:18]
a111: Logged on 2018-09-18 14:26 asciilifeform: mircea_popescu: i wrote the item originally for gossipd experimentations. udp gives a max practical packet length ( what it is , remains to be determined ) and if given proggy's protocol needs variably-sized ones, you can pad with rng. [10:18]
asciilifeform: afaik there is no practical reason to actually send variable-length udp. [10:18]
diana_coman: asciilifeform, clients pay for traffic though so dunno [10:18]
asciilifeform: diana_coman: i dun think there exists still on planet3 an isp that actually charges per-byte [10:19]
asciilifeform: ( per TB -- yes. per byte afaik no ) [10:19]
diana_coman: it's not the isp, lol it's eulora-internal because client can choose how much traffic it generates [10:19]
diana_coman: but if you force it to pad everything to maxlen it's a bit iffy [10:19]
diana_coman: every time they simply ask for an object you force them to send over 2048 bytes, ugh [10:20]
diana_coman: there IS some padding, i.e. it's not entirely arbitrary lengths, no [10:20]
asciilifeform: diana_coman: a frame is a frame, short packets still occupy one,. [10:20]
diana_coman: but it's variable lengths.. [10:20]
asciilifeform: i.e. it'll still take 1500. [10:21]
asciilifeform: even if nominal length is 3. [10:21]
mircea_popescu: diana_coman working on it. [10:21]
mircea_popescu: SPEC HAS EVOLVED MEANWHILE! [10:21]
asciilifeform: ultimately it's diana_coman's proggy, not mine, i can only recommend. imho fixed packets make the coad 9000x simpler, and simplify crapola filtration also. but if diana_coman's application absolutely gotta vary the lengths, then do it.. [10:21]
diana_coman: mircea_popescu, cool well, it's been 4 months being digested hopefully by everyone around so evolution makes sense! [10:22]
mircea_popescu: yeah. [10:22]
mircea_popescu: so far, productive activity, but only made it up to 3. [10:22]
diana_coman: asciilifeform, it certainly makes the code simpler! if only I could always choose by this criteria though... [10:22]
diana_coman: anyways, will wait to see the updates [10:22]
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 [10:23]
mircea_popescu: anyway, re "client pays for traffic" -- yes, but message traffic not packet traffic. [10:23]
diana_coman: asciilifeform, serpent payloads really rsa is meant for single use when registering with server pretty much [10:23]
mircea_popescu: padding wouldn't cost in principle, except if crypto produced then entropy costs. [10:23]
mircea_popescu: but i expect can have client opt to pad with fixnum. [10:23]
asciilifeform: mircea_popescu: hm if this is so, then i have nfi why you'd want to try an' shorten packets [10:23]
diana_coman: asciilifeform, the above wasn't clear until now, it's clarified ...now [10:23]
mircea_popescu: asciilifeform because the largest packet we ~need~ is 16kb [10:24]
diana_coman: so then hooray [10:24]
mircea_popescu: and forcing all packets 16kb may lose us on some routes. [10:24]
asciilifeform: well i did warn, http://btcbase.org/log/2018-09-28#1855322 , what else i can say. [10:24]
a111: Logged on 2018-09-28 15:12 asciilifeform: even if seems that 100% of 2/3-frag packets make it through in 'laboratory' conditions, still gotta remember that the frag reassembly buffer is the ~exact~ equivalent of the pre-trb 'block orphanage' [10:24]
mircea_popescu: here's the bojum, explained : [10:25]
asciilifeform: ( if i were writing this proggy, i'd rather http://btcbase.org/log/2018-09-28#1855329 . ) [10:25]
a111: Logged on 2018-09-28 15:57 asciilifeform: imho if you want large messages, oughta have own fragger/reasmer, not the ??? in linux/ciscolade [10:25]
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. [10:26]
mircea_popescu: 6. if you pertmit this 16kb item be chunked, you basically rebuild the tcp ddos bs long discussed here. if it has to be in 1 piece, you can always use or discard on sight. [10:27]
mircea_popescu: so -- eulora MUST have a 16kb packet in its format. [10:27]
asciilifeform: i'd still rather reasm'em in the proggy itself, rather than baking in a perma-reliance on the linux nonsense. but i suppose is easy to say, but moar work to actually bake. [10:27]
mircea_popescu: now, if it also has 1 single size, that means the size of all packets is 16kb [10:28]
mircea_popescu: this seems nutty. [10:28]
mircea_popescu: asciilifeform nevermind that. to re-asm you gotta keep chunks. [10:28]
mircea_popescu: how many chunks am i keeping and for how long ? [10:28]
asciilifeform: right but if you reasm in own proggy, the chunks actually carry the port # and origin ip. [10:28]
mircea_popescu: so ? [10:28]
asciilifeform: whereas if you rely on the udp fragger, only 1 in 4 chunks does, and the rest are not mechanically filtrable. [10:28]
mircea_popescu: what's "here's a list of 2mn unknown ips" buy me ? [10:29]
asciilifeform: that you can throw out obvious crapola [10:29]
asciilifeform: and that you can then use fyootoor fragless ip stack . is all. [10:29]
mircea_popescu: doesn't take so much work to ask me to hold 16gb of chunks. [10:29]
diana_coman: asciilifeform, but what's the problem with that? client sends and waits (for as long as it wants) for a reply whenever it has enough of waiting...sends again until it makes it [10:29]
mircea_popescu: this must-have magical packet of 16kb is extremely rare -- basically only sent when new client making new account. [10:30]
mircea_popescu: if it has to retry a few times not end of world. [10:30]
asciilifeform: diana_coman: imho i described the problem with using linux's fragger/defragger in sufficient detail, would rather not clutter the log with a repeat [10:30]
mircea_popescu: meanwhile if every single 13 byte posupdate takes 16kb... that's insanity. [10:30]
mod6: ben_vulpes: bitcoind has been stopped, and lovelace has been shutdown with `shutdown -h now`. Feel free to pack it up whenever you're ready. Thanks. [10:30]
asciilifeform: mircea_popescu: realize that the linux frag reassembler doesn't give you anything near GB buffer [10:32]
asciilifeform: once you have any substantial traffic density, it'll simply start dropping. [10:32]
mircea_popescu: nobody here but you is discussing that. [10:32]
asciilifeform: ( it's a coupla kB typically ) [10:32]
mircea_popescu: my problem is that i can't ~not~ have 2 sizes of udp packets. [10:33]
mircea_popescu: diana_coman do you see a way out of this ? [10:33]
asciilifeform: the way i'd do it, is to have e.g. 1400 byte packets , and they're authenticated (e.g. client gets seekrit 512bit turd, and keccak(turd + payload) is a field in those 1400) , and ~then~ there is a flag for whether the packet is part of a e.g. 8 byte sequence that gotta reasm, or not . [10:35]
asciilifeform: i.e. internal defragger . [10:35]
asciilifeform: err, not 8 byte, 8 packet [10:35]
mircea_popescu: asciilifeform and the attacker sends you sequence-1 packets. and you hold them. and as i said, "doesn't take so much work to ask me to hold 16gb of chunks." [10:35]
asciilifeform: attacker can't send anyffing unless he has a valid key [10:35]
mircea_popescu: i am not so interested in holding on to chunks of future. [10:36]
mircea_popescu: jesus. [10:36]
asciilifeform: ( he can send, but it gets tossed in O(1) ) [10:36]
mircea_popescu: looky, we're discontinuing this discussion, because you've not taken the time to familiarize with priors and i don't judge it's worth your time to do so, or mine to make you do so. [10:36]
asciilifeform: my observation is strictly in re linux defragger gives you no way to filter, whereas hand-sewn -- would. but it is not my intention to prevent folx from pissing on erry possible electric fence, i'ma leave it there. [10:37]
asciilifeform: and pretty sure i grasp the priors. for instance, the proggy i originally wrote the udp thing for, operated in 64kB chunks. [10:38]
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 ) [10:44]
a111: Logged on 2018-10-02 14:30 mircea_popescu: this must-have magical packet of 16kb is extremely rare -- basically only sent when new client making new account. [10:44]
mircea_popescu: right! [10:44]
mircea_popescu: see ? it's not that i hate you, but we gotta talk of the same things to talk to any sort of productive end. [10:44]
asciilifeform: no i get it [10:45]
mircea_popescu: here's the bojum with that : soner or later, you gotta meet new people. the DEFINITION of "new people" is "no way to secret prior". so... [10:46]
asciilifeform: right [10:46]
asciilifeform: i'd have a separate box for new acct regs, that eats rsagrams.. [10:46]
mircea_popescu: server as it stands now doesn't talk to any new people, hence the "talk to mp" thing in client. [10:46]
asciilifeform: ( or at least separate nic ) [10:46]
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 [10:47]
mircea_popescu: i can't have as many interfaces as packet types for crying out loud. [10:47]
asciilifeform: as i currently understand, the only non-negotiably 'heavy' one is the new acct packet [10:48]
asciilifeform: so there are 2 fundamental types [10:48]
asciilifeform: ( the serpent packets are constrained to simply multiples of 128 ) [10:49]
mircea_popescu: well, rsa packets are 4096 bits multiple serpent packets are multiples of 128. rsa key exchange is 16kb fix. [10:50]
asciilifeform: so this'd easily cut into 1 process that eats always 4096bit, and another that eats 16kb. [10:50]
asciilifeform: ( serpent can pad into 4096 ) [10:51]
mircea_popescu: yes but i can't possibly turn http://btcbase.org/log/2018-09-28#1855277 into 4096 bit and live. [10:52]
a111: Logged on 2018-09-28 05:07 Mocky: http://btcbase.org/log/2018-09-28#1855218 >> players in sight of each other, all getting position updates for all others is *THE* central scaling 'n squared problem' for mmo. 20 byte position sent 4 times per second to 100 players is 8k/s per player. and 4 updates per second is really not enough for good playability when you factor in the round trip lag. 15/s is less draconian (many games send 30-60). 100 players gathered with 15 updates [10:52]
mircea_popescu: heck, im currently proud i took that 20 down to 13. [10:52]
asciilifeform: 4096bit is 512byte, you're sending 1500 frame always, even if your nominal packet is 3bytes long. simply how ethernet worx. [10:52]
asciilifeform: i.e. the space saving is illusory. [10:53]
asciilifeform: this is that 'bit-packing variables' thing all over again. [10:53]
mircea_popescu: jesus christ you're right aren't you. [10:54]
asciilifeform: aha! i dun hate mircea_popescu's algo because his name starts with m!111 i simply rtfm'd... [10:54]
asciilifeform: ( and peeked at what actually moves down my wire.. ) [10:55]
asciilifeform: anyway i'ma bbl, meat. [10:55]
mircea_popescu: it's funny how "optimization" lures the mind. [10:56]
Mocky: if you accept 16k new-acct packets seems just as easy to http://btcbase.org/log/2018-10-02#1857229 but further, if you rely on external frag-reassm it's even easier for attacker to prevent you from accepting *any* new account packets [11:08]
a111: Logged on 2018-10-02 14:35 mircea_popescu: asciilifeform and the attacker sends you sequence-1 packets. and you hold them. and as i said, "doesn't take so much work to ask me to hold 16gb of chunks." [11:08]
Mocky: frag reassembly in-program can use a buffer of specified size, just as is done externally. so excess chunk memory overhead is known up front [11:10]
Mocky: http://btcbase.org/log/2018-10-02#1857260 I see anything like this in the logs, do you have a link? [11:24]
a111: Logged on 2018-10-02 14:53 asciilifeform: this is that 'bit-packing variables' thing all over again. [11:24]
Mocky: *don't see* [11:24]
mircea_popescu: Mocky http://btcbase.org/log/2018-09-18#1851193 or http://btcbase.org/log/2017-11-22#1742261 or http://btcbase.org/log/2017-11-14#1738259 or etc. [11:36]
a111: Logged on 2018-09-18 14:27 mircea_popescu: what it is is certainly <1kb say. wasting the occasional portion of a kb is not so unlike wasting the occasional portion of a 64 bit register to represent a boolean value. [11:36]
a111: Logged on 2017-11-22 23:03 mircea_popescu: it's bullshit all the way down, "the 4096 bit block gets cut into 16 sub blocks to be fit into rotorizers that cut each block into 64 bits and process with their 4 bit s boxes". because we're from the fucking cartoons. [11:36]
a111: Logged on 2017-11-14 20:35 mircea_popescu: asciilifeform typical pc has the following situation : 64 bit registers, 128 bit memory, 1024 bit disk sectors, 64 mb video buffers, and atop sitting a drunk driver who thinks 8 bits are a byte. [11:36]
Mocky: ah ok, thx [11:38]
mircea_popescu: there's more, somewhere i say "meanwhile people figured out the complexity's not worth the saving" and etc. recurrent topic. [11:40]
diana_coman: Mocky, if I get this right you argue that it's better to do frag internally because can't trust externally to not fuck up the line entirely as attack vector? [11:42]
Mocky: yes [11:42]
mircea_popescu: um. [11:43]
Mocky: e.g. attacker floods with packet frags prevents legitimate frags from ever being reassembled, instead silently dropped, server is none the wiser [11:45]
mircea_popescu: there are no frags. [11:45]
diana_coman: he is talking of the new rsa packets that are biggest [11:46]
diana_coman: so will get presumably fragged [11:46]
mircea_popescu: iirc 20kb packets made it over test [11:46]
Mocky: 16k packet -> 1500 MTU [11:46]
diana_coman: but honestly I don't see that to be such a huge problem [11:46]
mircea_popescu: Mocky 16kbits, you realise. [11:46]
Mocky: nope, missed that [11:46]
mircea_popescu: 4x rsa chunk. 2048 bytes. [11:47]
mircea_popescu: and in our tests, we saw unfragged 20-50kB packets. [11:47]
diana_coman: mircea_popescu, uhm, they made it through - presumably fragged though? [11:48]
mircea_popescu: ie, mtu is two things : no smaller frame shall issue from interface and larger packets MAY (but don't have to) travel as multiple frames. [11:48]
mircea_popescu: diana_coman well, possibly. iirc we didn't specifically check for that. [11:48]
diana_coman: precisely I think that in principle there is a possibility of that "attack" but I fail to see that it's worth much really [11:48]
asciilifeform: mircea_popescu: there are no frames bigger than 1500 ( aside from exotic lans ) [11:49]
diana_coman: so basically what, for as long as attacker can keep flooding , presumably no new accounts although there might still be some that make it through? [11:49]
asciilifeform: your heavies got fragged & reasmed by receiver [11:49]
mircea_popescu: asciilifeform so interface silently and timely reassembled 50kb packet out of 30 fragments ? [11:49]
asciilifeform: yes [11:49]
mircea_popescu: pretty good. [11:49]
mircea_popescu: anyway, i have no intention to deal with udp flood at gameserver level. [11:50]
Mocky: I'd expect frag and auto reassemble to work well in low volume conditions [11:50]
asciilifeform: try it with saturated receiver tho. [11:50]
asciilifeform: Mocky: errything worx great with quiet volume. [11:50]
mircea_popescu: of course... if we used smaller rsa keys we could fit in the mtu... [11:50]
diana_coman: eulora-sized rsa, hm [11:51]
mircea_popescu: but i mean... it's for a reason, not just cuz bored. [11:51]
mircea_popescu: i mean, really, 2048, not 1460 ? written in heavens or what ? [11:51]
mircea_popescu: suppose i make the rsa packet 1498 bytes. this then means 2996 bit rsa. problem ? [11:54]
Mocky: well including udp header, like 1470 to 1480 of payload available [11:56]
asciilifeform: afaik it's not unlike diff b/w a 25 and 50 megatonne nyook [11:56]
asciilifeform: i.e. large on paper, but ~sams physical effect [11:56]
asciilifeform: *same [11:56]
diana_coman: from a practical point of view it does mean that Eulora doesn't use directly TMSR RSA keys though [11:58]
mircea_popescu: im not sure anyone'd want to use his main key for this anyway [12:08]
mircea_popescu: but yes, as far as anyone knows 2048 bit keys perfectly safe, now and for the foreseable future (this isn't a comment on koch faux-pgp, which unsafe at any length as well documented in logs qntra and so on). [12:09]
diana_coman: yes anyway it's basically a knob to turn, not a big issue in itself [12:09]
asciilifeform: fwiw asciilifeform is still sitting on top of a 2048b main key [12:09]
mircea_popescu: i'm going to re-write the rewrite of comms protocol with this new paradigm. [12:09]
asciilifeform: ( will move when finally kerosene poured on gpg ) [12:09]
mircea_popescu: let's calculate this precisely. so what size is my actual payload here, 1468 reliably ? [12:10]
mircea_popescu: ( and btw diana_coman it's entirely possible this will mean republic might well inherit the format, seeing how the problem we are dealing with isn't of our own make -- others will run into it too.) [12:11]
asciilifeform: mircea_popescu: 1500(ethernet frame) - 20 byte (ip header) - 8 byte == 1472 [12:12]
asciilifeform: ( 1472 remains for programmable payload ) [12:12]
mircea_popescu: am i absurd in wanting to start from 1499 rather than 1500 ? [12:12]
asciilifeform: i can't think of why, but it dun do any harm afaik [12:13]
mircea_popescu: sure it do harm, you lose on some bytes. [12:13]
asciilifeform: the nic will simply insert a 0 octet [12:13]
asciilifeform: well yes, in that sense. [12:13]
mircea_popescu: alright then, ima put 1472 bytes helo packet meaning 2944 bit rsa keys. [12:14]
Mocky: 1472 is what i've used in the past [12:14]
asciilifeform: Mocky: it's the theoretical max udp-over-ethernet aha [12:14]
asciilifeform: ( not taking into consideration weirdo lans with 'jumbo' nics etc ) [12:14]
mircea_popescu: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in the rsa packet ? with oaep and everything ? [12:16]
mircea_popescu: !Qcalc 2944 / 1384 [12:17]
lobbesbot: mircea_popescu: 2.12716763006 [12:17]
mircea_popescu: holy shit, what if i can shave it down to 3x ?! [12:19]
mircea_popescu: !Qcalc 1472/3 [12:19]
lobbesbot: mircea_popescu: 490.666666667 [12:19]
Mocky: http://btcbase.org/log/2018-10-02#1857302 >> still will be filtering incoming UDP by known IPs and preferred serpent keys though anyway, correct? [12:19]
a111: Logged on 2018-10-02 15:50 mircea_popescu: anyway, i have no intention to deal with udp flood at gameserver level. [12:19]
mircea_popescu: Mocky nope, by size. [12:19]
mircea_popescu: rsa-size and serpent-size packets handled, rest discarded (and sources punished) [12:20]
Mocky: ok but if size matches still have to attempt decryption even if contains garbage? [12:21]
mircea_popescu: yes. [12:21]
mircea_popescu: !Qcalc 1472/128 [12:21]
lobbesbot: mircea_popescu: 11.5 [12:21]
asciilifeform: i expect decryptions will be the principal cpu expense of running a rsatronic box. at least until the fyootoor day of fpga etc [12:22]
mircea_popescu: possibru [12:22]
asciilifeform: fortunately they parallelize linearly [12:22]
mircea_popescu: the thing is -- new accounts handled "as resources permit" anyway, so... [12:22]
asciilifeform: ( farm out to as many cores as you like ) [12:22]
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. [12:25]
mircea_popescu: 2. fixed size 1408 byte serpent packets. [12:26]
diana_coman: mircea_popescu, 1872 useful bits in 3920-bit rsa, confirmed [12:29]
mircea_popescu: is serpent 128 bits or 128 bytes ? [12:36]
mircea_popescu: bits so then [12:38]
mircea_popescu: 2. fixed size 1472 byte serpent packets. [12:38]
diana_coman: bits, yes [12:38]
mircea_popescu: yuppers. 1470 vs 1472, pretty as can be. [12:38]
diana_coman: ha, quite [12:39]
mircea_popescu: in other very sads, the new p.bvulpes machine is VERY fucking slow. [12:48]
mircea_popescu: * About to connect() to p.bvulpes.com port 80 (#0) [12:51]
mircea_popescu: * Trying 51.15.42.105... Connection timed out [12:51]
ben_vulpes: that's odd, i'll look [13:28]
mircea_popescu: ben_vulpes nah, no need, by now i mostly suspect my route was bad. [13:29]
ben_vulpes: i was going to ask for a traceroute [13:29]
ben_vulpes: mod6: ack [13:29]
asciilifeform: lobbes: plox to confirm when satisfied that your rk worx correctly [13:34]
deedbot: http://bimbo.club/?p=38 << Bimbo.Club - TMSR Log Summary - 9/28/2018 [13:53]
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 [13:54]
asciilifeform: ~pigeons~ manually transported, nicoleci [13:55]
mircea_popescu: !!up nicoleci [13:58]
deedbot: nicoleci voiced for 30 minutes. [13:58]
mircea_popescu: meanwhile @birdcage, "<nicoleci> im getting so frusterated with these logs <mircea_popescu> yssat ? <nicoleci> i understand every 45th line" [13:58]
asciilifeform: lol i wouldn't have guessed that it'd be ~that~ line.. [13:58]
asciilifeform: i thought pigeon were universal. [13:59]
mircea_popescu: she didn't go to kindergarten. [13:59]
asciilifeform: ( my local ww1 aviation museum has entire glass case of stuffed 'famous' carrier pigeons. so they defo know about'em in usa... ) [13:59]
mircea_popescu: chick's injun, they got their own schools. [14:00]
asciilifeform: same place where they have the bed the wrights slept in, the shitter they shat in, etc [14:00]
asciilifeform: lolk [14:00]
nicoleci: im not going to make excuses for not connecting the pigeon talk, but no fucking clue what http://btcbase.org/log/2018-09-28#1855365 means [14:04]
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. [14:04]
lobbesbot: nicoleci: Sent 16 hours and 5 minutes ago: <asciilifeform> s/to/too [14:04]
mircea_popescu: nicoleci rsa keys are useless when the key is short. do you understand how rsa works ? [14:05]
nicoleci: mircea_popescu: not at all. [14:06]
mircea_popescu: alright. can you tell me the prime factors of the number 6 ? [14:06]
nicoleci: ah 1,2,3,6 [14:16]
mircea_popescu: ok. 1 and 6 we ignore, as they're trivial for our exercise. [14:17]
mircea_popescu: now, can you tell me the non-trivial prime factors of 221 ? (but without looking anywhere online). [14:17]
nicoleci: lol, no [14:18]
mircea_popescu: can you tell me what's 13 * 17 ? [14:19]
nicoleci: 221 [14:20]
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 [14:20]
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. [14:21]
mircea_popescu: some clever bits of math permit one to encrypt a message with the use of that 221 so that only he who knows 13 * 17 =221 can ever get it back out. [14:21]
nicoleci: ahh i see [14:22]
mircea_popescu: yw. [14:22]
BingoBoingo: Ah, slave priviledge in action. Countless ninjashoguns weep as the combination of right behavior and right parts allows the priviledged to learn in hallowed logs. [14:23]
BingoBoingo: #WoTInAction [14:23]
nicoleci: yeah thanks, Master. privilege in knowledge, torture in a chromebook [14:24]
mircea_popescu: http://trilema.com/2018/euloras-communication-protocol-restated/ << republished to significant change diana_coman Mocky asciilifeform an' whoever else may be interested. comments welcome! [14:28]
deedbot: http://qntra.net/2018/10/university-of-brighton-takes-ambiguous-position-on-program-supporting-coed-to-gentlemen-connections/ << Qntra - University Of Brighton Takes Ambiguous Position On Program Supporting Coed To Gentlemen Connections [14:30]
mircea_popescu: ahaha [14:31]
mircea_popescu: the 1 in 6 far exceeds the 1 in 20 or so females worth the fucking in ~anyone's estimation. [14:31]
BingoBoingo: And yet 100% of them are only 19 once [14:32]
BingoBoingo: Meanwhile from other mines: "I’m active in supporting LGBT causes. My boyfriend recently said that “this whole LGBT thing has gone way too far” and that he’s no longer sure what to think about same-sex marriage, even though he had thought he supported it. Worse, he said that maybe the original civil rights movement went too far, and perhaps businesses should be allowed to racially discriminate if they want to. In fairnes [14:37]
BingoBoingo: s, that was in response to me pointing to that as a precedent for LGBT rights, but I’m not sure that makes it better. I’m just aghast. How can I make him see how wrong he is?" [14:37]
* asciilifeform loox at mircea_popescu's item.. [14:37]
asciilifeform: mircea_popescu: is the 20 may date intentional ? [14:38]
Mocky: original pub date [14:38]
asciilifeform: aaaah edited aite [14:38]
mircea_popescu: right. [14:39]
mircea_popescu: BingoBoingo doh. let's check back with the aghast lonely hearts club when we're discussing how business can keep slaves (ie, them) if they feel like it. [14:41]
asciilifeform: 'n*(4*int64 + int32) (32 bytes each key followed by a 4 byte ID calculated as the keccak hash of the key itself)' << unless i misread, how does one get a 4byte output from keccak ? [14:41]
mircea_popescu: by setting it to spit out 4 byte output ? [14:42]
asciilifeform: does diana_coman's keccak do this ? ( aside from the q of what does a 32bit hash output win, it aint exactly hard to collide into a desired 32bit regardless of how you make hash algo.. ) [14:43]
mircea_popescu: but this'd be a collision inside an encrypted packet. [14:43]
asciilifeform: so moar of a checksum ? [14:43]
mircea_popescu: im really only using it as an adhoc crc possibly should either get rid of it altogether, or implement a proper ec. [14:43]
asciilifeform: aaah so not asked to be resistant, aite [14:43]
mircea_popescu: ya [14:43]
asciilifeform: i'd use ordinary crc32 for such item, much cheaper cpuwise [14:44]
mircea_popescu: in ~principle~ eve can't even know what serpent keys either server or client are using. [14:44]
asciilifeform: right [14:44]
mircea_popescu: but yes, i am seriously considering this. [14:44]
* asciilifeform reads the other moving parts... [14:44]
asciilifeform: 'text, consisting of int32 (keccak hash of top level itemxviii)' << i assume ditto [14:45]
mircea_popescu: anyways, i shall now torture girls @ beach. will read all comments and everything tonite. [14:45]
asciilifeform: and in 4.8 same [14:45]
asciilifeform: aite [14:45]
asciilifeform: i dun get how 'int8 (equal to 18364757930599072545' worx [14:46]
asciilifeform: on my planet, 'int8' means 8 bits [14:47]
asciilifeform: int16 - 16, int32 -- 32, int64 -- 64 [14:47]
* asciilifeform bbl,meat will come back to this item [14:48]
diana_coman: asciilifeform, keccak can spit out as many or as few bits as you want it to, not sure what is you q there re keccak [14:53]
diana_coman: your* [14:54]
diana_coman: specifically, bit-level version gives bit-level precision so one can ask for as many bits as they want workhorse byte-level keccak implementation works at byte-level so it will spit out as many *bytes* as you ask for (see http://www.dianacoman.com/2018/02/08/eucrypt-chapter-9-byte-order-and-bit-disorder-in-keccak/#selection-193.1-197.51 ) [14:56]
diana_coman: http://btcbase.org/log/2018-10-02#1857391 -> lol, they are also just... not prime [15:05]
a111: Logged on 2018-10-02 18:17 mircea_popescu: ok. 1 and 6 we ignore, as they're trivial for our exercise. [15:05]
diana_coman: http://trilema.com/2018/euloras-communication-protocol-restated/#comment-126805 - waiting in the queue [15:23]
asciilifeform: http://btcbase.org/log/2018-10-02#1857438 << ok i wasn't sure whether diana_coman's keccak knew how to output arbitrary bitness. but my other point was that a 32bit hash may as well be crc32, there can be no notion of collision resistance when yer output is 32b. [15:37]
a111: Logged on 2018-10-02 18:53 diana_coman: asciilifeform, keccak can spit out as many or as few bits as you want it to, not sure what is you q there re keccak [15:37]
asciilifeform: diana_coman: can you clarify re the 'int8' thing plox ? [15:39]
diana_coman: asciilifeform, int8 is indeed meant to be on 8 bits so no idea what that thing there is fwiw I added it to my comment on the article with ref to your q here in the logs too because I'm puzzled by it too [15:44]
diana_coman: re collision yes, it's clearly not collision-resistant [15:45]
diana_coman: the eucrypt keccak implementation uses an out parameter for output and so it will fill whatever the caller provides [15:45]
ben_vulpes: http://archive.fo/WeQ7Q << ruralia continues to deliver lulz: "booby trapped wheelchair", "hot tub attached to tripwire" "elder abuse" [16:27]
asciilifeform: ben_vulpes: poor idjit. could've set up proper dynamite, not as if he could sizzle in electric chair twice. [16:29]
asciilifeform: '.410-guage shotgun pellet' lol. [16:31]
ben_vulpes: sad fate to be remembered for failing to take out agents of the imperium given ~unlimited time and inclination to prepare. [16:31]
asciilifeform: Fuck Moar Cousins, i guess.. [16:31]
ben_vulpes: the many sleepless nights of the rural amphet didn't help. [16:32]
asciilifeform: between rotgut, dope, 6 generations of fucked cousin, mcfood -- not much chance left for brain [16:34]
deedbot: http://bingology.net/2018/10/02/haiku-r1beta1-thoughts/ << Bingology - BingoBoingo's Blog - Haiku R1/beta1 Thoughts [17:04]
asciilifeform: http://bingology.net/2018/10/02/haiku-r1beta1-thoughts/comment-page-1/#comment-504 << BingoBoingo [17:09]
BingoBoingo: asciilifeform: replied [17:21]
asciilifeform: BingoBoingo: loox like they lifted various drivers from freebsd, since i last saw [17:22]
BingoBoingo: Other parts as well. [17:23]
asciilifeform: so in effect it's freebsd but with an oddball incompatible thing in place of x11 [17:24]
asciilifeform: sorta like an open sores crapple. [17:24]
BingoBoingo: Well, the microkernel thing is different [17:24]
asciilifeform: still massive ball o' C [17:25]
asciilifeform: hence 'like crapple' [17:25]
BingoBoingo: Sure. Its the sort of thing you'd stick in a lobby to let people check the weather. [17:25]
BingoBoingo: Or throw on a video playing box [17:25]
asciilifeform: i'd stick a kernel that dun crash on these.. [17:25]
asciilifeform: and ugggh c++ kernel... [17:27]
asciilifeform: ( https://github.com/haiku/haiku/tree/master/src/system/kernel << behold and shudder ) [17:27]
BingoBoingo: ugh [17:27]
asciilifeform: reminds me of 'reactos' ( another oddball 'man alone' item believe or not : attempt to open sores re-create... winblowz ) [17:28]
BingoBoingo: The big difference between Haiku and ReactOS is in Haiku spreading works (TM)(R). Reactos hasn't made it that far yet. [17:32]
asciilifeform: spreading worx pretty easily when you lift all of the iron-specific C hairballs from existing open sores [17:33]
asciilifeform: the q is, what is gained thereby [17:33]
BingoBoingo: novelty [17:36]
asciilifeform: possibly i find novelty 'for sake of novelty' to not be auto-attractive but imho these folx took the same baccilae that made microshit what it is ( cpp kernel, kernelized gui, 'desktopization' ) and somehow supposed that it'd add up to different result than microshit's.. [17:38]
asciilifeform: ( and on top of this imported the worst gnarl from freebsd... ) [17:39]
asciilifeform: seems like there's even 1990s liquishit from the original 'beos' in there. [17:40]
BingoBoingo: Well, it isn't novelty for the sake of novelty. Novelty for the sake of highlighting how broken Ubuntu is. [17:41]
BingoBoingo: This piece of weird with all of its flaws... still works better than Ubuntu [17:42]
asciilifeform: BingoBoingo: even win10 loox pretty good when laid next to shituntu. [17:42]
asciilifeform: on just about erry metric.. [17:42]
BingoBoingo: Never tried it myself [17:43]
asciilifeform: wasn't an invitation to try it, lol. but statement of phakt. [17:43]
asciilifeform: BingoBoingo: i strongly suspect that a box that smoothly runs the haiku thing will also run freebsd.. [17:44]
trinque: huh, I ran one of the early x86 Be versions for a bit, didn't hate. [17:44]
asciilifeform: trinque: i dun hate. but gotta point out what it is. [17:44]
trinque: but yes, can't disagree with asciilifeform [17:44]
BingoBoingo: It ran openbsd fine, runs a linux fine now, FreeBSD was flakey last time I tried it on this one [17:45]
asciilifeform: at least terry davis was straightforward about not having iron drivers. [17:45]
asciilifeform: he refrained from importing world's 2nd gnarliest shitstack. [17:46]
asciilifeform: i favour folx who are honest, 'i dun have drivers', over gabriel_laddels [17:47]
BingoBoingo: Well, Uncle Terry is the Saint everyone thought Linus was [17:48]
trinque: pbuh [17:48]
BingoBoingo: Terry didn't let his daughter's feelz get in the way of his cause [17:50]
asciilifeform: BingoBoingo: i suppose that's 1 way to 'saint' -- skipping straight to face to face with odin.. [19:24]
BingoBoingo: TempleOS does exactly as advertised [19:24]
BingoBoingo: And now terry in in Valhala for it [19:25]
* BingoBoingo curious if gabriel ever got that amputation [19:26]
asciilifeform: meanwhile, in trb observatory, http://nosuchlabs.com/pub/trb/10_2_moar_ProcessBlock.txt << caught up.. [19:26]
asciilifeform: BingoBoingo: for all i know he got head amputation. [19:26]
BingoBoingo: Or maybe got adlai'd into a rehab [19:27]
asciilifeform: BingoBoingo: is 186.50.24.80 , castle BingoBoingostein ? [19:28]
BingoBoingo: It doesn't appear to be at the moment, but it could have been [19:29]
asciilifeform: aah dynamic [19:29]
asciilifeform: aite [19:29]
asciilifeform: ( i have dynamic here also, for some reason local fuckheads want 2x the dough to make static. but it changes 1-2x / year, thus far i live with it ) [19:30]
BingoBoingo: Here dynamic means dynamic [19:31]
BingoBoingo: It's also possible there's another trb node I haven't put my own eyes on running on a residential connection in this country [19:33]
asciilifeform: i've been thinking i oughta conjure up moar trb nodez, but erry time i sit down and look to do it, end up thinking 'why give money to heathen derps'. but on other hand it dun do much good to put 9000 nodes all in pizarro. but to which heathen can give moneys without retching.. [19:33]
asciilifeform: trinque's asian noad seems to be well-behaved [19:35]
asciilifeform: but it for same reason as stated earlier it wouldn't do so much good if i put a noad in same place [19:35]
asciilifeform: so presently i end up shelving the idea erry time it makes circle round my conveyor [19:36]
asciilifeform: sooo if anybody ( mircea_popescu ? diana_coman ? ) knows of some place that 1) isn't complete shit 2) doesn't have a trb noad living there yet -- plox to write in. [19:37]
asciilifeform: ( ideally : on some ~continent~ that dun have one yet, imho ) [19:38]
asciilifeform: diana_coman: do you have one back in 'old blightey' ? or know of a place there where i oughta put one [19:39]
BingoBoingo: asciilifeform: Have an eta on when to do the diana_coman switch? [19:39]
asciilifeform: BingoBoingo: how about nao. [19:39]
BingoBoingo: asciilifeform: Aite, lemme put pants on [19:39]
BingoBoingo: And finish this balcony coffee [19:39]
asciilifeform: BingoBoingo: i'ma meatspace for ~20min, should give you enuff time for leg [19:40]
asciilifeform: BingoBoingo: when you get to the dc, feel free to pull lobbes's drive from dulap ( label it ) and insert 1) first, diana_coman's 2) 30sec later, the new [19:40]
asciilifeform: BingoBoingo: ping me in #p when ready. [20:01]
asciilifeform: !Q later tell diana_coman your rk is redisked! and running you may want to stand up yer www server (iirc it doesn't run on boot) [20:37]
lobbesbot: asciilifeform: The operation succeeded. [20:37]
asciilifeform: diana_coman , lobbes : your old drives are currently in dulap, lemme know when you're ready to have'em reformatted ( so your boxen dun try an' boot from'em instead of the primary ) and reissued to you as secondary disks. [20:38]
asciilifeform: BingoBoingo: i think this is all for today in the bilge [20:38]
BingoBoingo: Aite, coming up [20:38]
asciilifeform: ty BingoBoingo ! [20:38]
asciilifeform: a+++ as usual. [20:38]
lobbes: http://btcbase.org/log/2018-10-02#1857370 << I can confirm rk is working. ty! [20:48]
a111: Logged on 2018-10-02 17:34 asciilifeform: lobbes: plox to confirm when satisfied that your rk worx correctly [20:48]
lobbes: http://btcbase.org/log/2018-10-02#1857138 << I can also confirm that this was exaaactly what was in my 40gb error log.. oof (btw ty asciilifeform for teh heads-up) [20:48]
a111: Logged on 2018-10-02 09:46 diana_coman: http://btcbase.org/log/2018-10-02#1857110 -> if it's anything like mine, it'll be mostly loud complaints from php because "time zone not set!!!" and similar (apparently php version on the RC is too new for its own good) [20:48]
* asciilifeform bbl,meat [20:48]
asciilifeform: oh btw, lobbes & diana_coman , dun forget to set your rk's clocks. [20:49]
* asciilifeform genuinely bbl [20:49]
BingoBoingo: tyvm [22:05]
lobbes: http://btcbase.org/log/2018-10-03#1857528 << forgot to respond to this, but you have my a-ok to reformat old drive. and thank you gentlemen for the smooth swap [22:23]
a111: Logged on 2018-10-03 00:38 asciilifeform: diana_coman , lobbes : your old drives are currently in dulap, lemme know when you're ready to have'em reformatted ( so your boxen dun try an' boot from'em instead of the primary ) and reissued to you as secondary disks. [22:23]
lobbes: (obligatory pizarro pitch to log readers: where else can you have 100% context on -why- service is being done on your box, as well as watch it unfold real-time? Compare and contrast with, say, this example from heathenlandia (Edis) >> http://archive.is/NVpIR) [22:24]
mircea_popescu: ikr! [23:01]
mircea_popescu: the incredible transparency they got going is actually a very strong selling point [23:03]
mircea_popescu: just needs packaging & being market communicated. [23:04]
trinque: "we slay incas" while cute, communicates nothing except "you're not in the in-group" [23:18]
trinque: oughta say something about why the fuck someone wants a republican ISP [23:19]
asciilifeform: trinque: yea the inca thing is placeholder [23:39]
asciilifeform: trinque: the text to answer 'wai republican isp' exists, unfortunately it's a coupla hundr MB, aka.. the l0gz [23:40]
asciilifeform: if can think of a way to conpress! [23:40]
asciilifeform: ( pretty hard, imho, to even begin in language heathens might understand.. ) [23:41]
asciilifeform: *compress [23:41]
trinque: I'd lean hard on the "we're humans" thing, communicate that [23:42]
trinque: somebody wants to know what makes an actual human later, great for him [23:42]
trinque: i.e. there's this fine gentleman BingoBoingo actually in the bowls of the machine, steadfastly giving a shit. [23:44]
trinque: polymath madman assembling world's only sane ARM hosting, etc [23:45]
BingoBoingo: Condensing these logs into marketing is a thing being pondered [23:46]
* BingoBoingo returns from doing the necessary work of walking the beach at night and tormenting the Peruana by reporting how incredibly safe and secure it was [23:48]
Category: Logs
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.
Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.