Topic: mgw - page 2. (Read 3794 times)

Dont rush this. In some sense this is the most important part of the gateway. There is plenty of time, we are still not even feature complete

I fully expect that all the major GUI's will add a gateway section to deal with gateway specific stuff. During development, we can just tell the testers they need to go to authentication webpage. Before mainstream release, maybe the client software interfaces directly with authentication website? Not sure, still working on low level.

As far as flowcharting, I hope there is enough info here for others to document. I would rather spend time coming up with stuff like NXTmixer than pretty flow charts

transaction explorer would be great, it could be integrated into the authentication website
I am very fluent in C, and I can write much faster and more accurately than if I used anything else. Once things stabilize, I definitely want it to be refactored.

https://github.com/jl777/multigateway is still in flux, but you can get a feel for things and get a head start on the refactoring

I view my code as proof of concept and specification. We will be dealing with people's money so it needs to be as robust as possible

Its in the from the future
at some point someone needs to make one

Where's this plan?

working on it - taking longer than I expected (terminology etc new to me!). Hopefully get back to you with some results later today or tomorrow latest.

Which client software? You mean that the user's NRS client will notice that you're sending assets to the gateway account and it will open the URL of the gateway web site?


Sounds fine. It wasn't clear to me up to now. Actually, it would help if you offered a complete diagram of the flow and the input/outputs of each step, especially for newcomers to this thread. I use http://www.asciiflow.com for simple diagrams (makes a killer combination with http://ditaa.sourceforge.net/)

If you want anything with the site, I'll be happy to help.

I'm still working way through the concepts in this thread, but I think I at least understand the basics as to how this works.

I gotta admit that my excitement was tempered a bit when I realized that centralized gateways were required. I get it though - it is unreasonable to require every client to have the all of the dameons running + blockchains downloaded.

I also agree with antast, in that having this in pure C gives me hives.

So what needs to be done here? Is anyone working on a transaction explorer? I could try to put together something that sniffs the AMs for transactions and displays them somewhere. I'm not really a web guy, so someone else could actually make it look nice. Or I could have a stab at porting some of the C to something more manageable.

I have a day job so my time is a bit limited, and I am sure there will be some time required before I can understand things well enough to be productive. So it may be good idea for me to start with something that isn't mission critical. But I am willing to put some time into it and help out where I can.

I understand that to use GA (Google Authenticator) the web server needs to know the key, otherwise it cant display QR code, which is critical.

I think you misunderstand my intent. I think AM should be the only way to change the withdrawal address. The GA will be an optional step people need to opt in for, so it has to be this way.

At some point the user sends NXT asset back to issuer, this triggers the withdrawal process. Presumably the client software will be updated to bring up the website (or at least URL). Now the user has to authenticate by putting in the GA TOTP, withdrawal address and amount. The last two are so the gateway can match up authentication with specific withdraw requests, in case there are more than one.

The website sends success in authentication with withdraw address and amount and the gateway will respond success if it finds a matching withdraw address, or at least something that is close to it.

Not sure what the problem is with this?

James

[NXTmixer announcement]

Based on feedbacks and ideas in the NXTcash thread, I think i might have come up with a pretty good NXT mixing algo. I just got a successful encrypt/decrypt cycle in the multigateway. Obviously, still very new as I just started coding this today, but now that I have verified proper public/private key handling, the rest is a matter of debugging.

The initial model supports both a mixing service using the gateway and a totally decentralized direct "payment" path. However, since NXT doesnt support multisig (hint, hint, CfB) the mixing is totally centralized on one of the gateway servers. The decentralized part allows (nearly?) undetectable transmission of NXT acct password (or any other data) directly to the destination acct.

Even though I am adding this functionality to the gateway, it is totally independent of the multisig DOGE gateway and also NXTcash. It just shares a lot of the code base, so it was easiest to add to the existing multigateway code. I am using libnacl http://nacl.cr.yp.to/index.html that xyzzyx recommended.

Ah, you want to know how it works?

