Topic: tlsnotary - cryptographic proof of fiat transfer for p2p exchanges - page 2. (Read 42802 times)

Hi Waxwing! Yes, your comparison is very reasonable.

But we're not discussing a reasonable adversary, but one who uses armed force to gain economic advantage and who adjusts the rules to suit its goals.

tlsnotary will be construed as something like wire-tapping and conspiracy to commit fraud (after all, the bank, who is one party to the communication, has not consented to the use of tlsnotary). I'm not calling it that; I'm saying that they'll apply some such label. And if the statutes as they stand are not sufficient then they'll change them to make their case stick.

But if they can't identify the participants because they remain pseudonymous then the statutes are moot.

Another thing to reflect on: I (like millions of people around the world) have had occasion in the past to *print* my bank statement - including the account name and number and the balance, and monthly transactions, and present it to a local bureaucratic office to "prove" my savings/income. This was done without my bank's permission.

Is tlsnotary really so different to that, in terms of privacy and permission? It *is* different in one very important sense - it's *actual* proof, not pretend proof!

Hi Oakpacific! Thanks very much for your thoughtul response.

Ratings will mitigate the problem of bad actors in the same way that ratings mitigate centralized monetary exchanges and markets.

Consider the late Sheep market as a perfect example of the latter.

An evil operator will patiently build reputation while fulfilling his role faithfully, all the while getting bigger and bigger, and then one day take everything and wipe his clients out.

In the case of an evil auditor (whether private or state) and auditees that are de-anonymized to him, he will patiently collect real-life identities until a huge database is amassed. Then one day there are sudden and co-ordinated mass arrests.

"Under the radar" is a silly idea. You think LE isn't already monitoring a big site such as this?

Hello hgt, at this moment, what you have to rely on, is the good-old rep/rating system, much like, you know, how they did in online black markets to counter Sybil attack.

We do expand serious effort to come up with something that can allow an auditee to have only the part of his statement that is strictly necessary (i.e., the amount and the destination account) to be verified by the auditor to be authenticated(which we call the "dark mode" in a tongue-in-cheek way), in the end we prove it's somehow theoretically not impossible, but is rather tricky would require quite a lot of developmental effort. Also note that the 'dark mode' still can't protect the identity of the seller, which is inevitable as the auditor has to make sure the money goes to the right account.

The good news is that I believe we are definitely not on the radar of the agencies, if we ever become so popular to draw their attention , we will certainly invest much more effort into the anonymity protection.

Thank you for your question!

Because they make the rules and they will change them to prohibit whatever they don't like. Witness the fact that we have statutes prohibiting "money laundering" and "structuring" - legal concepts that were invented in the last twenty years.

Even if they didn't act immediately, the banks would amend their TOS to disallow it, until the government caught up (but they're almost the same thing).

It's absolutely certain.

The only way to avoid such an outcome for the individual client is to prevent his real-world identification by the auditor. The client has to remain pseudonymous. If you have to trust the auditor then what have you accomplished with all the rest of the trustless technology?

Why would this be so? Surely they could not make it illegal to secure your own end of a data connection in which ever way you see fit?

It doesn't penetrate the corresponding party's system and it abides by the established secure connection protocol offered.

I hope I'll be forgiven if this is a question that has already been answered:

What if the "auditor" is an undercover cop and you're in a jurisdiction where this is illegal (surely everywhere once they find out about it)? Since the auditor can see your bank statement then he can see your account name and number and thus identify you. Is there provision for obfuscating that information?

Hi yakov,
Yeah, it's still going

We'd like people to try it out, as it's basically a finished product now (famous last words )

