#tlsnotary-chat

so if one treated the webserver as trusted not to collude, then a user could pass around a file *.audit containing the encrypted traffic, the unencrypted traffic, the webserver's signature of hash(commitment hash | rsa enpms1 | server pubkey), and call that a proof.

the interesting question is how does that model differ from : webserver acts as auditor normally, and at end appends its signature to the html page

thus doing what the bank should have done in the first place :)

yeah, that's my fundamental grunt, what difference does it make if people just trust us instead of the bank

https://www.reddit.com/r/Bitcoin/comments/2xyje... ingenious names all the way

oakpacific: it's a pretty big difference tbh

http://www.weibo.com/1981622273/C79uAbD0D you know how do you achieve a claimed 800 million peak TPS in a 'payment system"? easy, by just not updating your database is how you do it

this is about the Wechat's new year red-envelope gifting system

yeah, that much i figured out, i can kind of guess what it's about :)

people can get red-envelopes destined for other people by just changing the userid in the packet

oopsie

is this in ssl? mitm?

btw oakpacific so which of the two models i mentioned above makes sense to you?

the first keeps the notary server as dumb as possible, not seeing data. the second removes the need for another auditor. i guess.

waxwing: why not both

oakpacific: choice is evil :)

ian grigg said so today on metzdowd/crypto. and of course FREAK supports his POV.

waxwing: i meant, both model obviously satisfy a different need, right

there are demands for both

maybe; i don't know.

what would be really nice is to remove the collusion possibility between the notary server and the client so that the trust is still only in the bank/server pubkey, but i can't imagine that being possible. the premaster secret has to exist somewhere.

in a sense, that would be a violation of digital signatures because it would mean you can create a signature without knowing the pubkey

privkey, sorry

ridiculous idea #25: notary server commits 100 hashes of premaster secrets to the blockchain, then collects 100 requests for audits, waits for next blockhash and provably jumbles up which pms halves get used for which audits, making it impossible to use a pre-arranged premaster secret for a particular audit

back in a bit

well, if the trust is on us as humans, then maybe there is something easy we can do ;)

btw i didn't agree with your statement about the signature

which one oakpacific ?

if you are interested i could explain how do you remove trust with NISC, it's fairly scalable judging by what i know, what we don't have is the code

non-interactive..?

oakpacific, do explain, I'm still mystified by the NI part

seemed like the canon-mpc paper put together existing mpc scheme, i didnt realize there was a breakthrough with NI-ness

sorry just got a bit freaked out

i just realized that by using DKIM, mainstream e-mail service providers break my OTR

now i am desperately trying to work something out

otr deniability i meant

we don't need shitcoin we need tlsnotary :)

perhaps i am too cynical but i'm disappointed to see that mercury thing at the top of reddit

hmm, is it actually using coniswap?

or even coinswap

seems so: https://github.com/mappum/mercury/blob/master/s...

the dev just pinged me, it's apparently using atomic-cross chain as described here: https://github.com/TierNolan/bips/blob/bip4x/bi...

waxwing: so you just "freindly fired"

oakpacific: did i?

waxwing: well if they do atomic-cross chain swap they are after decentralized anonymity measure, then they are 'our boys' ;)

yes i think, even if they only manage a decentralized shapeshift.io that's already a useful thing indeed

shapeshift is bound to get pwned one day. the FBI will do it if no one else gets round to it :)

oakpacific: what were you saying about sigs earlier? i didn't get it

waxwing: well, if the mail service provider rsa-sha256 signs your email, then whatever otr protocol you use, you just can't deny that email is not from this particular address right

no, i meant when you said 'i disagree with your statement about signatures'

oh, i c

well, it mostly goes along with my scheme in which volunteers can go to submit disguised secrets for use by the notary

\using non-interactive 2pc

non-interactive 2pc? how does that work?

waxwing: i have been hestitate to say more because i don't understand properly, but it uses a special OT message, which allows you to construct a f(x,y) with y embedded, and just waiting for the x input

what's OT?

oblivious?

yes

here is the paper from 2000, apparently for semi-honest cases it's relatively easy

yet i am not seeing any code surfacing...

wow, one round secure computation. star trek stuff.

well, not really