I added the following to the gateway_AM structure:
Code:
struct payment_bundle
{
    unsigned char escrow_pubkey[crypto_box_PUBLICKEYBYTES];
    unsigned char depositaddr[MAX_NXTADDR_LEN];
    unsigned char paymentacct_key[crypto_box_SECRETKEYBYTES];
    unsigned char txouts[8][MAX_NXTADDR_LEN];
    int64_t amounts[8],sessionid;
};

added to gateway_AM:
        struct
        {
            unsigned char publickey[crypto_box_PUBLICKEYBYTES];
            unsigned char nonce[crypto_box_NONCEBYTES];
            unsigned char paymentkey_by_prevrecv[crypto_box_PUBLICKEYBYTES + crypto_box_SECRETKEYBYTES + crypto_box_ZEROBYTES];
            unsigned char payload_by_escrow[sizeof(struct payment_bundle) + crypto_box_ZEROBYTES];
        };

At the high level there are what I call sessions. Initially, when the activity is low, a session might be as long as a day, but as activity grows, the duration of a session will shrink. It is critical that your transaction isnt the only one in a session, otherwise no amount of anything will help anonymity. If there are 1000 transactions, then with a good system, the best anybody should be able to do is 0.1% accuracy, eg. random guessing.

Each session goes as follows:
A. NXTmixer pays out all the funds that cleared during the last session to the depositaddrs for each NXT addr that received anonymous payment during the session

B. NXTmixer publishes new sessionid and its public key for this session

C. ALL participating nodes publish a SEND_ANONYMOUS_PAYMENTS AM. Yes, I said ALL nodes.

D2. ALL nodes process all of the SEND_ANONYMOUS_PAYMENTS from C and they try to decrypt every paymentkey_by_prevrecv. If they are able to decrypt it (first half matches their previous public key) then they have access to the NXTacct that the password in the rest of the message contains.

D2. NXTmixer also scans all SEND_ANONYMOUS_PAYMENTS from C and processes all payment bundles that properly decrypt. paymentacct_key is for a (temporary) account that is funded with the amount necessary to make all the payments specified in the payment bundle. In order to make sure it wont be emptied and to MIX all the NXT together, the funds required to make all the payments are sent to a shared account. Since NXT is totally fungible, this step is actually VERY effective in removing payment source information.

The NXTmixer updates the credits for each NXTacct during session and when there is enough different payments or max time elapsed, the session ends and we go back to A, where the payments are made.

************
The NXTmixer cannot implement all parts of this by itself, the clients need to implement code that synchronizes all participating nodes. The reason for this is that if everybody is broadcasting, then there is no information leaked when you publish your public key and payment bundle. Since everything is on the same broadcast, anybody can receive the message, but nobody knows if they did or not. This allows a direct transmission of a funded NXT acct to somebody else. Let us assume you will trust them to not drain the account during the next two sessions. Since he is the one paying you, if he does, then whatever deal was in place is off.

userA funds acct A with 10000 NXT
userA encrypts password for acct A using public key of B and it goes into paymentkey_by_prevrecv

userB decrypts the AM and gets the password for acctA and locally verifies that it has 10000 NXT
Now, for the next session, userB sets the paymentacct_key to be the key for acctA and payments can be made from this acctA on behalf of userB, even though userB has NEVER used the password for acctA other than locally to encrypt it into the payment_bundle.

Similarly, you can specify your depositaddr to be an acct that you have never used, but know the password for. Then in later sessions, you can use depositaddr's password as the paymentacct_key. As long as you are receiving payments, you are able to make pretty anonymous payments as I am finding it hard to figure out how anybody can determine payment paths.

Can anybody find any serious flaws with this approach? Should I debug this and add it to the multigateway?

James

Let´s put this here, too, becaue I think that it will get lost in the other thread.

https://bitcointalksearch.org/topic/m.5574707

[NXTmixer announcement]

If you want to use Google Authenticator, the authenticator key must be known to the user, and therefore to the web server.

If, instead of using Google Authenticator, you ask the user to give you his DOGE withdrawal address, you won't be able to change it afterwards via AM. If you do allow changing it via AM, then this beats the purpose of asking it the first time.

Great stuff!

