Show Idle (>14 d.) Chans


← 2021-09-13 | 2021-09-15 →
dulapbot: Logged on 2021-09-13 14:36:02 punkman: if we forget about packet size limitation, I suppose message could contain N encrypted copies, one for each peer, and hearsay broadcast now has meaningful sig for recipient, even if not received directly
punkman: suppose we put an HMAC(Message) next to Message in Red Packet. Maybe Peer1 can somehow aggregate one HMAC for each of his peers, into a single HMAC(Message) that doesn't take up N*64 bytes
punkman: now Peer2 can forward Peer1's message to Peer3, and Peer3 checks for "is HMAC(K_1, Message) in AGGREGATE-HMAC(Message)", and can thus verify that the forwarded message was indeed signed by Peer1
punkman: maybe Peer1 can make a Bloom filter that can hold (number of peers)*2 64byte strings, he calculates HMAC(K_N, Message) for each peer, puts it in Bloom filter, and uses that as the AGGREGATE-HMAC
punkman: now if you peer with a new person and he tries to getdata, neither you or other peers can send him the old packets, they must be reground by original speaker so AGGREGATE-HMAC includes HMAC for the new peer.
punkman: so new peer can only getdata directly from you, and doesn't even need the inner AGGREGATE-HMAC to verify it's coming from you
punkman: question is how small can we make this Bloom Filter, while keeping the "is HMAC(K_1, Message) in AGGREGATE-HMAC(Message)" operation reliable/secure
PeterL: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-13#1057913 << RE. handle collisions: you can ask politely that one of the two change their name, but iiuc that would require setting up new connections with each of their peers?
dulapbot: Logged on 2021-09-13 14:25:56 asciilifeform: punkman: say asciilifeform has peers a,b,c. punkman has peers x,y,z. asciilifeform and punkman became peers.
punkman: if Peer2 wants to send "Peer1 says he luvs cock" to Peer3, he could generate a filled up bloom filter with a XX% false positive rate, and then HMAC(K3<->1, FakeMessage) will pass the test XX% of the time.
punkman: so Peer3 must be able to verify that the Bloom filter has a small enough false positive rate
punkman: PeterL: even if one of the Joes decides to be "Joe_2", now everyone that has logs/cache must go and change, if logs are to keep making sense
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-14#1058098 << imho terrible idea. there's what, 320 message bytes avail. to cannibalize for such a pseudosig; even if you leave only a pittance for the msg text itself -- that's still a very small space, while a wot could be ANY # of entries
dulapbot: Logged on 2021-09-14 05:20:19 punkman: suppose we put an HMAC(Message) next to Message in Red Packet. Maybe Peer1 can somehow aggregate one HMAC for each of his peers, into a single HMAC(Message) that doesn't take up N*64 bytes
asciilifeform: if i have 500 peers, and the aggregate is only 4x larger than a standard hmac, what do you suppose will happen.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-14#1058108 << it trivially won't. and meanwhile adds mega-overhead to all processing.
dulapbot: Logged on 2021-09-14 08:16:50 punkman: so Peer3 must be able to verify that the Bloom filter has a small enough false positive rate
asciilifeform: it is difficult imho to think of a worse idea for pest.
asciilifeform doesn't even understand why to contemplate any such thing, when reasonable solution already posted.
dulapbot: Logged on 2021-09-13 16:25:46 asciilifeform: sooo punkman , cgra , et al: let's try this 'solution' on for size :
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2021-09-14#1058110 << mno ? so, trinque turned into signpost , do 'logs must change, to make sense' ? why ?
dulapbot: Logged on 2021-09-14 08:23:28 punkman: PeterL: even if one of the Joes decides to be "Joe_2", now everyone that has logs/cache must go and change, if logs are to keep making sense
punkman: asciilifeform: yes never mind about the logs
punkman: per simple calculator: 120bytes gives you 100 item bloom filter with 1% false positive, 180 bytes for 100 items 0.1% false positive
punkman: not great for 500 peers
punkman: and you'd have to process 500 MACs
asciilifeform: 500macs per se aint fatal, they parallelize (speaking here of the ordinary kind, rather than lossy)
asciilifeform: punkman: the problem is elementarily that the bottle is finite but the water, if you will, is unbounded
punkman: do you suppose you will ever have 500 peers, meaning 500 people with GPG keys, and exchange secrets with all of them?
asciilifeform: punkman: likely not. but not prepared to say 'well you oughtn't have moar than x.. and btw probability of forgery will go up geometrically with # of peers'
asciilifeform: right now the only limit for peer count is how many cpu cores you can spare
punkman: suppose you had 500 people in WOT, 2-3 times Dunbar number, is it so wrong to say that "I can only fit 100 in my living room"
asciilifeform: punkman: i find the very principle of climbing forgery %rate unacceptable.
asciilifeform: bloom filter exemplifies errything asciilifeform despises about heathen crypto.
asciilifeform: the crypto is to function identically regardless of # of peers. or it's hokum.
punkman: 1 in 100 false positive with 100 people, means if I generate message+random bloom filter, I need to send to ~100 peers for 1 to believe in forgery, then you can also add in that "bogosity" measure
asciilifeform: mno. simply means you need to generate 100 forgeries.
asciilifeform: (in practice, ~50)
punkman: if I send more than 1 forgery, you can already sound alarm
punkman: we have selfchain
asciilifeform: punkman: i aint using lossy crypto. i aint participating in a network that uses lossy usg.crypto. this is asciilifeform's final word on bloom filters.
punkman: and if we also think about the commitment scheme, then I need to send message and reveal random for you to have correct random in forgery
asciilifeform: punkman: lol how many bytes wouldja then leave for text ?
asciilifeform: if yer eating 100 for blomism, anuther 64 (32 : H(R), 32 : R') for committment ?
asciilifeform: 156 for msg is kinda laffable imho
asciilifeform: anyways i utterly , thoroughly fail to grasp the point of this horror show, when one can simply print the # of peers who duped-with-bounces==1 a given hearsay. as detailed yest.
asciilifeform: each such peer counted is effectively equivalent to that msg carrying that peer's sig.
punkman: no particular point, just derping out loud. might be useful for different application
punkman: was also thinking about commitments and ended up with horror show of a hash-based signature scheme
punkman: what does asciilifeform think of hash-based sigs as replacement for GPG signing?
asciilifeform: (only practical imho for emergency use)
asciilifeform: !w poll
watchglass: Polling 17 nodes...
watchglass: 185.85.38.54:8333 : Could not connect!
watchglass: 84.16.46.130:8333 : Could not connect!
watchglass: 185.163.46.29:8333 : Could not connect!
watchglass: 71.191.220.241:8333 : (pool-71-191-220-241.washdc.fios.verizon.net) Alive: (0.035s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531 (Operator: asciilifeform)
watchglass: 205.134.172.4:8333 : (172-4.core.ai.net) Alive: (0.082s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=700531
watchglass: 54.39.156.171:8333 : (ns562940.ip-54-39-156.net) Alive: (0.111s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531
watchglass: 205.134.172.26:8333 : Alive: (0.146s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=700531
watchglass: 208.94.240.42:8333 : Alive: (0.159s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531
watchglass: 205.134.172.28:8333 : Alive: (0.144s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Return Addr=0.0.0.0:8333 Blocks=700531 (Operator: whaack)
watchglass: 205.134.172.27:8333 : Alive: (0.293s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700419 (Operator: asciilifeform)
watchglass: 143.202.160.10:8333 : Alive: (0.294s) V=70001 (/therealbitcoin.org:0.7.0.1/) Jumpers=0x1 (TRB-Compat.) Blocks=700531
watchglass: 54.38.94.63:8333 : (ns3140226.ip-54-38-94.eu) Alive: (0.262s) V=88888 (/therealbitcoin.org:0.8.88.88/) Jumpers=0x1 (TRB-Compat.) Blocks=700402
watchglass: 213.109.238.156:8333 : Alive: (0.416s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700531
watchglass: 103.36.92.112:8333 : (terebe.ns01.net) Alive: (0.643s) V=99999 (/therealbitcoin.org:0.9.99.99/) Jumpers=0x1 (TRB-Compat.) Blocks=700419
watchglass: 176.9.59.199:8333 : Violated BTC Protocol: Bad header length! (Operator: jurov)
watchglass: 192.151.158.26:8333 : Busy? (No answer in 100 sec.)
watchglass: 205.134.172.6:8333 : Busy? (No answer in 100 sec.)
PeterL: Does pest need 64 bytes for the signature? Could a smaller signature be used, and allow a correspondingly larger message size?
asciilifeform: PeterL: how much of a diff would 32 extra byte of text payload make ? you still need 2 to cover a max len irc msg
b: hi asciilifeform. what is the reserved field in pest packets for?
asciilifeform: hi b. ( who might you be ? ) -- answered in earlier thrd.
dulapbot: Logged on 2021-09-10 16:30:04 asciilifeform: PeterL: so that all other fields 32bit-word-align.
bomolochus: ah, only grepped spec.
asciilifeform: b: do we know one another ? how didja come across dulapnet ?
asciilifeform: err, bomolochus ^
bomolochus: historically ben_vulpes
asciilifeform: bomolochus: i.e. he introduced you? or yer ben under new nick
asciilifeform: ( if the latter, plox to ping signpost (aka trinque) to update yer deedbot reg )
bomolochus: fancy, glad to see the continuity
bomolochus: will do
asciilifeform: bomolochus: wb! then
asciilifeform: errything's continuous, http://logs.nosuchlabs.com/log/ goes back to 'dawn of time', searchable/linkable
bomolochus blows dust off finger-macros
asciilifeform: quite a few of the old playing characters are here
asciilifeform: bomolochus: don't hesitate to ask about the pest spec (didja get a chance to read whole thing? and threads?) -- or anyffin else
bomolochus: i've read the spec, but it deserves a second pass. haven't read all of the logs threads yet, but some.
asciilifeform: bomolochus: very much a work in progress; rekey section not written yet; the hearsay mechanism from yest. -- ditto
thimbronion: Updated the packet structure for alcuin to match 0xFE - I'll post the relavant code soon in case anyone has the time to check it.
thimbronion: *relevant
signpost: thimbronion: yeah I'll fire it up.
signpost welcomes bomolochus, is who he says!
signpost: I'll update deedbot when he gets the chance to sign same.
← 2021-09-13 | 2021-09-15 →