1300+ entries in 0.021s
sina: hows all today, is it time to rotate shift mod6?
sina: (and it was so far!)
sina: I honestly didn't make it because I thought it would solve any problem, but only because I saw the spec and happen to be on holidays from work this week, thought it would be a good fun
sina: hope you have a nice day
sina: I was just about to sign off for the night :)
sina: erlehmann: I do hope to be able to code a naughty host counter up, still thinking about that
sina: I was just happy to get the OTP working for today and will continue to increment it
sina: erlehmann: yup. if you look through the code you see I do validate inputs as they come in on the socket for example, but I noticed while I was developing that there are some more subtle edge cases and that's what I was referring to
sina: erlehmann: nope hehe
sina: problem. Read this advisory for instructions about an Intel-provided
sina: Disable hyper-threading immediately in BIOS/UEFI to work around the
sina: situations, dangerously misbehave when hyper-threading is enabled.
☟︎ sina: TL;DR: unfixed Skylake and Kaby Lake processors could, in some
sina: tmsr trigger warnings: it uses sqlite, TCP, OOP but I tried to make it modular enough that those things could easily be changed. It isn't the lighthouse or linespeed thing asciilifeform has mentioned, I just tried to follow the spec on trilema.com
sina: pytomcrypt is the only external dependency
sina: it's still a little rough around the edges so you can break it pretty easily if you disconnect during a session or send bad data or whatever like that.
☟︎ sina: alright. the gossipd thingo is 0.0.1 implemented. peers can communicate, each session (fetch messages) is mediated by deedbot style OTP with per peer-pair RSA keys (no GPG shell asciilifeform, using libtomcrypt). I wrote a tiny client to add peers, exchange keys, broadcast msgs and view stored msgs. there is a README.
sina: ben_vulpes: I'm not smart enough to make what's described there, just implementing the spec I saw for amusement
sina: ben_vulpes: that is quite different from the spec :P
sina: it's almost as if being a homosexual has nothing to do with your political orientation :P
sina: TL;DR, Russian gay activist who triggered crackdown/kidnap/murder on gay people in Chechnya (aside from a bunch of other stupid shit) is also very anti-semite
sina: that seems less hacky typing it out
sina: or should it be a three-phase thing where 1. each peer advertises their name/host/port to the other 2. each receives the others pubkey 3. adds it to the peer info
sina: any thoughts? does that even make sense? basically it's caused because I am trying to use a different pubkey per peer, if there was just 1 pubkey it would be a standard out of band RSA pubkey exchange
sina: which seems a bit hacky.
sina: but this presents a chicken/egg problem, where the peer "initiating" the addition will need to then advertise that key to the other peer and wait for a key back, and then initiate an update to the peer data to add in the advertised pubkey
☟︎ sina: I am trying to program the following behaviour, a user can run "gossipc --add-peer --host 1.1.1.1 --port 5000 --name sina" and gossipc will select one of the available (not bogus) RSA keys generated by the ongoing key generation process and say something like "peer added. advertise/exchange the following pubkey to that peer:"
sina: suggestions on the following key exchange conundrum:
sina: oh right its from instructables
sina: that is some dumb shit BingoBoingo but I am pretty sure it's just someone trolling, because I think I have seen that pic before
sina: gonna head out for dinner and hopefully start adding in pieces of the crypto on my return
sina: took me a fair bit of debugging but I got the gossipd thing going so it sends and receives messages. peer addition and message addition are manual commands atm, but it does work :D github.com/sinner-/gossipd
sina: finally, you got the breaking power you truly need!
sina: BingoBoingo: did you hurt yourself
sina: you might roll the key you're using to talk to a particular peer, or want to update its last seen status
sina: so really the list of identities needs to be mutable?
sina: it also states later that clients should keep track of last seen info
sina: but per the next specification sentence, the client will be generating keys constantly and potentially assigning them to use when connecting to a peer
sina: I. Gossipd will have access to a read-onlyii databaseiii of identitiesiv known to it.
sina: was kind of hoping mp would be around as I have a few gossipd questions
sina: not bad just got home from eating some breakfast dumplings
sina: although tbh I don't fully understand the purpose because if someone is watching the wire, they will see the session never gets fully established
sina: "Unsolicited challenge strings will also be sent, at intervals and to destinations specified by the operator."
sina: just going through those comments again trinque, e.g.
http://trilema.com/2016/gossipd-design-document/#comment-119015 "One possible cut of the Gordian Knot re: my "enemy's ability to trigger a response from a suspected-node on demand" would be for every node to have a "lighthouse" - an always-on broadcaster of authentication challenge strings." per the spec I will be implementing this
sina: my impl is more "hey, here is a spec I can implement for some funtimes" than "hey, here is a useful thing"
sina: trinque: my problem is I don't have an original bone in my body, so short of a well described (enough) spec I have a lot of trouble
sina: ah yeah I do remember reading the lighthouse comments
sina: going to get some food and chill out for a bit, any feedback would be appreciated
sina: trinque: is there anything from the thread you think was agreed that materially modifies the spec in post? I figured mp would have updated if so
sina: I'm working on the spec per the blog post, the thread had a lot of stuff on which there wasn't a consensus yet
sina: I need to complete the client part for that so I can flesh out the key handling
sina: anyway I am hoping to have a decent complete implementation done by tomorrow-ish
sina: shinohai: I was definitely thinking about it. there is a lot to be said for the strong typing and forced error checking which makes the program more robust
sina: its not finished yet, but I just completed the "server" portion of the daemon the next piece is to start on the "client" that connects to peers, generates RSA keys, sends bogus challenges
sina: been working on it all week really
sina: mod6: heya, not too bad, working on a gossipd impl!
sina: I'm off gentlemen, have a fabulous week
sina: what a first link to click after exiting the shower
sina: nothing further to report
sina: I looked again through asciilifeform bignum lib in Ada
sina: alright, it's been a pleasure, going to get some sushi
sina: tell us the story asciilifeform