The google authenticator is the second authentication. All withdraw requests, actually all requests, verify that the NXTaddr matches the sender of the AM. So, only the one who controls the NXTaddr should be able to set/change the withdraw address.

Nervous about sharing secrets. Maybe there is no need to? All the gateway really needs is a second approval before releasing a withdrawal. maybe include withdrawal address and amount in the data that is gathered? then I can match it up with any withdraws in the queue

Google authenticator works this way:

There's a secret key (a random string) that leads deterministically to the TOTP token, depending only on time. Both the server (the web site) and the client (user) should know this key, so usually the server shows this secret key to the user via a QR code and the user scans this to his Google Authenticator app (on his phone).

The user afterwards generates the TOTP and gives it back to the server. The server compares the given TOTP with his own TOTP, and if they match, the user is verified. This must be done within 30 seconds, because afterwards the TOTP changes value and it must be sent again.

If you want to verify a user from your gateway as well, we should somehow share the secret key.

I've made a test web site in Python (using Flask) that once a user visits the site, the server sends to the gateway this command  (the names are purposefully descriptive):


and waits for the following:


It then renders the web site where the user enters his NXT address, and authenticates via Google Authenticator (a QR code of the secret key is presented). The DOGE address to which he should make his deposit is also shown with QR code.

When the user submits the form, the following is sent to the gateway:


After this, you have all you need to associate the user's secret key with the DOGE multisig address and his NXT account. You can use AES encryption to encrypt this data before you put it in the blockchain.

All this is just for locally testing the whole concept, of course. Relying on Google Authenticator as the sole method of authentication is like asking for trouble. We'll find many more issues on the way I guess, but at least we can begin testing.

Look at README.txt for instructions on how to run it.

https://mega.co.nz/#!Vd0lzT5b!zJSagQT743QhAkUMzvGU-2YM_p8WXDq1adeZ5z0lFzA

This isnt exactly what I saw, but it does look highly relevant. Can you dig up some objective reviews about this service, especially how it compares to other similar services? Once we find one, we can find all its competitors and then choose the best one for our needs

Thanks for the legwork, it saves me time hour for hour!

James

I´m glad there is some activity here. Let me know if I can do anything for you, guys.

Is this what you have in mind?

If not I'll do some more searching.


http://www.trendmicro.com/us/business/saas/deep-security-as-a-service/index.html

There's a 30 day free trial

I found the above site linked from the following


http://cloud.trendmicro.com/5-questions-aws/

Ok, I figured this out. Stay tuned, hopefully tomorrow I'll have something ready :-)

1. I just want to use the blockchain as a reliable redundant storage of the user's magic number. I am pretty sure I need to encrypt it with a private key that only the gateway(s) know. That way, on startup, the gateways scan the blockchain and load each users magic number.

My understanding is that the google authenticator algorithm generates a time dependent token that is purely based on a user specific magic number combined in some way with the website. This token is called a TOTP.

JSON is fine. I can setup a port that waits for { "acct":"45372594753443", "TOTP":"123456" }
I will just return { "result":"user visible string" }

So there will be a webpage on your server that just asks for the NXT acct # and google authenticator token. You send it to the gateway, which returns a success or error string.

What the gateway will do when it gets a packet from your website is that it will look up the acct and extract the magic number, generate the TOTP and if they match, mark the withdrawal as approved.

I still have to figure out how to encrypt and decrypt and generate the magic number. I think the website will need to generate and display a QR code that the user can take a picture with to initialize google authenticator. It would be great if you can figure out how to integrate google authenticator to a website

James

You mean public key, right? What's the password needed for? I think I still haven't grasped the architecture you have in mind.


It's been a long time since I dabbled in C, and I avoid anything that requires manual memory management like a plague. Nowadays I only deal with Python and Javascript.

So, I can quickly throw code in Python if it's acceptable to you. I believe the best and most simple way for some processes to communicate is via  JSON requests, like NRS does.

What does TOTP stand for? The lore of those acronyms eludes me.

In any case, we'll need a clear layout of the workflow and the separate parts. What exactly will the web UI ask for the user, what inputs and outputs do you want from this UI. What are the modules you are implementing, what function will each one perform, and it's inputs and outputs.