Ideally if we could get a good group of people (we don't need hundreds or thousands, just 'some' is fine) that could give it a try, then we could iron out any bugs and also get good feedback on what proportion of websites it works OK with (from extensive automated testing, it works with the vast majority of https pages, but certain dynamic features in some websites might stop it working in the way you want).

Installing it is very easy nowadays compared to what it was. Just have Firefox, have Python, and it should run out of the box.

I've tried to put tons of explanatory information in the README on the main page: https://github.com/tlsnotary/tlsnotary . So anybody new to the project, start reading there.

Thanks.

I've just read this entire thread. It looks great.

Is this project still going?

The newest location for downloading https://github.com/tlsnotary/tlsnotary.

THe software now is near feature-complete, but in order to test its compatibility with the large number of banks out there, we need testers! Please, if you want to help freeing Bitcoin from the harassment of the banks, come and talk to us.

E-mail: tlsnotarygroup-at-gmail.com

Freenode IRC: #bitsquare.io

Introductory video for tlsnotary: https://www.youtube.com/watch?v=kKdEhuiXYz4&list=PLnSCooZY6_w9j5tQ8jAeZtrl9l4NnL48G&index=3 (EDIT: updated link, new Intro video - also algorithm video in the same playlist)

(re-shared after some updates and checks).

Commentary/update (refer to (EDIT: paper is now at https://github.com/tlsnotary/tlsnotary/blob/master/data/documentation/TLSNotary.pdf?raw=true) for technical details):

So the last few weeks have been focused on patching what was, although practically very implausible, a theoretically important weakness in the design that we had been working on. That's why I killed the earlier doc and video links.

You can see a reference to it in the discussion on the thread back in February - does the fact that the client doesn't check the server mac during the (very brief) audit connection matter? Basically, yes it does - TLS provides authentication, and that mac check is the cornerstone of the authentication. It might be crazily difficult, but in principle someone might be able to alter the traffic in a malicious way.

So this hole has been patched (credit to dansmith for the main idea to solve it), and as described in the abstract of the document in the previous post, we have now fully reinstated the TLS security model, modulo a reduction in the entropy of the secret.

How is it done? The client (the auditee) makes a request to the server using the tlsnotary special sauce negotiated premaster secret, but at that point doesn't know the server mac secret/key. When the server sends the response back, the client effectively hits 'pause' and doesn't decrypt this traffic. The client/auditee sends a hash of the traffic (i.e. a commitment) to the auditor, who only then sends to the client/auditee the required secret data to reconstruct the server mac secret. At this point the client has the entire master secret for the session and can safely decrypt. They could even render it in the browser safely, although for other reasons we set it up so the client only looks at the raw html of what's being audited (just that one page).

All this shenanigans does not impact the user experience really (or at least, not more than it did before) - the user just sees a page reload taking a few seconds extra (and there are info messages in the status bar telling them what's going on in the mean time).

Some extra modifications have been done, importantly RSA encryption of the peer to peer messaging has been implemented.

As it stands, everything is badly in need of more eyes on it. I am much happier (see underlined above) and I have tested all this stuff to death, but the usefulness of that is limited beyond a certain point.

If anyone has questions about where to find stuff, please ask me.

see below

hi everyone, oakpacific told me to drop by and talk about distributed oracles.

We just published this whitepaper a few hours ago
http://github.com/orisi/wiki/wiki/Orisi-White-Paper
and we'll have an implementation ready of it tomorrow.

The idea behind Orisi is that there can be a set of independent oracles locking the funds until some external condition occurs. So it's something similar to what you guys need to have done.

Perhaps you can get some cool things out of our whitepaper, or even fork our solution and just attach your verdict module?
Feel free to ask me any questions, although I'll be going to bed any moment now (Europe, midnight, long day)

We are actively looking for testers! Please, if you want to join, and help creating a future where people can trade and use bitcoins without being subjected to the whim of the banks, come to talk to us on #bitsquare.io on freenode, or ask here.

New update, now supporting custmoized IRC server/channel used for auditing information exchange, download with git clone https://github.com/themighty1/tlsnotary

The latest alpha release of the tlsnotary software has just been updated by dansmith and can be found at https://github.com/themighty1/tlsnotary/releases.

A few points about the current state:
We have been able to build binaries for MacOS, and indeed run tlsnotary, but there are some technical problems. We'll keep you updated on that. (Edit: Mac OS is now available - ignore the 'Tor Browser' branding; it is not a Tor Browser; we just reused parts of their build process).

The binaries are built using gitian and should therefore be reproducible. See the folder data/gitian for details.

For those running typical Ubuntu installs (and possibly other Linux distros), you may find that there are problems if your version of tshark is 1.6.7 (as it is by default in some cases, even if you do sudo apt-get install tshark). You should upgrade to tshark 1.10. Ask here if that proves difficult.

To test the basic functionality, run in 'self-test mode'. This will start both an auditor and an auditee running on your machine. Pay attention to the instructions in the status bar. Press 'Record' to audit a single page (Edit: button is now 'Audit this page'). You can do this multiple times to get multiple pages audited. At the end, press 'Stop', which will complete the audit by sending the evidence to the 'auditor' (in this case, yourself).

For real time support, you will usually find us hanging out on #bitsquare.io (temporary change of name) on freenode.
Or ask here if you prefer.

Looking forward to using the actual service.

Amazing work once again. I don't have the time/energy to check the maths unfortunately, but it sounds plausible.

A short update of the project status: we have managed to tackle the MITM problem by splitting the MS/keyblock generation process between the auditor and the auditee, as it turns out, the RFC 2246 TLS standard effectively allows the splitting in the definition of the MS generation function:

PRF(secret, label, seed) = P_MD5(S2, label + seed) XOR P_SHA-1(S1, label + seed),

where S1 and S2 are the first and second half of the 48 bytes PMS, respectively.



The basic procedure is a modification from that posted by dansmith: https://bitcointalksearch.org/topic/m.4998488.

1. The auditee connects to the bank's server and starts a TLS handshake.
  
2. The auditee gives the auditor the bank's public key, client_random and server_random.

3. Both auditee and auditor independently generate 24 bytes of random data, called S1 and S2 respectively per the definition of the RFC2246 standard.

4. Both parties then cooperate to generate the encrypted PMS with the bank's public key, using the homomorphic property of RSA encryption:


RSA(2^(k_p)*P+2^(k_1)*S1+1)*RSA(2^(k_2)*S2+1) mod n=RSA(2^(k_p+k_2)*P*S2 + 2^(k_p)*P+2^(k_1+k_2)*S1*S2+2^(k_1)*S1+2^(k_2)*S2+1),

where P is a factor used in construction of the PKCS RSA padding. As can be seen from the result of the above equation, the cleartext PMS that is to be used by the bank can be splitted clearly into parts which can be generated separately by an auditor/auditee, as long as k_1 > k_2+k_s, where k_s is the number of digits of S2.

5. The auditee calculates P_SHA-1(S1, label+seed), generating 48 bytes - H_1 = H_11||H_12, where H_11 and H_12 are of equal length of 24 bytes.

6. The auditor calculates P_MD5(S2, label+seed), generating 48 bytes - H_2 = H_21||H_22, where H_21 and H_22 are of equal length of 24 bytes.

7. The auditor gives to the auditee H_21.

8. The auditee gives to the auditor H_12.

9. The auditee constructs M_1 = H_21 XOR H_11 (the first half of the master secret).

10. The auditor constructs M_2 = H_12 XOR H_22 (the second half of the master secret).

11. The auditee now calculates X=P_SHA-1(M_1, label+seed).

12. The auditor now calculates Y=P_MD5(M_2, label+seed).

13.The auditor and auditee share those bytes of each of X,Y which allow the other party (using XOR again) to generate the required secret data: for the auditor, the server mac secret, and for the auditee, the client and server encryption keys. During the whole process, neither the auditor nor the aduitee has access to the full PMS/MS/keyblock, which prevents both the MITM attack from being carried out, and the forgery on auditee's part. The finished handshake message can be generated similarly as it uses the same PRF function.

Known problems:

Padding the secret is a bit tricky, as it needs to meet certain specified format, however we are already able to generate valid PMS at a high probability(about 90% of the time).

The entropies of both S1 and S2 are a bit too small, with that of S2 being as small as 10 bytes, however any brute-force attack can only be conducted in real-time as the PMS will not be reused, so even 2^80 possibilities pose a formidable challenge to any known potential attacker.

The above procedure will only work for TLS 1.0/1.1, as the TLS 1.2 changes the PRF to use a single SHA-256 function, yet given the slow pace of IT infrastructure upgrade it would take many years before the TLS 1.0/1.1 are phased out.

Implementation:

All of the modifications are already implemented, live trials have been conducted successfully as well, right now dansmith is working on polishing the NSS patch.

As always, questions are welcomed, especially attacks against the security.