tmsr - Search: a

61100+ entries in 0.463s

asciilifeform: s is a hedge fund d00d.

asciilifeform: 'On June 22, 2017, CNN.com published a story connecting Anthony Scaramucci with investigations into the Russian Direct Investment Fund. That story did not meet CNN's editorial standards and has been retracted. Links to the story have been disabled. CNN apologizes to Mr. Scaramucci.'

sina: thanks to clarification from mircea_popescu Framedragger and asciilifeform I have refactored for statelessness, which led to a significant amount of unnecessary code being deleted! ☟︎

jhvh1: BingoBoingo: Error: 'birds' is not a valid currency code.

jhvh1: BingoBoingo: (ticker [--bid|--ask|--last|--high|--low|--avg|--vol] [--currency XXX] [--market <market>|all]) -- Return pretty-printed ticker. Default market is Bitfinex. If one of the result options is given, returns only that numeric result (useful for nesting in calculations). If '--currency XXX' option is given, returns ticker for that three-letter currency code. It is up to you to make sure the code is a valid (1 more message)

PeterL: from old thread: http://btcbase.org/log/2017-04-11#1641818 << where I work, we do stuff in excel, and every spreadsheet gets printed along with a copy of the formula view and these go together through a data audit ☝︎

a111: Logged on 2017-06-28 03:14 sina: "If you sign malware with a fake self-signed Microsoft certificate, several major AV's on VirusTotal will ignore it"

mircea_popescu: got a whole bbq terrace thing by teh pool.

mircea_popescu: i do make a fire now and again.

mircea_popescu: sounds liek a chiuldhood dream

sina: ha that is interesting, but the ikea thing is just a $5 polished metal bowl that has been setting stuff in peoples houses on fire

sina: "If you sign malware with a fake self-signed Microsoft certificate, several major AV's on VirusTotal will ignore it" ☟︎

mircea_popescu: i don't want to grind myself by the measure of some 9.60 an hour mexicans in a kitchen somewhere.

sina: mircea_popescu: my perspective is that I am just trying to implement what appears to be an interesting spec. for the reason of being interested in implementing that spec. so when I ask for tmsrthing clarification, it is just in terms of spec, not in terms of "making a thing" ...if that makes sense

asciilifeform: with proviso that if he lives for a week, he gets reprieved

sina: I mean I *can* go off and do my own thing, but then I am making a sinathing not a tmsrthing

asciilifeform: there was an old sf tale, maybe 1940s, about a d00d in the Evil Future who is sentenced to death , but 'in house arrest', is put in a seemingly normal flat where common household objects are boobytrapped

mircea_popescu: it can work, depending, but it doesn't work by itself, it has to be a very strictly examioned thing.

mircea_popescu: as a matter of habit.

mircea_popescu: this is the root of the divergence so far, so not a bad reference. encountering a problem, sina tends to seek the "correct" dependency to bake in.

sina: the weather is shit so I am just going to order a pizza and sit in the dark

a111: Logged on 2017-06-28 02:04 sina: you can't replay timestamps outside of a certain window +/- 0.5s or something?

