Show Idle (>14 d.) Chans
← 2021-09-18 | 2021-09-20 → ↓
scoopbot: New post on Blog of Peter Lambert: A funny thing about Python
shinohai: $vwap
busybot: The 24-Hour VWAP for BTC is $ 47625.80 USD
user: how's most senile republic of bitcoin going?
user: OK, I'll leave a few stupid comments about Pest spec.
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.
dpb: user, check out http://atruechurch.info/ and don't go to hell like the rest of the world!
user: dpb, you should just stand up a bot to spam that
user: I assume HMAX is chosen because polynomial MAC is too must a footgun?
user: *too much
asciilifeform: user: do we know one another? ( your intro suggests that you were lurking in the era of mp ? )
apeloyee: I still have my GPG key, though probably didn't protect it anywhere as well as you
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.
apeloyee: you can stuff MACs over plaintext for all your phriendz you don't have a direct connection to
asciilifeform: you still need 1 per peering
asciilifeform: and if you have a shared key with someone, and can use a mac, that person is a peer of yours
apeloyee: true, but you probably don't have very many of them.
asciilifeform: conversely, if someone is no peer of yours, you have no shared key with which to mac with him
apeloyee: If you had, the chaneel probably would be unbearably spammy for you
asciilifeform: how is this different from traditional chatisms (e.g. irc) ?
apeloyee: I'm talking about peer you don't have direct connection to
apeloyee: that is, you have a shared secret
asciilifeform: if he's your peer, you have a direct connection definitionally. and vice-versa.
asciilifeform: what does apeloyee suppose is the meaning of 'peer, but no direct connection' ?
asciilifeform: the spec permits no such thing.
apeloyee: suppose the wreckers interfering with you connection
apeloyee: so you can directly reach A but not B
apeloyee: after all, if everyone can reach everyone, what's the point of even having a relay mechanism?
asciilifeform: apeloyee: the point is in fact largely so that a net (connection graph that is not necessarily a clique) can form
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.
dulapbot: Logged on 2021-09-13 22:03:26 asciilifeform: thinking further re the algo -- can be simplified as follows :
asciilifeform: ( ^ proposed 0xFD algo for in-wot hearsay marking )
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
asciilifeform: the human-readable text, that is, rather than anything intended for machine to interpret
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?
asciilifeform: apeloyee: this is idiotic sophistry and beneath contempt.
asciilifeform: i will not dignify it with a reply.
apeloyee: Blocking huge ranges of IP addresses is S.O.P. here. And your protocol requires me to trust the peers then.
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.
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)
punkman: apeloyee: simple file transfer would be more like direct message to single peer
asciilifeform: apeloyee: file transfers strictly with direct messages
punkman: and if you want to share with everyone, can just make torrent, perhaps with some mechanization
asciilifeform: ( why on earth would attempt to do otherwise ? the kind of things folx ask about, sometimes boggles my mind... )
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-19#1058630 << what would a protocol that ~does not~ 'require trusting the peers' look like ?
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.
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
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.
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.
apeloyee: or elliptic curve. Bitcoin
apeloyee: works, after all
apeloyee: where's RSAcoin?
asciilifeform: there shall be no slow crypto with valuable longterm key in pest.
apeloyee: is ECC a bigger "ugh" than serpent?
asciilifeform: let's start with the fact that there is no constant-time ecc in ada and probably won't be in my lifetime.
asciilifeform: and if somehow existed, would not run on standard pc at e.g. Gb/s line rate with 1 sig per packet.
asciilifeform: similar problem to rsa.
apeloyee: I think your mind will be less boggled if you state your assumptions in the spec. (not poor, etc.)
apeloyee: you don't bother to verify unless in message MAC'd by peer.
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
apeloyee: if he relays invalid sigs repeatedly, drop him.
apeloyee: or stop verifying the sigs of $loathesome_fuck_you_don't_care_about
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.
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
asciilifeform: and i aint interested in touching any other kind.
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?
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.
asciilifeform: punkman: valid == passed all validation steps, incl. dupeism
asciilifeform: ALL of them.
asciilifeform: punkman: probably oughta lay it out pedantically so no possible ambiguity on the subj, i agree.
apeloyee: going back, to fix the holes, it's needed to know what kind of attacks you consider and which "don't be poor"
asciilifeform: apeloyee: let's expand on this, imho is a good q
apeloyee: who should expand, me or you?
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.
apeloyee: that I agree with
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
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.
apeloyee: but re: poor connection, your response is "don't be poor", right?
asciilifeform: it is the people who allow allcomers to tie up cpu with trivial effort, who oughta be made to explain themselves.
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.
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
asciilifeform: 'don't be poor' is arguably a misleading phrase ( stole it from mp & co. ) -- better statement would be 'don't be a miser'
asciilifeform: misers, as the proverb goes, pay twice.
punkman: "don't be poor" is excellent heuristic, I use all the time with friends
punkman: as in: stop putting so much effort into making "being poor" work, put more effort into "not being poor"
asciilifeform: punkman: sometimes misunderstood (esp. by folx bent on misunderstanding) -- 'haha, you can't afford a death star, you're poor too'
apeloyee: as someone said, "if you don't have 1G$, fuck off"(c)
asciilifeform: apeloyee: btw if you missed, 'someone' is feeding the fish now in the ocean, 1e9$ didn't help, lol
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.
apeloyee: my quotee is arrested, IIRC
asciilifeform: ah then not familiar
apeloyee: one Sergey Polnskiy. but that's off topic.
apeloyee: *Polonskiy
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?
asciilifeform: aa the d00d who was rejected from space tourism for being fat
asciilifeform: apeloyee: in 0xFD rev. there is 'getdata', which addresses loss
punkman: asciilifeform: do datacenter-to-datacenter routing paths actually drop packets bigger than ~530 bytes?
asciilifeform: (you get packet with 'selfchain' which doesn't correspond to the predecessor -- you issue getdata to the peer)
asciilifeform: punkman: they do not. the problem with jumpopackets is that the frags are accepted 'on faith'
asciilifeform: i.e. if you accept jumbograms, you're quite ddosable
punkman: jumbograms are 65kb
punkman: iirc
asciilifeform: punkman: i'm abusing the terminology, factually. referring to anything that may be fragged.
punkman: so if you put "no-frag" flag on 1kb datagram, they will frag anyway or drop?
asciilifeform: apeloyee: 0xFD pest will operate under any packet loss condition other than 100%
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.
asciilifeform: but only <=508byte guaranteed not to frag.
asciilifeform: (^ mass not incl. headers )
punkman: why do we care about fragged packets though? we aren't gonna process frags in application side
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.
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?
asciilifeform: punkman: BECAUSE THEY AINT SIGNED
asciilifeform: a frag isn't verifiable !!
asciilifeform: it has to be 'taken on faith' until the other N-1 frags are in hand, and ~then~ you can maybe verify it.
asciilifeform: until then it could be whatever.
punkman: I mean this happens in network layer, not in application
asciilifeform: and nothing stops allcomers from bombarding you with bogofrags and filling your buffers with liquishit.
punkman: how does it make it easier to ddos me?
asciilifeform: punkman: what's it matter ~where~ it happens? there's a finite buffer. which unauthenticated fuckwads can pump fulla shit.
asciilifeform: punkman: do you understand what a packet frag is ? and how they are reassembled into original ?
apeloyee: I meant that not-trusted *direct* peers are routinely used to relay stuff. the internet works that way, in fact. but not Pest.
punkman: but they can do this anyway, unless I tell network side to disallow frags or something
asciilifeform: punkman: naturally you config your network stack to immediately discard anything marked a frag.
punkman: perhaps I'm missing something
apeloyee: non-trusted would be useful strictly as proxies. in Pest, stuff they relay cannot be verified.
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.
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.
apeloyee: asciilifeform: what this has to do w/my question?
asciilifeform: apeloyee: where's the question ?
asciilifeform: ( maybe this thread will answer , incidentally ? )
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'
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).
apeloyee: why should I trust a machine at $vps_service?
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
asciilifeform: need to pierce chinese firewall etc.? run a proxy as described above.
asciilifeform: fwiw asciilifeform fully intends to operate his station at his house, and relay packets in exactly this way through his dc.
apeloyee: OK, can you put these statement (what Pest is NOT designed for, maybe w/o explanations) in the next draft?
asciilifeform: apeloyee: does spec for e.g. tcp , lay out explicitly what it 'is and is not designed for' ?
asciilifeform: imho whether an algo fits your use case, is to be decided by the prospective user.
apeloyee: TCP doesn't give a fuck re security
apeloyee: specs which do, generally DO have such a section
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.
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
asciilifeform: ity can be achieved with pc ??? )
asciilifeform: wb bingoboingo
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
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.
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 ?
apeloyee: perhaps that part will have however many most recent messages fit. etc.
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.
asciilifeform: asciilifeform is trying to specify a rational bottom layer for whole thing.
asciilifeform: iirc signpost wants to send lubygrams, for instance.
asciilifeform: this aint 'forbidden' somehow. simply imho doesn't belong in the basic protocol.
apeloyee: observe that few messages actually need >400 bytes. so suppose I *always* send the extra MACs. the intended receivers know where theirs are.
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... )
apeloyee: so we got to sigs rather than MACs?
asciilifeform: apeloyee: i'm using the word interchangeably
asciilifeform: hash-based sig / mac
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
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.
asciilifeform: and each layer adds cost in geometric progression; as well as the massive additional complexity of having the layers at all
apeloyee: oops, collision.
apeloyee: l3 in the net sense or in the trust sense?
apeloyee: why not? the plaintext MAC survives any number of hops
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.
asciilifeform: there are no lists, no variable-length anything.
asciilifeform: no entities which 'may be text, but may be list of xyz' etc
asciilifeform: strings (text payloads, handles) live in fixed spaces, with unused elements consisting of 0s.
asciilifeform: no variable-length strings.
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)
apeloyee: well, "no variable-length strings" is certainly unusual. and you will continue to be baffled by comments until you state it
asciilifeform: apeloyee: it's designed to be trivially hardwarizable -- this is the 'clef' to the 'roman a clef' if you will.
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?
asciilifeform: there's no magic in our universe.
asciilifeform: what if your upstairs neighbour's pipe bursts ? you'll have water and shit raining on you until fixed.
apeloyee: "upstairs neighbor" is the equiv. of L1.
asciilifeform: and it'll be fixed with hands. there's no magic fixer that will fix it without manual intervention.
asciilifeform: apeloyee: the 1st thing you'd do is to set max-bounces to 1. then talk to the peer who was relaying liquishit.
asciilifeform: apeloyee: btw i considered to have a default rate limit for simple hearsay messages.
asciilifeform: will put in 0xFD.
asciilifeform: it doesn't somehow solve the problem of 'burst pipe' in the general case, but in practice imho will make easier to plug.
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.
asciilifeform: apeloyee: it is presumed that you ~always~ can contact any peer out of band (i.e. outside of pest)
asciilifeform: it is required if only for the initial key/ip agreement.
apeloyee: what's the point of direct messages then?
asciilifeform: and if a station is destroyed, it all has to be done again. for each peer.
asciilifeform: apeloyee: functionality equivalent to irc priv msg.
asciilifeform: i.e. realtime chat.
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.
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.
asciilifeform: a complex protocol is in practice impossible to implement without catastrophic bugs.
asciilifeform: ( and, to make things worse, impossible for most, even intelligent and dedicated students, to 100% fit in head. )
asciilifeform: fitting-in-head is an explicitly stated design principle in 0xFE already.
apeloyee: so, is Pest intended as a foundation of a more complex thing, or nothing is intended atop it?
asciilifeform: foundation.
asciilifeform: initially simply to replace dulapnet ( we're here because fleanode finally bit it , notice )
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.
apeloyee: got to have places where to place new things, then. Those may be unspecified in the initial implementation
asciilifeform: apeloyee: here.
asciilifeform thought it was rather clear
apeloyee: emitting several packets rather than one is visible to snoops
asciilifeform: 0xfd has half dozen new commands, btw (rekeys, getdata...)
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.
asciilifeform: it isn't appropriate for all users.
asciilifeform: (e.g. gsm modem where you pay per byte, say)
asciilifeform has been sawing on 0xFD spec for 2w nao, but sadly not likely to post today...
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.
asciilifeform must bbl
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.
asciilifeform: thimbronion: standard cbc alone won't cut it, and i'ma have to fiddle with the spec here, also, to make it workable
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)
asciilifeform: 496 == 16 * 28
asciilifeform: and so nomoar problem with ciphertext not being multiple of serpent blocksize.
asciilifeform: 448 == 16 * 28
asciilifeform: the 4 additional bytes of black packet will be reserved field.
asciilifeform: (or i suppose can make msg longer...)
asciilifeform going with the latter, unless someone can formulate a persuasive objection
asciilifeform: meanwhile, asciilifeform set up a running copy of the current rough draft of pest spec. currently reflects a very partially-done 0xFD. will be kept reasonably current on best-effort basis. please do NOT rely on the item at this link being static, or even consistent !!
asciilifeform: will be updated at unpredictable intervals with potentially arbitrarily-inconsistent text!
asciilifeform: and at times may disappear entirely. you've been warned!
asciilifeform: updated/added material includes 'for the enemy, nothing' ; command table;
asciilifeform: and of course the red/black/message masses, updated re earlier thrd.
← 2021-09-18 | 2021-09-20 → ↑
Random(asciilifeform) | Download hourly DB snapshot | Get Source Code