judging by what i see, people are so bored with the boredom of it that they all went to work on more parties, malicious scenario

oakpacific: pls concretize it. suppose you had the code, how would it work in our case?

okay

you don't recite it every night before bed? :)

okay, firstly, the volunteer contributor calculates RSA(S2), SHA2PC(()XOR H22) and publish them to either a central server or the blockchain, where () is the H12 waiting for the auditee to fill in

'volunteer contributor'? who is that?

waxwing: as i stated above, the idea was to decentralized the trust by asking people to connect to a server to contribute random secrets generated locally, or with other means

ok

so the contributor also generates HMACV2PC(S2,K,M,H), which verifies the page M and its HMAC hash H supplied by the auditee, by outputting S2, the PMS when the HMAC verification passes, or 0, when it fails

this is also put online

S2 is just the PMS-half, sorry

now the auditee creates H1, and H12, then uses P_SHA2PC(H12 XOR H22) to generate the first 120 bytes of Y(not the rest), and use them to create all the keys he needs directly, and retrieve the page and commit it

now when he needs to be audited, he could just supply his M and H to the HMACV2PC function, and get S2, then publish to the world

anybody can verify S2 can be encrypted to RSA(S2), whether the contributor is online really doesn't matter

so that's it

i got disconnected after 'ok':

<waxwing> so in general terms, the volunteer (or anyone) knows that the auditee must have used the provided secret material. does the collusion risk then become (volunteer+auditee)?

(but, let me read the log oakpacific )

waxwing: well, the assumption is, obviously, the majority of them are honest(also they should sign their secrets), and the number of honest contributors >the number of auditees

oakpacific: so did i understand right, that it still needs interactivity from the contributor, to do the HMAC-finished part?

waxwing: no

HMACV2PC is another OT 2PC message from the contributor

oh so it's like, the function is sitting there ready to run

which once generated can be used anytime

yes

this is so hard to understand :)

hmacv2pc(s2, k, m, h), what is k?

the hmac key, which is hidden in the message itself

ok so in vague terms he just puts the functions with his data in, ready to run, and the auditee comes along later and uses it

so what's this trust model issue? semi-honest i think it's called?

you testing dansmith_btc ?

waxwing, yes

waxwing: yes to both

oakpacific: but what does semi-honest mean ?

i just heard the term

waxwing: it means the contributor follow the rules when participating in the protocol, e.g, if there are multiple parties, and they participate in generating an output, and all but one input all zero bits, then they are considered malicious, and the one remaining party's input is certainly going to be revealed

is that workable here?

waxwing: well, the assumption is that the contributor will follow the rules and create real randomness

drama in #bitcoin-wiki

heavy hitters arguing about some triviality :\

non-tonal triviality? :)

heh

oakpacific: ah i see, so if the contributor's contribution is provably separated from the audit, it could be dealt with

you know like blockchain provable randomness maybe

waxwing: yes, that's the point

hmm i think we have a 5 party protocol here :)

bank server, notary server, contributor, auditor, auditee

there is strictly, no need for a certain auditor

you can just put out your bank statement, hmac, and s2

for anyone to see

yeah i get that, i was mulling over scenarios before

but i could easily see it being like that; notary for provable bank statement but still auditor because you don't publish your bank statement to the world

one advantage is that: it might(assuming all will work out) eliminate the connection that can be developed over time between an auditee and an auditor

e.g., someone challenges an auditee to do an audit, the auditee goes on to bribe the auditor, in this scenario we can really assume a large percentage of auditors will fail

however when the auditor commited his secrets he had no idea what will happen in the future, so we could have his past working against him

so the honesty percentage can be relatively high

but when you boil it down, your argument is that a system like this makes the concept of "signed bank statement with trust only in server pubkey" possible, ie a disproof of my earlier statement

that doesn't count as a proof until we sort everything straight :)

e.g., what's the difference with FHE?

sure. but it's like, another way to implement an oracle.

if that semi-honest setup works, i'd be really surprised if there's no code anywhere

does it have a big cpu hit maybe?

waxwing: for semi-honest cases, interactive 2pc's workload does seem to be acceptable

according to my experiment and dansmith_btc 's

well

right but this one is different, right, one message or something

the strange thing is, there are more complicated stuff out there