asciilifeform: it can be as expensive ( broadcast to galaxy! ) or cheap ( request a turd in web form, which actually reduces to approx. mircea_popescu's original..! ) as desired.

asciilifeform: this btw is also a major feature of mircea_popescu's (non-lighthousetronic) algo, and imho important

asciilifeform: ('come back with the plaintext' of course means that you, e.g,, gimme a hash H(R + salt), or the like, not literally exposing it for world!)

Framedragger: sina: point was to prove continued identity of A, continued ownership of A's private key, so to speak.

asciilifeform: but asciilifeform is happy to give a hand.

Framedragger: asciilifeform: ah, damn. is the point to prove to B that A holds A's key at time t? i feel dumb

asciilifeform: sina: to get a window to speak to me, you come back with the plaintext of a recent R. proving that you are one of p1,...pN.

sina: anyway, I guess this is a seperate question for smarter people, I will just stick to trying to update my thingo to match mircea_popescu description above

Framedragger: if incoming message is *not signed*, then i understand - it sets a fixed horizon in terms of how much you can spam.

Framedragger: and if the main work is in checking signature, how does a "could not have practically come into existence before you broadcast S" help with regards to DoS?

asciilifeform: ntp requires a hitler.

sina: tmsr is a weird place

asciilifeform: i.e. a signed(S) could not have practically come into existence before you broadcast S, if the latter is a long rng turd

sina: you can prevent replay by signing a timestamp and accepting only "current" timestamp within a window of +/- 0.X seconds?

Framedragger: i assumed that packets were signed by A

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?

mircea_popescu: there's a difference between my client showing alf as "online" and my client being built on the concept of sessions.

mircea_popescu: the idea was to report to the operator, "We have link with x". but conceptually, sessions as a fundamental building block of comms, are not used.

sina: because the blogpost has a challenge/response thingo

sina: mircea_popescu: I assume A generated that reference, and it is storing it until B has responded?

mircea_popescu: sina i imagine it's a keyid of some kind. that makes a session ?

sina: "a reference allowing it to respond." << is that not a session concept?

asciilifeform: and it was different from asciilifeform's, and did not include 'lighthouses', luby transform, a few elses

mircea_popescu: sina so where's a session in there ?

mircea_popescu: if the operator of B opts to relay, at t5 various nodes will receive a P.?j

asciilifeform: Framedragger: recall, mircea_popescu and asciilifeform never came to a 'hey we have this 1 algo', so all q re 'gossipd' presume, imho, mircea_popescu's algo, which was actually called so

mircea_popescu: if the operator of B opts to respond, at t4 A will receive a P'.Ai

mircea_popescu: at t3, providing B has opted to decrypt P.B1, it is in possession of P. if P is a standard message, it contains a reference allowing it to respond.

mircea_popescu: at t2, B is free to decrypt or not decrypt P.B1. it is supposed to make this decision on the basis of B1 and whatever other data it uses to make such a decision.

mircea_popescu: at t1, A remits P.B1 to B.

mircea_popescu: at t0, A encrypts plaintext P to key B1.

mircea_popescu: a

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

Framedragger: mircea_popescu: yeah lighthouse discussion does complicate matters, the fact of the matter is, it's the only current (written) alternative to DoS-prone traditional challenge-response (A asks B to plz send challenge, A then response to B with that challenge), within gossipd universe

mircea_popescu: there's no peer discovery as a gossipd function ; at all times it knows already all the peers it will ever know. in lawyer speak this is called "never ask a question you don't know the answer to." ☟︎

mircea_popescu: the only way for A and B to be introduced, outside of the grandfatherly, A fucks B and they exchange bits of paper, is C tells A about B and B about A. ☟︎

Framedragger: (in fact maybe that's an important point as well: lighthouse shits at a fixed rate; there is a discrete amount of auth strings which can be used. i guess this is obvious, i'm slow)

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.

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

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: 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? ☟︎

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.

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

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: 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: 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: 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." ?

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: 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"

sina: asciilifeform: yest you said no sessions in gossipd, yet http://trilema.com/2015/artifexd-a-better-ircd-rfc/ clearly describes a session based proto

Framedragger: (ah in fact a bit up the stack, http://trilema.com/2016/gossipd-design-document/#comment-121602) ☟︎

sina: this will change my design a little bit

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? ☟︎

asciilifeform: 1) original mircea_popescu's algo: http://trilema.com/2015/artifexd-a-better-ircd-rfc 2) the newer: http://trilema.com/2016/gossipd-design-document

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)

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 ☟︎

asciilifeform: to trick systemd-resolved in to allocating a buffer that's too small, and subsequently write arbitrary data beyond the end of it.'

asciilifeform: in other, not wholly unrelated, lulz, '...out-of-bounds write in systemd-resolved in Ubuntu, which is possible to trigger with a specially crafted TCP payload. ... Certain sizes passed to dns_packet_new can cause it to allocate a buffer that's too small. A page-aligned number - sizeof(DnsPacket) + sizeof(iphdr) + sizeof(udphdr) will do this... A malicious DNS server can exploit this by responding with a specially crafted TCP payload

mircea_popescu: i got a whole silo fulla these btw, if you need.

Framedragger considers posting a bet re. this

shinohai: If your sole contribution to computing is "adding fucking emojis" please die in a fire.