log☇︎
180600+ entries in 0.109s
asciilifeform: now i know that a certain % of the time your 'box' is spilled out of.
asciilifeform: now at some point your smm bios kicks in and spends 700ms adjusting fan speed. and i happen to know that this happens every whatever many seconds.
asciilifeform: say your time box is 1s
asciilifeform: understand: if your scheme cannot be proven to work : it does not work.
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" ☟︎
asciilifeform: and the only way to make it so that i can't -- and ~probably~ so -- is to do your arithmetic in constant time.
asciilifeform: because if i can make your thing spill out of the time 'box' which you made for it, i get >0 info re your key. again.
asciilifeform: the only way to make guaranteed time bound is... constant-time arithmetic
asciilifeform: EVERYONE eventually asks this ☟︎
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
asciilifeform: sina: don't hesitate to ask
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
asciilifeform: (if i can unglue the auth from the payloads, because the latter are plaintext -- IT IS HOMEOPATHIC)
asciilifeform: this is elementary, and the fact that i have to, apparently, explain this, beggars the imagination
a111: Logged on 2016-02-07 23:57 mircea_popescu: complete anonimity between peers more than one node removed ; complete secrecy outside of the node group ; no integrity or authenticity outside of the wot trust.
trinque: ^ great threads in there.
asciilifeform: sina: in the linked thread, mircea_popescu described why he did not want to use rsa ~signatures~
asciilifeform: you gain NOTHING from the crypto unless it is applied correctly - i.e. to whole channel.
a111: Logged on 2016-02-08 00:06 mircea_popescu: the only assurance to be had here comes from a gossipd model. where anyone could have written the plaintext, and for all anyone POORLY CONNECTED knows, they probably did.
asciilifeform: if i want this -- i will use irc.
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
asciilifeform: there is NO reason why enemy should be able to read and alter at will traffic b/w 2 nodes.
a111: Logged on 2016-02-08 00:05 maqp: The point is, unless you encrypt the message, anyone might have created the plaintext
asciilifeform: 'ohai i authenticated and now lemme say [NSA INSERTS TEXT HERE] sincerely yours, mr.chump'
asciilifeform: wtf is the point of writing a proggy that leads to this.
sina: I assumed it was deedbot style OTP thing
asciilifeform: wtf is the point of even having the challenge then !
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
asciilifeform: sina: why do you think mircea_popescu mentioned rsa in his spec ? to keep the room warm with cpu heat ?
sina: I think we might be speaking at corss purposes and just wish to clarify that point before proceeding
asciilifeform: unless it sends only 1 message and then both sides call it quits and never speak again.
asciilifeform: now your homework : prove that an rsa-only channel MUST re-use every key at least once
sina: can I clarify something? when you say gossipd are you assuming that all traffic is enciphered?
asciilifeform: if this is a surprise to you -- i recommend getting familiar with the basic arithmetic
asciilifeform: i can trivially tell when you've switched keys, strictly by looking at ciphertext ( is how rsa works. )
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?
asciilifeform: ( by timing decrypts of session establish )
asciilifeform: 1 ephemeral key. say i break the 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
a111: Logged on 2017-06-17 19:56 asciilifeform: idea of pll is that you can indeed see a lit match from mile away in daylight if you know 'exactly when to look'
a111: Logged on 2017-06-17 19:50 asciilifeform: the imho interesting part of this tale is that ~time~ is the most, it turns out, difficult side channel to properly cement shut
asciilifeform: http://btcbase.org/log/2017-06-17#1671568 << see also thread ☝︎
asciilifeform: sina: and the answer is, interestingly: no
asciilifeform: sina: this is a good q
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
asciilifeform: ( this should not horrify, but encourage. the logs are a very handy resource. )
asciilifeform: sina: if you've been reading anything other than the logs, you have a great deal of catching up to do.
sina: ok fair point, I get the general need for constant time constant space algo regardless of gossipd stuff anyway
asciilifeform: sina: subject is considerably trickier than charlatans (e.g. schneier) let on. in fact, most of what is available on the net, is deliberate disinfo.
asciilifeform: not reusing the keys would do 0
asciilifeform: ( unlike, e.g., gpg, ssl, the rest of the shit soup )
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
asciilifeform: this means ALL ciphertext is the output of rsa modular exponentiations.
asciilifeform: for one thing, there IS NO SESSION in gossipd (either my concept or either of mircea_popescu's two essays) ☟︎
asciilifeform: even 1, cuts the amount of practical work necessary to break your key, considerably.
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?
asciilifeform: sina: if some % of the time i can determine how long it took you to carry out a secret key op (incl. key generation) i can determine a few bits of key. over time, i get 1/4 of them, and that is == to getting the rest.
sina: I am on the general points
asciilifeform: sina: are you familiar with the concept of timing side channel ?
mod6: everytime I think of a shoemaker/cobbler, i think of that character from A Tale Of Two Cities who used to be a Doctor before he did 18 years in the Bastille.
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
mod6: <+sina> hows all today, is it time to rotate shift mod6? << hows that?
sina: hows all today, is it time to rotate shift mod6?
asciilifeform: sina: one of the things gossipd needs is a constant-time-constant-space rsa. if you don't have one, enemy can derive your privkeys remotely based on timing. ☟︎
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
asciilifeform: sina: at least a few folx were playing with very similar things even before mircea_popescu wrote his essay
asciilifeform: and iirc trinque had another
asciilifeform: sina: but understand that the problem does not resolve to '200 lines of py' or would have been solved years ago and we'd all be using.
a111: Logged on 2017-06-26 16:32 asciilifeform: http://btcbase.org/log/2017-06-26#1674428 << fwiw i carefully read all of it. asciilifeform's verdict: very much a gabriel_laddel-ization of gossipd. does 0 of the necessary work, and drags in 5+GB of liquishit deps (python, sql, some derp's crypto lib.) the amount of this that would have to be rewritten, from the ground, is 100%. not even useful as illustration of anything, because NONE of the actually complicated moving parts of a
trinque: gotta wedge the broomstick at the right angle, can sit and sweep simultaneously!
asciilifeform: but say i also make own chair. then which must i be... shoe maker, or chair maker..?
mod6: yah, if you want !b, gotta make them yourself, or hire a sandal artisan of sorts.
mod6: haha. well, suppose you're getting good re-use out of them.
asciilifeform: because a) can't be arsed to go to town to get new one b) ain't like you can get nonchinese sandal anyway
asciilifeform: for the 3rd time
asciilifeform: epoxying, i shit thee not, a paid of shoes
mod6: how goes toinght?
phf: nah, that's your monthly occurrence. ☟︎
asciilifeform: https://archive.is/7bx0V << upstream in same thread << apparently he tried to draw a line, 'stfu with the monolithic unreadable patches'
asciilifeform: meanwhile, 'thief cries thief', https://archive.is/vgrDP << organized pantsuit ouster of linus t. slowly crystallizing...
shinohai: So (signal + ETH - Tor)
shinohai: Apparently they made a "Mobile ethereum interface w/ encrypted messaging"
shinohai: Just another Lame Ethereum ICO that raised millions and now gonna dump to pay for hookers, etc.
ben_vulpes: > sold via OTC over the course of the next month, to ensure it will have a negligible effect on the market
asciilifeform: and that 'your' horse is somehow still 'your' AFTER you join kolhoz.
asciilifeform: gotta luvv the folx so slow on the uptake, who imagine being in 'a community' while having already been subsumed into usg faceless mass.
asciilifeform: from earlier, lulz, 'In April 2017, an unexpected and disruptive change was made to the MIT network: the sale of historically MIT-allocated IP address ranges to external entities such as Amazon. The sale wasn't announced to the MIT community until after it had taken effect. ' ☟︎☟︎
phf: "[Global Notice] Hi all. We need to take services (NickServ, ChanServ and friends down for some quick database tweaking so they'll be unavailable for a few minutes. I'll update via WALLOPS when completed."
BingoBoingo: <asciilifeform> they spent it all on... ethertardium?! << YES!!!
asciilifeform: and the necessary bits -- reduce to a slightly generalized vtron.
asciilifeform: certainly not in the form offered.
asciilifeform: MY SHELL IS STILL SET TO THE KING'S ENGLISH
asciilifeform: and i say this as an orc, who uses cyrillic
asciilifeform: which SHOULD NOT BE A THING
asciilifeform: and produced differing orderings depending on the 'charset' set on the machine