1200+ entries in 0.017s
sina: oh yeah, while we have you alf, can you answer above? why is lighthouse necessary if A can just sign current timestamp and B only accept timestamps within a small variance window?
sina: time for some food and stuffs, I will spend time later trying to implement this
sina: this clarification is much appreciated, I do think I can rework what I've got to fit the above model
sina:
http://trilema.com/2016/gossipd-design-document/ III. Gossipd will receive inbound connectionsvii from identified clientsviii and on the basis of that identification produce an encrypted challenge string, which constitutes its response. If the other party responds with the proper challenge string, the connection is established ; otherwise it is dropped.
sina: because the blogpost has a challenge/response thingo
sina: mircea_popescu: ok that makes sense, you should consider updating the blogpost :P
sina: mircea_popescu: I assume A generated that reference, and it is storing it until B has responded?
sina: "a reference allowing it to respond." << is that not a session concept?
sina: mircea_popescu: while I appreciate the validty of issues about sessions, challenge/response dictates there must be something akin to a session, even if that isn't the most precisely fitting term
sina: unless all responses are identical for all peers, which would make them plaintext
sina: also I can't see how the model can be *completely* stateless, there will always be some kind of minimal session which is "hi, I'm A" followed by a response tailored to A
sina: I'm not sure I understand how you can craft packets in advance if they need to be signed
sina: Framedragger: really appreciate your patience, I get the feeling asciilifeform would be shouting at me again by now
sina: you can't replay timestamps outside of a certain window +/- 0.5s or something?
☟︎ sina: why not just sign the current UTC timestamp
sina: another probably dumb question
sina: oh nevermind, obviously if you sign any random bytes it can be replayed
sina: but why can't A just sign any random bytes? why does it need to come from the lighthouse?
sina: probably a dumb question
sina: if I'm operator of peer A and want to send a message to peer B, what do I do? pick one of my stored challenge strings, sign it, send it along with my message?
sina: and nodes are receiving and storing those challenge strings
sina: so we have a lighthouse thingo broadcasting some random bytes as challenge strings in plaintext
sina: Framedragger: can you bear with me for a few questions or were you going to bbl?
sina: no apologies necessary
sina: well, the next line is literally "This variant is not, incidentally, intrinsically incompatible with Mircea Popescu's - conceivably he might choose to hand out auth challenges to all-comers, while I operate lighthouse; while retaining the other basic mechanics."
sina: "To craft a valid packet, a sender must collect a single auth string from the receiving node's lighthouse (via whatever means, can be a shortwave tuner), craft auth with it as described by Mircea Popescu earlier, encipher to receiver's RSA pubkey, and send." ?
sina: I guess I'll wait for some clarification from mircea_popescu ? challenge/response is a session based concept even ignoring the older post
sina: appreciated Framedragger
sina: this will change my design a little bit
sina: then is there a need for a challenge at all?
sina: asciilifeform: can you clarify, *all* comms? when I was implementing my first pass at encrypting comms yest, I found that at least the very first message when a peer connects as a client would be plaintext, i.e. "hi I'm A", otherwise the "server" would need to enumerate all its keys to find if it knows the peer?
☟︎ sina: asciilifeform: yesterday you mentioned 2 articles, but I had only seen one, if you recall URL can you link second one?
sina: so the answer is "the program should allow for both behaviours"
sina: Framedragger: thanks, exactly what I meant
sina: should the operator be encrypting the message for the final recipient and then publishing that ciphertext?
sina: what I'm asking is, does that behaviour match the intent? OR
sina: in current model, operator can write a message and claim it is from anyone and "publish" it to their own message store. when peers connect, the messages since last seen are delivered, each encrypted with a peer-pair unique RSA key. so as the message "progresses" between peers it gets encrypted, then decrypted and stored in each peers message store in plaintext
☟︎ sina: mircea_popescu: patience appreciated while I attempt to rephrase question.
sina: mircea_popescu: is it intention that there should be encryption from author to recipient as well?
☟︎ sina: but each peer can see the msg plaintext of the messages for now
sina: ok so I implemented some p2p encryption for the gossipd thingo
sina:
http://btcbase.org/log/2017-06-27#1674872 << sorry I used the wrong term there, I meant the operator. what I ended up with re that query is approximately what you've got there, except it's a two step process. 1. gossipc --add-peer --name sina --host <host> --port <port> which furnishes you a pubkey you can exchange with that peer (and they vice versa with you) and a seperate command to set the peer key
☝︎ sina: alrighty, gonna go do some human stuff. have a good week all!
sina: have fun in Managua?
sina: vulnerable to what, exactly, is the question? I am struggling to see how timing can be ascertained from that kind of model, but it's only a thought experiment so I can steal your brain juices
sina: same as above, but each computer houses 1 process respectively, connected over ethernet or whatever
sina: fine, what if we assume two independent computers
☟︎ sina: messages are to be delivered for a given peer or set of peers.
sina: Imagine two independent processes. Process #1 is going through the list of peers and generating encrypted payload for unique peer key since last seen. When the payload is generated it places in outbox. Process #2 is running every N interval (1s example sure) to accept connections and deliver payloads from outbox. If for some reason Process #1 doesn't complete operation in time, it simply appears as if no
sina: I'm not sure I explained correctly. Please let me try one more time.
sina: any actual practical example of making it spill out of the time box? lets say two independent processes, one is preparing the payloads and putting them in an "outbox"
☟︎ sina: can I ask how come no?
sina: asciilifeform: how about this simpler model. Nodes only accept connections at interval N seconds, and during time between intervals it is preparing encrypted payload of all messages since last seen for each peer. so when A connects to B and says "Hi, I'm A", B responds with a pre-prepared payload encrypted for As key
sina: again, I'm not proposing my impl as "hey you should use this!", only wanted to ask you some questions re timing
sina: asciilifeform: don't pop a vein, I absolutely get your point, I was trying to explain (erroneous or otherwise) the path walked
sina: I got that impression from reading gossipd logs, obviously I didn't read everything ever because I only learned about the linespeed thing yesterday
sina: I assumed it was deedbot style OTP thing
sina: and right now my impl does send everything except the challenge in plaintext!
sina: ok fair. see, the spec I was working from it only mentions encryption for the "session establishment" so I assumed that encryption of actual message payloads was to be with out of band encryption
sina: I think we might be speaking at corss purposes and just wish to clarify that point before proceeding
sina: can I clarify something? when you say gossipd are you assuming that all traffic is enciphered?
sina: so no key is ever retained beyond a single "session"
sina: why would there be a long term key? I mean, right now in the impl the process to rotate a key is manual, but if you're using ephemeral key why not just "chain" them in the sense that at the end of the "session" you pass some ciphertext that includes the next ephemeral key, wait for delivery ack and then dump the old key?
sina: sorry, define "station key"?
sina: another thought, in my impl, even if you broke the key, all this nets you is the ability to have messages delivered to you from a single node
sina: vein? e.g. perform 3 parallel decryptions
sina: asciilifeform: if I'm not pestering let me throw a couple of questions. in my impl there are two secret operations, 1. key generation 2. challenge decryption. for #1, it runs in a different process on a random basis and marks a portion of the keys generated as bogus (per linked spec). that seems like it should sufficiently obfuscate against timing? for #2 is it possible to do some bogus ops in a similar
sina: I have been reading the logs, agreed they are handy
sina: ok fair point, I get the general need for constant time constant space algo regardless of gossipd stuff anyway
sina: session may be the wrong term. I just mean, in the spec
http://trilema.com/2016/gossipd-design-document/ "III. Gossipd will receive inbound connectionsvii from identified clientsviii and on the basis of that identification produce an encrypted challenge string, which constitutes its response. If the other party responds with the proper challenge string, the connection is established ; otherwise it is
sina: so my impl doesn't do this currently, but imagine it throws away the key after the session is established, no big deal then
sina: but do they not depend on measuring the timing over many operations?
sina: I am on the general points
sina: well, not even generated, just assigned
sina: asciilifeform: can you elaborate on timing? in my impl each peer-pair has its own set of corresponding RSA keys and I was thinking of adding something like, at the end of each session a new keypair is generated and exchanged on each side
sina: mod6: ah hehe you signed on just before I went to bed last night :P