180100+ entries in 0.84s
Framedragger: situation is different if
the point is for peer A
to newly introduce self
to B.
then (sina) "unpredictable lighthouse" is important because it sets a limit
to how many auth strings can be used.
mircea_popescu: prolly should separate
the re-discussing of
that from
the guy
trying
to comprehend
the spec
mircea_popescu: you know,
the lighthouse idea, while an idea, didn't actually get included.
a111: Logged on 2017-06-28 01:45 Framedragger: sina: fwiw (he can speak for himself but
to save you
time), asciilifeform does not like sessions [ever|anymore], and considers
them ugly beasts which won't have a place in his gossipd bed
mircea_popescu:
http://btcbase.org/log/2017-06-28#1675565 <<
the problem with
the concept of a "session" is
that it attempts
to link machine state
to world state.
this is a very
tenuous proposition, and
the fundamental reason why sessionificatyion of (the correctly designed) stateless
http protocol failed for 30 years straight and will continue
to fail forever.
☝︎☟︎ a111: Logged on 2017-06-28 01:28 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?
a111: Logged on 2017-06-28 01:19 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
Framedragger: sina: right, re future, i didn't make sense
there
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
Framedragger reading how asciilifeform described
the packets, if at all, because forgot
sina: I'm not sure I understand how you can craft packets in advance if
they need
to be signed
Framedragger: i guess he'd say "read
the article [implying read
the comments,
too]"
sina: Framedragger: really appreciate your patience, I get
the feeling asciilifeform would be shouting at me again by now
Framedragger: let me recall why
that is super important lol; but
the unpredictability of
the auth strings coming from lighthouse is important
Framedragger: because you can predict
the future of such a lighthouse, hence craft any number of packets in advance
sina: you can't replay
timestamps outside of a certain window +/- 0.5s or something?
☟︎ sina: why not just sign
the current UTC
timestamp
Framedragger: yeah, so
this avoid replay but also sets a limit
to how much DoS exposure you have (one of
the limits, at least)
Framedragger: i believe
this relates
to asciilifeform's "traditional challenge-response creates DoS vector". so with a lighthouse auth string, one more important point is
that a particular auth string cannot be reused.
Framedragger: (btw
the challenge strings may be in something else
than plaintext, all depends on lighthouse and medium)
sina: but why can't A just sign any random bytes? why does it need
to come from
the lighthouse?
Framedragger: mircea_popescu had concerns re. "signed", but iirc
the concept of "station key" (vs. "mega important owner key") helped
there. not sure if entirely resolved,
tho
Framedragger: A and B may
then decide
to enter some different "state" but
the general gossipd design is stateless, i.e.
there is no session
Framedragger: yes i
think so, and note
that
there is a
time window
there re. how recent challenge string has
to be,
to avoid replay. i.e.,
those strings expire. and yes
that's how you send a msg
to B iirc
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?
Framedragger: so in
that sense it's not your
traditional challenge-response. again, sorry if repeating
Framedragger: ("well ok, let me generate
this one just for you, and
this for just for you", vs. "i'll generate
this many auth strings per
time unit, and distribute
them
to
this set of destinations (or "shit
them out via radio"))
Framedragger: so
there's no way
to DoS peer B with "hi plox
to send me an auth string, i'm
totally legit non sybil node"
Framedragger: the point is
that auth strings are sent regardless of whether
the connecting peer (A) wants
them
Framedragger: "in all directions" depends on medium. in radio, it's clear; in packet switched networks, could be a list of broadcast addresses
to send auth strings
to (constantly), etc
Framedragger: note
the important aspect which lighthouse introduces: constant stream of auth strings, "in all directions"
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."
Framedragger: yeah,
though note
that
the lighthouse may for all intents be node C
there
Framedragger: tl;dr asciilifeform described a way for peer A
to provide a challenge-response
to peer B in a way which would not require any communication from B, hence not creating a DoS vector
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." ?
Framedragger: did you read
the part about lighthouse based challenge,
though?
sina: I guess I'll wait for some clarification from mircea_popescu ? challenge/response is a session based concept even ignoring
the older post
Framedragger: (i know it's a hella lot of comments under
the newer article but iirc his "DoS magnet!!" points are addressed
there)
Framedragger: sina: fwiw (he can speak for himself but
to save you
time), asciilifeform does not like sessions [ever|anymore], and considers
them ugly beasts which won't have a place in his gossipd bed
☟︎ Framedragger: (but
then,
the newer article clearly states "This is an up-to-date draft specification for gossipd", so i'm not
too sure about
that, either)
Framedragger: sina:
to clarify (hopefully lol),
that ^ is for all intents and purposes outdated. asciilifeform did say "original mp algo".
that said, i'll agree if you say "you guys have a documentation problem omg"
Framedragger: afaict gossipd model assumes
that some rsa keys had been exchanged out-of-band.
traditional challenge-response has been constantly critiqued by asciilifeform via "it's a DoS vector" argument (sorry if
too curt, am in bed)
Framedragger: i even raised a (nonsensical) "but-t-t
time complexiti!" concern re
this
Framedragger: in fact
that's a question i asked in comments, sina
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?
☟︎ Framedragger: god it's like quoting
talmud at
this point :D (i mean
the long comments etc)
Framedragger: asciilifeform: sure, but (plz don't vomit from use of keyword)
there should be a way
to onion-rsa
them,
too (A encrypts
to C's key,
then encrypts
to B's key and
tells B
to relay
to C which is currently offline, or w/e)
Framedragger got confused from article,
too (hence not opining re gossipd currently)
Framedragger: in fact i'd imagine
that gossipd should ideally allow for arbitrary end
to end encryption, would be up
to operator?
sina: so
the answer is "the program should allow for both behaviours"
sina: Framedragger:
thanks, exactly what I meant
Framedragger: intermediary peers won't be able
to decrypt message in
the latter model, asciilifeform
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.
a111: Logged on 2017-06-27 23:18 lobbes: "Many folks expect
to have some way of viewing and using emojis" heh
Framedragger: i mean, scriba was supposed
to have an mp emulator chatbot, so i'll keep it in mind :)
mircea_popescu: netflix interprets maersk as damaged and just routes around
teh censor ships!
Framedragger: btw maersk (some related ports) is down due
to new "ransomware" (orange website says it's
the same nsa "eternalblue" windows vuln)
☟︎ Framedragger: calling it: "serious linux desktop RCE discovered related
to emojis" (memory mismanagement or related) (exact words in quote may differ)