Show Idle (>14 d.) Chans


← 2021-09-18 | 2021-09-20 →
10:23 scoopbot New post on Blog of Peter Lambert: A funny thing about Python
~ 6 hours 7 minutes ~
16:31 shinohai $vwap
16:31 busybot The 24-Hour VWAP for BTC is $ 47625.80 USD
~ 2 hours 29 minutes ~
19:00 user how's most senile republic of bitcoin going?
19:06 user OK, I'll leave a few stupid comments about Pest spec.
19:09 user 512-bit MAC seems overkill, 160 bits ought to be enough for everyone (c). Supplying a MAC for all of your contacts looks more practical then.
19:09 dpb user, check out http://atruechurch.info/ and don't go to hell like the rest of the world!
19:10 user dpb, you should just stand up a bot to spam that
19:16 user I assume HMAX is chosen because polynomial MAC is too must a footgun?
19:18 user *too much
19:20 asciilifeform user: do we know one another? ( your intro suggests that you were lurking in the era of mp ? )
19:21 asciilifeform aa ha
19:21 apeloyee I still have my GPG key, though probably didn't protect it anywhere as well as you
19:22 asciilifeform user: re mac -- in next draft (0xFD) i've hmac-384 for the sigs, so to free up some room to make payload a multiple of 16, the serpent blocksize. i sure as fuck aint using hmac256 tho, what with the abundance of sha256-bruteforce silicon on planet3. and don't see why the hell to use even smaller.
19:22 apeloyee you can stuff MACs over plaintext for all your phriendz you don't have a direct connection to
19:23 asciilifeform you still need 1 per peering
19:23 asciilifeform and if you have a shared key with someone, and can use a mac, that person is a peer of yours
19:23 apeloyee true, but you probably don't have very many of them.
19:24 asciilifeform conversely, if someone is no peer of yours, you have no shared key with which to mac with him
19:24 apeloyee If you had, the chaneel probably would be unbearably spammy for you
19:24 asciilifeform how is this different from traditional chatisms (e.g. irc) ?
19:24 apeloyee I'm talking about peer you don't have direct connection to
19:25 apeloyee that is, you have a shared secret
19:25 asciilifeform if he's your peer, you have a direct connection definitionally. and vice-versa.
19:25 asciilifeform what does apeloyee suppose is the meaning of 'peer, but no direct connection' ?
19:25 asciilifeform the spec permits no such thing.
19:25 apeloyee suppose the wreckers interfering with you connection
19:26 apeloyee so you can directly reach A but not B
19:27 apeloyee after all, if everyone can reach everyone, what's the point of even having a relay mechanism?
19:28 asciilifeform apeloyee: the point is in fact largely so that a net (connection graph that is not necessarily a clique) can form
19:28 asciilifeform apeloyee: imho selective dropping of packets is at the bottom of the list for problems. esp. if you aint poor and control a number of ips which are not used for anything else.
19:30 asciilifeform as for indirect messages, so long as you can reach a ~subset~ of your peering -- yer in biz.
19:30 dulapbot Logged on 2021-09-13 22:03:26 asciilifeform: thinking further re the algo -- can be simplified as follows :
19:30 asciilifeform ( ^ proposed 0xFD algo for in-wot hearsay marking )
19:32 * asciilifeform ftr thinks that a scenario where you can only -- and for appreciable length of time -- contact one or two of your peers -- is sufficiently exotic, and dire, that your text oughta consist of a gpggram informing yer wot that you're stuck in war zone, or the like
19:33 asciilifeform the human-readable text, that is, rather than anything intended for machine to interpret
19:34 apeloyee wouldn't the same "don't be poor" and "don't be in war zone" argument apply to DoS against which "reject at line rate" is supposed to protect from?
19:35 asciilifeform apeloyee: this is idiotic sophistry and beneath contempt.
19:35 asciilifeform i will not dignify it with a reply.
19:40 apeloyee Blocking huge ranges of IP addresses is S.O.P. here. And your protocol requires me to trust the peers then.
19:44 apeloyee Will also say that if you're DDoSed (as in, the machine which you're using to access the internet), most of the legitimate packets will be simply lost. and you're lucky to have a few packed come through, can't rely on redundancy to tell the legitimate ones apart.
19:52 apeloyee finally, using this for large file transmission looks stupid. (it will just clog your pipe, transmitting the same thing to each of your peers; worse than bittorrent in that regard)
19:53 punkman apeloyee: simple file transfer would be more like direct message to single peer
19:53 asciilifeform apeloyee: file transfers strictly with direct messages
19:53 punkman and if you want to share with everyone, can just make torrent, perhaps with some mechanization
19:54 asciilifeform ( why on earth would attempt to do otherwise ? the kind of things folx ask about, sometimes boggles my mind... )
19:55 asciilifeform http://logs.nosuchlabs.com/log/asciilifeform/2021-09-19#1058630 << what would a protocol that ~does not~ 'require trusting the peers' look like ?
19:55 dulapbot Logged on 2021-09-19 15:40:28 apeloyee: Blocking huge ranges of IP addresses is S.O.P. here. And your protocol requires me to trust the peers then.
19:57 apeloyee Transmitting an RSA signature in addition to MAC, as discussed a few days before? We have established that to big traffic goes through relays, so the assumption that you can RSA-verify everying your peers transmitted to you is quite reasonable
19:58 asciilifeform http://logs.nosuchlabs.com/log/asciilifeform/2021-09-19#1058631 << this is correct, but explicitly handled -- a massively ddosed line will simply look like a very slow and lossy modem from the peer's pov. because the garbage does not impose any additional cost other than occupying bw.
19:58 dulapbot Logged on 2021-09-19 15:44:32 apeloyee: Will also say that if you're DDoSed (as in, the machine which you're using to access the internet), most of the legitimate packets will be simply lost. and you're lucky to have a few packed come through, can't rely on redundancy to tell the legitimate ones apart.
19:58 apeloyee or elliptic curve. Bitcoin
19:58 asciilifeform ugh
19:58 apeloyee works, after all
19:58 apeloyee where's RSAcoin?
19:59 asciilifeform there shall be no slow crypto with valuable longterm key in pest.
19:59 apeloyee is ECC a bigger "ugh" than serpent?
19:59 asciilifeform it is
20:00 asciilifeform let's start with the fact that there is no constant-time ecc in ada and probably won't be in my lifetime.
20:00 asciilifeform and if somehow existed, would not run on standard pc at e.g. Gb/s line rate with 1 sig per packet.
20:00 asciilifeform similar problem to rsa.
20:00 apeloyee I think your mind will be less boggled if you state your assumptions in the spec. (not poor, etc.)
20:01 apeloyee you don't bother to verify unless in message MAC'd by peer.
20:01 asciilifeform apeloyee: spec is actually a terrible document atm, full of holes wide enuff to drive a train through, and at least a coupla contradictions i suspect
20:01 apeloyee if he relays invalid sigs repeatedly, drop him.
20:02 apeloyee or stop verifying the sigs of $loathesome_fuck_you_don't_care_about
20:02 asciilifeform apeloyee: i get the intent (same as punkman's rsa idea more or less) but again the fits-in-head constant-time code does not exist.
20:02 dulapbot Logged on 2021-09-16 06:23:40 punkman: flow of messages that can be comfortably read as chat, is much lower than packet rate, I assume RSA (or maybe hash-based signature scheme) can keep up with that
20:02 asciilifeform and i aint interested in touching any other kind.
20:04 punkman asciilifeform: I got a poorly defined bit from spec "the AT is automatically updated by the station when a cryptographically-valid packet is received from a new address.". If you update AT just after verifying crypto, but not checking for dupes, wouldn't that mean I can send you replay from new ip and essentially blackhole any peer?
20:04 asciilifeform i also specifically like the idea of a non-numbertheoretical basis for the signatures -- will make it considerably easier to implement in fpga for baking dedicated (hardware) line-rate prefilters.
20:04 asciilifeform punkman: valid == passed all validation steps, incl. dupeism
20:04 asciilifeform ALL of them.
20:04 asciilifeform punkman: probably oughta lay it out pedantically so no possible ambiguity on the subj, i agree.
20:08 apeloyee going back, to fix the holes, it's needed to know what kind of attacks you consider and which "don't be poor"
20:09 asciilifeform apeloyee: let's expand on this, imho is a good q
20:09 apeloyee who should expand, me or you?
20:09 * asciilifeform will
20:10 asciilifeform probably oughta approach the q from another side. imho to explain 'why shouldn't a packet from an enemy eat more resources than the share of the bandwidth it occupies?' is rather like asking why shouldn't a petrol tank have 9000 little holes in its bottom.
20:11 apeloyee that I agree with
20:11 asciilifeform the latter doesn't become less funny simply because we aren't on idiot planet where somehow traditional for almost all petrol tanks to have 9000 holes the size of a penny in their bottoms
20:11 asciilifeform aha
20:12 asciilifeform so then, the 'ddos resistance' isn't an elaborate thing which has to be justified -- it is simply 'not have 9000 holes in the tank' imho.
20:12 apeloyee but re: poor connection, your response is "don't be poor", right?
20:12 asciilifeform it is the people who allow allcomers to tie up cpu with trivial effort, who oughta be made to explain themselves.
20:13 asciilifeform apeloyee: if you calculate a hypothetical cost of, for instance, running a traditional tcp www server in such a way as to be proof against arbitrary ddos -- it would approach the cost of a space fleet.
20:13 asciilifeform but otoh simply having a couple of spare internet connections, never used on any occasion other than when primary is dead -- is inexpensive and in fact rather common
20:14 asciilifeform 'don't be poor' is arguably a misleading phrase ( stole it from mp & co. ) -- better statement would be 'don't be a miser'
20:15 asciilifeform misers, as the proverb goes, pay twice.
20:15 punkman "don't be poor" is excellent heuristic, I use all the time with friends
20:17 punkman as in: stop putting so much effort into making "being poor" work, put more effort into "not being poor"
20:17 asciilifeform punkman: sometimes misunderstood (esp. by folx bent on misunderstanding) -- 'haha, you can't afford a death star, you're poor too'
20:19 apeloyee as someone said, "if you don't have 1G$, fuck off"(c)
20:20 asciilifeform apeloyee: btw if you missed, 'someone' is feeding the fish now in the ocean, 1e9$ didn't help, lol
20:20 dulapbot Logged on 2021-09-15 23:45:48 deedbot: asciilifeform updated rating of mircea_popescu from 2 to 1 << sleeping in davy jones's locker. RIP.
20:21 apeloyee my quotee is arrested, IIRC
20:21 asciilifeform ah then not familiar
20:22 apeloyee one Sergey Polnskiy. but that's off topic.
20:22 apeloyee *Polonskiy
20:24 apeloyee so, Pest isn't designed to operate under high packet loss, or with peers trusted only as far as you can throw them. what else?
20:24 asciilifeform aa the d00d who was rejected from space tourism for being fat
20:24 asciilifeform apeloyee: in 0xFD rev. there is 'getdata', which addresses loss
20:25 punkman asciilifeform: do datacenter-to-datacenter routing paths actually drop packets bigger than ~530 bytes?
20:25 asciilifeform (you get packet with 'selfchain' which doesn't correspond to the predecessor -- you issue getdata to the peer)
20:25 asciilifeform punkman: they do not. the problem with jumpopackets is that the frags are accepted 'on faith'
20:26 asciilifeform i.e. if you accept jumbograms, you're quite ddosable
20:26 punkman jumbograms are 65kb
20:26 punkman iirc
20:26 asciilifeform punkman: i'm abusing the terminology, factually. referring to anything that may be fragged.
20:27 punkman so if you put "no-frag" flag on 1kb datagram, they will frag anyway or drop?
20:27 asciilifeform apeloyee: 0xFD pest will operate under any packet loss condition other than 100%
20:28 asciilifeform punkman: depending on the iron between you and destionation, may sometimes even emerge intact on other side. or may be dropped, or fragged regardless.
20:28 asciilifeform but only <=508byte guaranteed not to frag.
20:28 asciilifeform (^ mass not incl. headers )
20:29 punkman why do we care about fragged packets though? we aren't gonna process frags in application side
20:29 asciilifeform http://logs.nosuchlabs.com/log/asciilifeform/2021-09-19#1058690 << the second clause also not factual -- you can communicate with 'not trusted further than you can throw' fella ~for so long as one of your peers~ (or your peer's peers, up to $depth) peers with him.
20:29 dulapbot Logged on 2021-09-19 16:24:26 apeloyee: so, Pest isn't designed to operate under high packet loss, or with peers trusted only as far as you can throw them. what else?
20:29 asciilifeform punkman: BECAUSE THEY AINT SIGNED
20:30 asciilifeform a frag isn't verifiable !!
20:30 asciilifeform it has to be 'taken on faith' until the other N-1 frags are in hand, and ~then~ you can maybe verify it.
20:30 asciilifeform until then it could be whatever.
20:30 punkman I mean this happens in network layer, not in application
20:30 asciilifeform and nothing stops allcomers from bombarding you with bogofrags and filling your buffers with liquishit.
20:30 punkman how does it make it easier to ddos me?
20:31 asciilifeform punkman: what's it matter ~where~ it happens? there's a finite buffer. which unauthenticated fuckwads can pump fulla shit.
20:31 asciilifeform punkman: do you understand what a packet frag is ? and how they are reassembled into original ?
20:31 apeloyee I meant that not-trusted *direct* peers are routinely used to relay stuff. the internet works that way, in fact. but not Pest.
20:32 punkman but they can do this anyway, unless I tell network side to disallow frags or something
20:32 asciilifeform punkman: naturally you config your network stack to immediately discard anything marked a frag.
20:32 punkman perhaps I'm missing something
20:32 asciilifeform i do.
20:33 apeloyee non-trusted would be useful strictly as proxies. in Pest, stuff they relay cannot be verified.
20:33 asciilifeform apeloyee: the way to have petrol tank that aint full of holes -- machines that cannot be brought down by arbitrary liquishit pumped in at line rate -- is to give NOTHING to the stranger. i.e. you're not in the peer set ? you don't even get ping answer. there is no other way.
20:33 dulapbot Logged on 2021-09-19 16:12:01 asciilifeform: so then, the 'ddos resistance' isn't an elaborate thing which has to be justified -- it is simply 'not have 9000 holes in the tank' imho.
20:35 apeloyee asciilifeform: what this has to do w/my question?
20:36 asciilifeform apeloyee: where's the question ?
20:37 asciilifeform ( maybe this thread will answer , incidentally ? )
20:37 dulapbot Logged on 2021-09-12 13:28:57 asciilifeform: punkman: the whole protocol is one big 'weird contortion' around the fact that we can't do rsa at line rate but 'want to play anyway because fuckerryone'
20:38 apeloyee right. Why shouldn't there be "peers" which are only trusted to relay auth'd material from *actual* peers? (as a way to have lots of IPs, as you suggest).
20:39 apeloyee why should I trust a machine at $vps_service?
20:39 asciilifeform apeloyee: it isn't that i can't picture a situation where a simple proxy (eats packets from $ip1, forwards to $ip2, and vice-versa) is useful; but i don't see why to make it part of pest, complicating the protocol and creating multiple types of peering
20:40 asciilifeform need to pierce chinese firewall etc.? run a proxy as described above.
20:41 asciilifeform fwiw asciilifeform fully intends to operate his station at his house, and relay packets in exactly this way through his dc.
20:41 apeloyee OK, can you put these statement (what Pest is NOT designed for, maybe w/o explanations) in the next draft?
20:42 asciilifeform apeloyee: does spec for e.g. tcp , lay out explicitly what it 'is and is not designed for' ?
20:42 asciilifeform imho whether an algo fits your use case, is to be decided by the prospective user.
20:42 apeloyee TCP doesn't give a fuck re security
20:43 apeloyee specs which do, generally DO have such a section
20:44 asciilifeform apeloyee: let's approach from different angle -- describe to me one or more situations where the protocol (as currently detailed in 0xFE + the giblets of 0xFD so far given in the log) would not , by your lights, be usable; such that an alternate variant in fact would work there , and without compromising on the 'holes in the tank' principle.
20:48 asciilifeform ( meanwhile, since perhaps it aint obvious, asciilifeform will explicitly remind readers : pest is arguably an atrocity, in that the Final Solution to the problem it intends to solve, is constant-time-rsa-at-line-rate. and nothing else. but this'd cost 1e9$+ to produce the required iron, and then somehow to get it to erryone who wants to play! so asciilifeform posed the question -- what subset of the desired functional
20:48 asciilifeform ity can be achieved with pc ??? )
20:49 asciilifeform wb bingoboingo
20:52 apeloyee high packet loss, say >70% (i.e. DoS). if you include MACs over plaintext for all (or some subset thereof) your peers, *in addition* to primary one over ciphertext, you can get auth'd packed out, even via an untrusted peer
20:53 apeloyee I understand that' it's complicated, so I propose the following: the message can contain a part "not for IRC display". that part can contain MACs as described, etc. what to do with it is between the sender and intended receiver.
20:54 asciilifeform apeloyee: how would you have the station decide when to start sending these sandwiches to one peer, rather than the usual kind to all ?
20:54 apeloyee perhaps that part will have however many most recent messages fit. etc.
20:55 asciilifeform apeloyee: observe that i did not specify how to send e.g. warez, either. there's nothing in the way of someone who wants to use custom message types.
20:55 asciilifeform asciilifeform is trying to specify a rational bottom layer for whole thing.
20:55 asciilifeform iirc signpost wants to send lubygrams, for instance.
20:56 asciilifeform this aint 'forbidden' somehow. simply imho doesn't belong in the basic protocol.
20:57 apeloyee observe that few messages actually need >400 bytes. so suppose I *always* send the extra MACs. the intended receivers know where theirs are.
20:58 asciilifeform apeloyee: your layered thing is iirc in heathendom called 'onions'. and the mass gets outta hand pretty quickly (and especially with hash-based signatures : i want to send to 10 people, and i can reach 3 relayers, so now i need to generate 30 distinct packets... )
20:58 apeloyee so we got to sigs rather than MACs?
20:59 asciilifeform apeloyee: i'm using the word interchangeably
20:59 asciilifeform hash-based sig / mac
21:00 asciilifeform apeloyee: imho the sandwich/onion approach isn't helpful, because does not somehow solve the problem of 'not having rsa' in the general case -- you cannot communicate authenticably with your l3, only with l1/l2
21:01 apeloyee why? supposing my message fits in 200 bytes, I generate 10 MACs over plaintext of 20 bytes each, then send 3 packets as normal.
21:01 asciilifeform and each layer adds cost in geometric progression; as well as the massive additional complexity of having the layers at all
21:01 apeloyee oops, collision.
21:02 apeloyee l3 in the net sense or in the trust sense?
21:02 asciilifeform net
21:03 apeloyee why not? the plaintext MAC survives any number of hops
21:03 asciilifeform apeloyee: observe that simplicity is a deliberate design goal. concretely, currently there are no 'unions' (in c lang. sense) in pest -- every field has one and strictly one possible meaning.
21:03 asciilifeform there are no lists, no variable-length anything.
21:03 asciilifeform no entities which 'may be text, but may be list of xyz' etc
21:04 asciilifeform strings (text payloads, handles) live in fixed spaces, with unused elements consisting of 0s.
21:04 asciilifeform no variable-length strings.
21:05 asciilifeform this is deliberate. i want ~simple~ protocol (in fact, even the 0xFE item may be too complex, but i currently do not know how to make it less complex while sticking to the 'tank WILL NOT HAVE HOLES in the bottom' dictum)
21:07 apeloyee well, "no variable-length strings" is certainly unusual. and you will continue to be baffled by comments until you state it
21:08 asciilifeform apeloyee: it's designed to be trivially hardwarizable -- this is the 'clef' to the 'roman a clef' if you will.
21:08 apeloyee btw. let's say a station in your L2 is compromised and starts to send mountains of garbage. what now, disconnect all common peers?
21:08 asciilifeform yes.
21:08 asciilifeform there's no magic in our universe.
21:09 asciilifeform what if your upstairs neighbour's pipe bursts ? you'll have water and shit raining on you until fixed.
21:09 apeloyee "upstairs neighbor" is the equiv. of L1.
21:09 asciilifeform and it'll be fixed with hands. there's no magic fixer that will fix it without manual intervention.
21:10 asciilifeform apeloyee: the 1st thing you'd do is to set max-bounces to 1. then talk to the peer who was relaying liquishit.
21:11 asciilifeform apeloyee: btw i considered to have a default rate limit for simple hearsay messages.
21:11 asciilifeform will put in 0xFD.
21:12 asciilifeform it doesn't somehow solve the problem of 'burst pipe' in the general case, but in practice imho will make easier to plug.
21:14 apeloyee l2 compromise shouldn't mean you disconnect your peer (and lose the ability to talk to him). I'll think if your fix is enough.
21:15 asciilifeform apeloyee: it is presumed that you ~always~ can contact any peer out of band (i.e. outside of pest)
21:15 asciilifeform it is required if only for the initial key/ip agreement.
21:15 apeloyee what's the point of direct messages then?
21:15 asciilifeform and if a station is destroyed, it all has to be done again. for each peer.
21:15 asciilifeform apeloyee: functionality equivalent to irc priv msg.
21:15 asciilifeform i.e. realtime chat.
21:16 asciilifeform yes i can write someone a snail mail. or take a plane. but if you have a link established, then don't need to.
21:17 asciilifeform apeloyee: some of the things you mentioned (e.g. messages signed 'for' one peer but also, 'on outside of envelope', 'for' another, to be relayed) are arguably useful. and i thought about them. but they are ~costly~ in complexity. moving parts are a cost, and not counting this cost is why literally every traditional high-level protocol, starting with tcp, is garbage, imho.
21:17 asciilifeform a complex protocol is in practice impossible to implement without catastrophic bugs.
21:18 asciilifeform ( and, to make things worse, impossible for most, even intelligent and dedicated students, to 100% fit in head. )
21:18 asciilifeform fitting-in-head is an explicitly stated design principle in 0xFE already.
21:22 apeloyee so, is Pest intended as a foundation of a more complex thing, or nothing is intended atop it?
21:22 asciilifeform foundation.
21:23 asciilifeform initially simply to replace dulapnet ( we're here because fleanode finally bit it , notice )
21:24 asciilifeform whole idea was born because there , initially , were to be other irc relayes in dulapnet. and then asciilifeform et al finally read through whole rfc , and realized that it is impossible to make a all-to-all irc network.
21:24 apeloyee got to have places where to place new things, then. Those may be unspecified in the initial implementation
21:24 asciilifeform apeloyee: here.
21:24 * asciilifeform thought it was rather clear
21:25 apeloyee emitting several packets rather than one is visible to snoops
21:25 asciilifeform 0xfd has half dozen new commands, btw (rekeys, getdata...)
21:25 asciilifeform apeloyee: there was discussion in the past re link saturation to frustrate snoops. imho not necessary to specify whether or how to do it.
21:25 asciilifeform it isn't appropriate for all users.
21:26 asciilifeform (e.g. gsm modem where you pay per byte, say)
21:29 * asciilifeform has been sawing on 0xFD spec for 2w nao, but sadly not likely to post today...
21:30 asciilifeform apeloyee: thx btw for taking the time to read the article and make comments. and feel free to leave comments in log, asciilifeform promises to answer in detail when able.
21:30 * asciilifeform must bbl
~ 1 hours 39 minutes ~
23:10 thimbronion asciilifeform: Unable to relase the acluin update today after realizing black packet size still incorrect because not using CBC mode. Fortunately upon closer examination of the serpent lib I'm using I see it *does* support CBC mode, so that's good.
23:25 asciilifeform thimbronion: standard cbc alone won't cut it, and i'ma have to fiddle with the spec here, also, to make it workable
23:29 asciilifeform thimbronion: in 0xfd i propose hmac384 for the signature. i.e. 48 bytes for S (vs 64 in 0xFE) ; 448 bytes for ciphertext instead of 444; for a total mass of 496 for black packet (instead of 508 previously)
23:29 asciilifeform 496 == 16 * 28
23:29 asciilifeform and so nomoar problem with ciphertext not being multiple of serpent blocksize.
23:30 asciilifeform err
23:30 asciilifeform 448 == 16 * 28
23:30 asciilifeform lol
23:32 asciilifeform the 4 additional bytes of black packet will be reserved field.
23:41 asciilifeform (or i suppose can make msg longer...)
23:44 * asciilifeform going with the latter, unless someone can formulate a persuasive objection
← 2021-09-18 | 2021-09-20 →