Chat logs of #funderscore for Sunday, 2024-06-23

02:06 *** Quits: tester2 (~tester@tester2.tor.gateway.irc.andrewyu.org) (The TLS connection was non-properly terminated.)

02:13 *** Joins: tester2 (~tester@tester2.tor.gateway.irc.andrewyu.org)

04:46 *** Joins: TheLongnoseRob (~rob@p071246.f.east.v6connect.net)

06:30 *** Joins: Livio (~livio@37.163.176.75)

09:57 *** Quits: TheLongnoseRob (~rob@p071246.f.east.v6connect.net) (Quit: leaving)

11:39 <f_> > (335) --  f_ is a bot on rx

11:52 *** Quits: Livio (~livio@37.163.176.75) (Ping timeout: 240 seconds)

13:18 *** Joins: Livio (~livio@37.163.176.75)

14:19 *** runxiyu is now known as unreg-12431

14:20 *** Quits: unreg-12431 (runxiyu@netadmin.irc.runxiyu.org) (Quit: ZNC 1.8.2+deb3.1 - https://znc.in)

14:20 *** Joins: runxiyu_ (runxiyu@netadmin.irc.runxiyu.org)

14:44 *** f_ is now known as BouncerServ

14:44 *** BouncerServ is now known as 101AAAAAB

14:44 *** 101AAAAAB is now known as f_

14:55 *** Quits: hax (hax@netadmin.irc.andrewyu.org) (*.net *.split)

14:55 *** Joins: hax (hax@netadmin.irc.andrewyu.org)

14:55 *** Quits: hax (hax@netadmin.irc.andrewyu.org) (*.net *.split)

14:55 *** Joins: hax (hax@netadmin.irc.andrewyu.org)

15:13 *** *status sets mode: +qo FUN▬▬▬▬▬▬▬▋ FUN▬▬▬▬▬▬▬▋

15:16 *** Quits: hax (hax@netadmin.irc.andrewyu.org) (*.net *.split)

15:16 *** Quits: FUN▬▬▬▬▬▬▬▋ (vdoSoju@services.irc.vitali64.duckdns.org) (*.net *.split)

15:16 *** Quits: DuckServ (\_o<@services.irc.vitali64.duckdns.org) (*.net *.split)

15:16 *** Joins: DuckServ (\_o<@services.irc.vitali64.duckdns.org)

15:16 *** fun.irc.runxiyu.org sets mode: +o DuckServ

15:16 *** Joins: hax (hax@netadmin.irc.andrewyu.org)

15:17 *** Joins: FUN▬▬▬▬▬▬▬▋ (vdoSoju@services.irc.vitali64.duckdns.org)

15:17 *** *status sets mode: +qo FUN▬▬▬▬▬▬▬▋ FUN▬▬▬▬▬▬▬▋

16:06 <f_/tc> tilde.chat is such a fun and cozy network

16:18 <Adeline> rx more fun but less cozy

16:18 <f_> yes

16:19 <f_/h> hackint very fun though

16:19 <f_/h> and full of memes

16:19 <f_/h> you should idle in #hackint at some point :P

16:19 <f_/h> oh wait you do

16:19 <f_/h> well, check messages :P

16:21 <f_/h> People thinking that Hackint is a network for blackhat crackers :P

16:21 <f_/h> Even when the topic literally stated "no blackhat"

16:21 <f_/h> s/stated/states(

16:21 <f_/h> s/stated/states/

16:22 <hax[xor]> what, you think people actually read? :p

16:22 *** Joins: tester3 (~tester@tester3.tor.gateway.irc.andrewyu.org)

16:23 *** Quits: DuckServ (\_o<@services.irc.vitali64.duckdns.org) (Impostor removed.)

16:23 *** Joins: DuckServ (\_o<@services.irc.vitali64.duckdns.org)

16:23 <f_/h> I do I think

16:23 <f_/h> runxiyu: join #archiveteam-* and #dn42 and #37c3 too

16:24 <f_/h> and #freenode

16:24 <f_/h> and #pissnet

16:24 *** Quits: tester2 (~tester@tester2.tor.gateway.irc.andrewyu.org) (Ping timeout: 240 seconds)

16:24 <f_/h> and #replicant

16:24 <f_/h> and #☃

16:24 <f_/h> and #38c3-offtopic

16:24 <Adeline> f_/h: not in hackint on this client

16:25 <f_/h> why do you maintain 4 clients

16:25 <f_/h> I only maintain 2 clients

16:25 <hax[xor]> I only maintain 0 clients

16:26 <f_/h> hax[xor] no you maintain 1-2

16:26 <Adeline> I maintain ircrx.c... not really

16:26 <Adeline> f_/h: maintain = program

16:26 <f_/h> I mean

16:26 <f_/h> Why do you keep 4 clients around

16:26 <Adeline> because "yes"

16:26 <Adeline> ok i should delete andrewyu.org/s soju

16:26 <hax[xor]> I use 1 client, that one I don't poke in any fashion other than general usage, and rarely mess with its configuration too

16:26 <f_/h> I only keep 2 clients around

16:27 <f_/h> Adeline: keep soju, delete everything else :P

16:27 *** f_/h sets mode: -o f_[xmpp]/h

16:28 <hax[xor]> Adeline: maintain also can make sense in the non-program sense, i.e. fiddling with configuration/etc to keep up with demands

16:29 <Adeline> fine

16:30 <hax[xor]> but yeah "I leave this client sitting in tmux, auto-started with the system" I don't count as maintained

16:31 <Adeline> hax[xor]: haxircd protocol should use sctp or udp

16:31 <Adeline> hax[xor]: with dtls or something similar

16:31 <Adeline> hax[xor]: (also sounds like thatd solve some locking issues because message-oriented)

16:32 <Adeline> (thiugh long messages into seperate packets and stuff and whatnot)

16:32 <hax[xor]> Adeline: there's no message-oriented locking issues

16:32 <hax[xor]> Adeline: I already do protocol-specific parsing without locks

16:33 <hax[xor]> dtls I think was a prblem because it'd still require parsing in-order, losing the advantage of udp

16:34 <hax[xor]> if not the case then it's fine

16:35 <Adeline> hax[xor]: Im thinking about just using a simple HMAC

16:35 <hax[xor]> and with udp I'd just ignore it and rely on regular routing protocols overtop to handle resends/etc

16:35 <hax[xor]> `HMAC`?

16:35 <hax[xor]> I've heard that term before but don't remember what it means

16:35 <Adeline> hax[xor]: Like, somehow exchange keys with verification, and just HMAC it with the message (or a hash thereof) as the signature

16:36 <hax[xor]> gotta deal with replay attacs

16:36 <Adeline> simpliest explanation is symmetricKey signature

16:36 <hax[xor]> but I suppose just some counter could do

16:36 <Adeline> counter -> ordered

16:36 <hax[xor]> right

16:36 <Adeline> hmmm

16:37 <hax[xor]> something always-changing-and-verified-not-duplicated without-storing-the-last-n-packets

16:37 <hax[xor]> (not duplicated within reason anyways)

16:37 <Adeline> "within reason"

16:37 <Adeline> :D

16:37 <Adeline> sounds like randomness

16:37 <Adeline> until they collide

16:38 <hax[xor]> well, you need to be able to deal with eventual repeats

16:38 <Adeline> (and until we run out of memory to store used random IDs)

16:38 <hax[xor]> unless you have an unlimited-width-id-field which is totally not a problem

16:38 <hax[xor]> *20 yrs later, we've run out of IDs with <10000 digits, and HaxIRCd runs slower than matrix*

16:39 <hax[xor]> which is funny since matrix would probably still be slower and it'd take far longer than 20 yrs to actually reach that

16:40 <Adeline> lol

16:42 <hax[xor]> Adeline: btw, since closed-network and all

16:42 <hax[xor]> could just leave out the key exchange and have people put the public keys of the other servers in their config

16:43 <Adeline> i dont see a solution for replay attacks

16:43 <Adeline> hax[xor]: hmac is symmetric

16:43 <hax[xor]> could go for an asymetric one then :P

16:43 <Adeline> sure

16:44 <hax[xor]> and yeah replay attacks are going to be annoying to solve

16:44 <Adeline> i smashed a mosquito

16:44 <hax[xor]> well actually

16:44 <hax[xor]> it's totally solvable with random data

16:44 <hax[xor]> if you require confirmations

16:45 <Adeline> i was thinking of the same thing lmao

16:45 <hax[xor]> which would be useful because udp anyways

16:45 <Adeline> waaaiiitt

16:46 <Adeline> a->b: 0x123456 + signed_data

16:46 <Adeline> b->a: 0x123456 ack

16:46 <Adeline> well i dont see how this solves replay yet

16:46 <hax[xor]> you need a third a->b: cont

16:46 <Adeline> but ack'ing certainlly seems to be in my mind

16:46 <Adeline> hax[xor]: explain a bit

16:46 <hax[xor]> which conveniently lines up with my old netsplit handling idea

16:47 <hax[xor]> well a->b 0x123456 cont I mean

16:47 <hax[xor]> b holds on to 0x123456 until a gives it the cont

16:47 <hax[xor]> actually no

16:47 <Adeline> how does wireguard do it...

16:48 <hax[xor]> a->b: 0x123456 + data <all signed&encrypted>

16:48 <hax[xor]> b->a: 0x123456 ack 0x275332 <all signed&encrypted>

16:48 <Adeline> ?

16:48 <hax[xor]> a->b: 0x275332 cont <all signed&encrypted>

16:49 <hax[xor]> at which point b can begin processing of the message

16:49 <Adeline> ah

16:49 <Adeline> double-latency though

16:49 <Adeline> triple*

16:50 <hax[xor]> yes but also no, it's useful for ensuring netsplit rerouting integrity anyways

16:50 <hax[xor]> a->b: here's a message

16:50 <Adeline> "well tcp kinda does that anyways too

16:51 <hax[xor]> b->a: I got the message

16:51 <hax[xor]> a->b: I haven't recieved a netsplit message between now and sending the original, so you can go and propagate it now

16:51 <hax[xor]> b->a is only there to ensure sufficient time has passed for any netsplit b has seen to make it to a

16:51 <Adeline> https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard

16:52 <Adeline> huh

16:52 <hax[xor]> but this is kinda a problem still I suppose

16:52 <Adeline> well what if a netsplit occurs between "a->b: I haven't... it now" and b propagating the message

16:53 <hax[xor]> b will know if a netsplit happened between b->a and it receiving the ack

16:53 <hax[xor]> this plan was done with tcp in mind though, so it does rely on order hmm

16:54 <Adeline> basically a locking problem but your memory is unreliable and everything is very slow

16:54 <hax[xor]> yep

16:55 <hax[xor]> and it falls apart when you add proper mesh networking anyways since c->b netsplit yay a->b hi b->a got it a->b cont c->a netsplit yay

16:56 <hax[xor]> it works for `spanningtree but redundant links that will transparently be activated` though

16:59 <Adeline> yeah

17:00 <Adeline> hax[xor]: does the concept of a connection even need to exist

17:00 <hax[xor]> Adeline: yes, because netsplits (for that specific server) need to exist when a server goes down

17:00 *** Joins: Livio_ (~livio@78.208.179.128)

17:01 <hax[xor]> it doesn't need to be at the tcp layer of connection though ofc

17:01 <Adeline> yeah

17:01 <Adeline> hax[xor]: also, lol at how modern things (part of activitypub and part of matrix) uses "one http request" to send message-oriented messages

17:02 <hax[xor]> lol

17:03 *** Quits: Livio (~livio@37.163.176.75) (Connection closed)

17:06 *** Joins: runxiyu (soju@netadmin.irc.runxiyu.org)

17:07 <runxiyu_> ok

17:07 <runxiyu_> let's see if wireguard does anything smart

17:08 <runxiyu_> Nonce Reuse & Replay Attacks

17:08 <runxiyu_> Nonces are never reused. A 64bit counter is used, and cannot be wound backward. UDP, however, sometimes delivers messages out of order. For that reason we use a sliding window, in which we keep track of the greatest counter received and a window of roughly 2000 prior values, checked after verifying the authentication tag. This avoids replay attacks while ensuring nonces are

17:08 <runxiyu_> never reused and that UDP can maintain out-of-order delivery performance.

17:08 <hax[xor]> > never

17:09 * runxiyu_ is reading https://www.wireguard.com/protocol/

17:09 <hax[xor]> I mean, sure, gl using up 64bits of counter any time in the near future, but still as time goes on network speeds increase and such

17:09 <runxiyu_> hax[xor]: reboot when they're about to be used up

17:09 <runxiyu_> :P

17:10 <hax[xor]> great plan :P

17:10 <runxiyu_> I don't understand the sliding window

17:10 <hax[xor]> it means they have around 2k packets tracked and they must not all be out of order

17:10 <runxiyu_> https://www.wireguard.com/papers/wireguard.pdf

17:11 <runxiyu_> hm

17:11 <hax[xor]> and if it is... well... resend will cover it?

17:11 <runxiyu_> i mean, sounds practical, if there's a resend mechanism

17:11 <hax[xor]> yeah

17:12 * runxiyu_ has no idea what https://noiseprotocol.org/ is

17:12 <runxiyu_> Curve25519 points as pre-shared static keys hmmmm

17:13 <hax[xor]> > zero round-trip encryption

17:13 <hax[xor]> kinda need to be pre-shared to meet that

17:13 <runxiyu_> < 4000 lines of kenrel code

17:13 <runxiyu_> hm

17:13 <hax[xor]> > kernel code

17:13 <runxiyu_> hax[xor]: Yes, wireguard keys are pre-shared

17:13 <runxiyu_> hax[xor]: there are userspace implementations

17:14 <runxiyu_> hax[xor]: but I'm using the linux kernel version

17:14 <hax[xor]> ah

17:14 <runxiyu_> I mean it's layer 3, so yeah

17:16 <runxiyu_> hax[xor]: I mean, we could just not do encryption at all and expect people to run wireguard tunnels :P

17:17 <hax[xor]> runxiyu_: does evosauros support wireguard :P

17:17 <runxiyu_> hax[xor]: If it supports IP, then probably yes

17:18 <runxiyu_> ... well, if BGP would be improved without overthrowing IP completely

17:18 <hax[xor]> true but also meh

17:19 <runxiyu_> hax[xor]: when will you write an Internet Draft for IP multicast :P

17:20 <runxiyu_> hax[xor]: uhhhhh I was listing random channels on hackint and I found https://dn42.dev/ and it turned out to be a VPN

17:20 <runxiyu_> what a coincidence

17:20 <hax[xor]> need to write a draft for HaxIRCd multicast and find its issues first :P

17:20 <runxiyu_> It must have known that I was looking at wireguard

17:20 <hax[xor]> lol

17:20 <runxiyu_> hax[xor]: but that's layers on top of IP already

17:20 <hax[xor]> wireguard must be insecure if it's leaking that :P

17:21 <hax[xor]> yes but the concepts behind it will be similar

17:22 <runxiyu> hax[xor]:

17:22 <runxiyu> https://git.dn42.dev/dn42/registry

17:22 <runxiyu> Can I use Windows to clone and update the registry ?

17:22 <runxiyu> No. The registry includes IPv6 resources but NTFS does not support having a : in filenames.

17:22 <runxiyu> lol

17:22 <hax[xor]> lol

19:37 *** Quits: Livio_ (~livio@78.208.179.128) (Ping timeout: 240 seconds)

20:01 *** Joins: Livio (~livio@78.208.179.128)

22:59 *** Quits: Livio (~livio@78.208.179.128) (Ping timeout: 240 seconds)