02:41 |
thimbronion |
Updated the packet structure for alcuin to match 0xFE - I'll post the relavant code soon in case anyone has the time to check it. |
02:43 |
thimbronion |
*relevant |
02:48 |
signpost |
thimbronion: yeah I'll fire it up. |
02:55 |
* |
signpost welcomes bomolochus, is who he says! |
02:55 |
signpost |
I'll update deedbot when he gets the chance to sign same. |
| |
~ 1 hours 6 minutes ~ |
04:02 |
verisimilitude |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057822 Yes. |
04:02 |
dulapbot |
Logged on 2021-09-12 22:19:17 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057793 << soo yer not only asking to double (triple? ntuple? in general case) the req'd amt of bandwidth taken up, but also asking receiver to burn a buncha cpu cycles finding the correct alignment?! all to avoid using checksums? |
04:03 |
verisimilitude |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057810 I never wrote ``unauthenticated''. |
04:03 |
dulapbot |
Logged on 2021-09-12 22:09:11 asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-12#1057805 << it's no optimization of any kind, if yer storing unauthenticated and undecrypted (i.e. can't see the timestamp yet) enemy can fill you to the ears with replayed material |
| |
~ 8 hours 42 minutes ~ |
12:46 |
PeterL |
verisimilitude: so you are saying to save both the black and red packet after authentication, which doubles the amount of data stored, but will allow quicker discarding of black packets if somebody tries to flood you with replays? |
| |
~ 2 hours 17 minutes ~ |
15:04 |
asciilifeform |
PeterL, verisimilitude : storing a black packet is absolutely pointless (even if you already discovered, by decoding it, that the signature is valid and the timestamp is not stale) |
15:04 |
* |
asciilifeform thought that this was rather obvious |
15:06 |
asciilifeform |
the only time you'll ever see a black packet twice+ is during ddos. and i did specify that yer box gotta be able to handle the full decoding procedure at line rate. |
15:06 |
PeterL |
according to the protocol, you should never see the same black packet twice |
15:06 |
asciilifeform |
PeterL: not from an actual pest station, no. from ddoser -- yes |
15:07 |
asciilifeform |
but adding an extra hashism and bufferism for blacks doesn't help -- enemy can simply throw 5years worth of valid but distinct blacks he collected from your isp instead of simply identical |
| |
↖ |
15:07 |
PeterL |
and if you can actually decode at line rate, trying to ddos by replaying is pointless |
15:07 |
asciilifeform |
and then you'll be burning ~more~ cpu to deal with these, than per my specced scheme. |
15:07 |
asciilifeform |
PeterL: correct. |
15:08 |
asciilifeform |
ergo black packet is thrown out after decoding (or being proclaimed martian). |
15:08 |
* |
asciilifeform will bbr |
15:08 |
PeterL |
so adding a black packet buffer just adds one more check that you don't need |
15:09 |
PeterL |
well, not just one more check, one more check against everything in the buffer |
| |
~ 36 minutes ~ |
15:45 |
asciilifeform |
PeterL: correct |
| |
~ 37 minutes ~ |
16:22 |
mats |
https://www.vice.com/en/article/3aq9p5/expressvpn-uae-hacking-project-raven-daniel-gericke |
| |
~ 1 hours 6 minutes ~ |
17:28 |
asciilifeform |
meanwhile in 0xFE comments. |
17:33 |
asciilifeform |
mats: 'The court filings detailed that prosecutors will drop the charges if the three men cooperate with U.S. authorities, pay a financial penalty, and agree to a list of unspecified restrictions on their employment' << lol, press-gang ?? |
| |
~ 33 minutes ~ |
18:06 |
asciilifeform |
unrelatedly, |
18:08 |
asciilifeform |
... replays become considerably trickier to pull off once we have frequent rekeying. |
18:08 |
dulapbot |
Logged on 2021-09-15 11:07:22 asciilifeform: but adding an extra hashism and bufferism for blacks doesn't help -- enemy can simply throw 5years worth of valid but distinct blacks he collected from your isp instead of simply identical |
18:08 |
dulapbot |
Logged on 2021-09-07 14:34:56 asciilifeform: so handshake goes : 1) X->Y : a' 2) Y->X: b' 3) X->Y: a 4) if a' != H(a), Y->X: fuckyou ; else Y->X: b 5) if b' != H(b), X->Y: fuckyou; else X->Y: hello with new key a^b 6) Y->X: hello to you too with new key a^b . |
18:09 |
asciilifeform |
and unrelatedly to this, is ~is~ possible to maintain a large log and answer 'getdata' for arbitrarily old packets, ~if~ the timestamp check is made ~after~ checksumming of the message. |
18:10 |
asciilifeform |
this'd be a slightly more expensive per-packet prologue -- but allow arbitrarily old timestamps ~strictly~ when they are replies to a getdata which explicitly requested an 'ancient' packet, without adding anything to be gained by a replayer. |
18:12 |
asciilifeform |
(i.e. this is solvable) |
18:12 |
dulapbot |
Logged on 2021-09-12 19:21:26 asciilifeform: thinking again about 'getdata' : this won't work as given. because if timestamp indicates 'stale' (>15min in the past) the answer to the 'getdata' will be tossed. |
18:13 |
asciilifeform |
... and imho oughta be done; the price is small, while the gain (read log to beginning of time! for so long as even 1 peer has it and willing to answer) is substantial. |
18:13 |
* |
asciilifeform invites discussion; will bbl |
| |
~ 27 minutes ~ |
18:40 |
PeterL |
would the getdata only be for things that peer had said, or for any data? IE, would I only be required to hold onto my own history, rather than keeping everything I had ever seen? |
| |
↖ ↖ |
| |
~ 58 minutes ~ |
19:39 |
mats |
asciilifeform: the filings land a day after expressvpn is acquired |
19:39 |
mats |
convenient timing |
| |
~ 44 minutes ~ |
20:24 |
punkman |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058228 << keeping only your history would be weird, if you are gonna limit your log, you'd limit by time, not speaker |
| |
↖ |
20:24 |
dulapbot |
Logged on 2021-09-15 14:40:37 PeterL: would the getdata only be for things that peer had said, or for any data? IE, would I only be required to hold onto my own history, rather than keeping everything I had ever seen? |
20:26 |
punkman |
also if I want to catchup with getdata(selfchain) requests, I'd also need a way to get last selfchain for all speakers |
| |
↖ |
| |
~ 1 hours 13 minutes ~ |
21:39 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058231 << you keep at minimum 30min of log, separately, for a) your net b) direct (priv.) messaging sessions w/ each peer. |
21:39 |
dulapbot |
Logged on 2021-09-15 16:24:02 punkman: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058228 << keeping only your history would be weird, if you are gonna limit your log, you'd limit by time, not speaker |
21:39 |
asciilifeform |
(a) can getdata on (a), (b) can getdata on (his particular) (b), strictly. |
21:40 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058233 << mno. you getdata on the self/net chain of your last packet received (in the case of (a) -- from anyone on your net; in the case of (b) -- from the peer in question.) |
21:40 |
dulapbot |
Logged on 2021-09-15 16:26:05 punkman: also if I want to catchup with getdata(selfchain) requests, I'd also need a way to get last selfchain for all speakers |
21:41 |
asciilifeform |
http://logs.nosuchlabs.com/log/asciilifeform/2021-09-15#1058228 << stations oughta answer getdatas on a 'cycles available' basis. in principle very little will be lost if ~no one~ answers'em, you will simply have a very small amount of outright lossiness. and very little ability to follow unbroken chains if your/peer's uptime aint 100%. |
21:41 |
dulapbot |
Logged on 2021-09-15 14:40:37 PeterL: would the getdata only be for things that peer had said, or for any data? IE, would I only be required to hold onto my own history, rather than keeping everything I had ever seen? |
21:42 |
asciilifeform |
it is largely on account of the latter that, imho, getdata is justified. |
21:42 |
asciilifeform |
( and not on account of packet loss, which happens just about never on a working (i.e. rats not chewed on cable on either end) link. ) |
21:43 |
asciilifeform |
in other words, virtually 100% of packet loss happens because the would-be recipient box is actually unplugged. |
21:43 |
asciilifeform |
(or in some cases the ~sender~ is..) |
| |
~ 22 minutes ~ |
22:05 |
punkman |
asciilifeform: if first message of speaker has selfchain=0, how do we request getdata for it |
22:08 |
punkman |
hmm never mind, got it |
22:15 |
punkman |
re: packet loss https://www.openmymind.net/How-Unreliable-Is-UDP/ |
| |
~ 28 minutes ~ |
22:44 |
asciilifeform |
punkman: you don't |
22:44 |
asciilifeform |
aha. |
22:45 |
asciilifeform |
punkman: we did a similar udp trial in the #t days, found iirc 0 loss (can't seem to dig out the log ptr tho. if anyone recalls, plox to write in) |
| |
↖ |
22:46 |
asciilifeform |
punkman: was a test of this asciilifeform item. (where conveniently example proggies for echo) |
22:47 |
asciilifeform |
iirc diana & co. took and made a more elaborate setup with permutations & ordering test etc |