71600+ entries in 0.046s
mircea_popescu: in other very sads,
the new p.bvulpes machine is VERY fucking slow.
mircea_popescu: ok, so
this back of a digital envelope seems
to suggest we want : 1. fixed size 1470 byte rsa packets, made
to work with 3920-bit rsa (of which i presume
the useful message size
to be 1872 bit, diana_coman plox
to confirm maffs ?). such a packet has
then 1696 bits spare for e and bullshit.
☟︎ mircea_popescu: the
thing is -- new accounts handled "as resources permit" anyway, so...
Mocky: ok but if size matches still have
to attempt decryption even if contains garbage?
a111: Logged on 2018-10-02 15:50 mircea_popescu: anyway, i have no intention
to deal with udp flood at gameserver level.
mircea_popescu: diana_coman 2944 bit rsa keys, meaning 1384 bit usable message space in
the rsa packet ? with oaep and everything ?
Mocky: 1472 is what i've used in
the past
mircea_popescu: alright
then, ima put 1472 bytes helo packet ; meaning 2944 bit rsa keys.
mircea_popescu: am i absurd in wanting
to start from 1499 rather
than 1500 ?
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.)
mircea_popescu: let's calculate
this precisely. so what size is my actual payload here, 1468 reliably ?
mircea_popescu: i'm going
to re-write
the rewrite of comms protocol with
this new paradigm.
diana_coman: yes; anyway it's basically a knob
to
turn, not a big issue in itself
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).
mircea_popescu: im not sure anyone'd want
to use his main key for
this anyway
diana_coman: from a practical point of view it does mean
that Eulora doesn't use directly
TMSR RSA keys
though
Mocky: well including udp header, like 1470
to 1480 of payload available
mircea_popescu: suppose i make
the rsa packet 1498 bytes.
this
then means 2996 bit rsa. problem ?
mircea_popescu: of course... if we used smaller rsa keys we could fit in
the mtu...
Mocky: I'd expect frag and auto reassemble
to work well in low volume conditions
mircea_popescu: anyway, i have no intention
to deal with udp flood at gameserver level.
☟︎ mircea_popescu: asciilifeform so interface silently and
timely reassembled 50kb packet out of 30 fragments ?
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?
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
mircea_popescu: diana_coman well, possibly. iirc we didn't specifically check for
that.
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.
diana_coman: mircea_popescu, uhm,
they made it
through - presumably fragged
though?
diana_coman: but honestly I don't see
that
to be such a huge problem
diana_coman: he is
talking of
the new rsa packets
that are biggest
Mocky: e.g. attacker floods with packet frags prevents legitimate frags from ever being reassembled, instead silently dropped, server is none
the wiser
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?
mircea_popescu: there's more, somewhere i say "meanwhile people figured out
the complexity's not worth
the saving" and etc. recurrent
topic.
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.
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.
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.
a111: Logged on 2018-10-02 14:53 asciilifeform:
this is
that 'bit-packing variables'
thing all over again.
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."
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
☝︎ 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
mircea_popescu: i can't have as many interfaces as packet
types for crying out loud.
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
mircea_popescu: server as it stands now doesn't
talk
to any new people, hence
the "talk
to mp"
thing in client.
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...
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.
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.
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.
mircea_popescu: i am not so interested in holding on
to chunks of future.
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."
☟︎ mircea_popescu: my problem is
that i can't ~not~ have 2 sizes of udp packets.
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.
mircea_popescu: meanwhile if every single 13 byte posupdate
takes 16kb...
that's insanity.
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
mircea_popescu: doesn't
take so much work
to ask me
to hold 16gb of chunks.
mircea_popescu: asciilifeform nevermind
that.
to re-asm you gotta keep chunks.
mircea_popescu: now, if it also has 1 single size,
that means
the size of all packets is 16kb