Question on the 'hole punch'
Read the doc you posted.
Have you implemented the one where the server helps two clients to establish a connection and then the server drops out of the conversation? OR does the server STAY IN the conversation...
IF not I am concerned about the risk of the server being able to 'change' the conversation between the two peers - a kind of spoofing of the trade... e.g. you think you are receiving person A's keys but the dest key has been swapped by Evil Bobs server for Bobs key so you start sending to Evil Bob thinking its the nice person you started the trade with...
I think the TX logic will detect it but not sure it can then reverse/refund it if bob is clever about which subatomic components he spoofs... Need to look deeper - its the introduction of the server that has made me think about malleability of the direct conversation between the two peers.
EDIT: If we are super paranoid - sign all direct TX messages with senders private key, they can't then be changed and receiver can decode with public key just like other tokens, then it doesn't matter what path the communication flows.,,, Evil Bob can watch and howl in frustration because he can't change the packets...
it is just a directory service. One you get the info on the peers, it is all locally maintained. I will most definitely add the tokened security before launch, it is just a pain to have to generate a token for every request.
I pushed the source to a modified version of
http://basyl.co.uk/code/punch/doc/files/Readme-txt.htmlIt was a guy's toy project, and had some bugs, but easy to fix and I was able to integrate it into the source base pretty quickly. Enhancement for binary message support is working. Packetization is still a bit buggy, but not surprising since I coded it during hours 12+ of my coding day. Stuff like that is better during the first hours
Since peer to peer comms are pretty central to crypto, I figure its worth a couple day delay to get all this sorted. With the chat service active, I hope once I add windows support, we will be able to get more testers
James
--------------------------
Think there is a minor reconnection bug...
If I leave a group and then try to rejoin I get this
group name : NXTsubatomic
Connecting as 'chan3test' in group 'NXTsubatomic'
Server is at: 209.126.71.170:60218 (colo.hostirian.com)
server rejected user/group: group member with this name already exists
so it still thinks I'm connected after i've left..
might cause problems.
I've destabilized it a bit with lots of code changes. The most important thing for me to know is if you are able to chat with Jay. If you can that means the "cant open connection" problem is fixed and there are no roadblocks
James
---------------
http://209.126.71.170/NXTsubatomic_v09.ubuntu.ziphttp://209.126.71.170/NXTsubatomic_v09.mac.zipI think I stabilized the chat, at least it seems to work for me. While I was fixing bugs, I added automatic authentication using NXT tokens.
When you login to the chat, you MUST use the "name" from the AccountInfo, otherwise you will get rejected. You also need to make sure your time is synced to ntp, or you will get rejected. In the description field of Accountinfo, you need to set "username":"<username on your PC>" so it can find the coin daemons. If you set a "group" field, it will automatically log into that chat group. "NXTsubatomic" is where the default group is for now
Oh, I made it open a new terminal window for Mac so the chat is totally separate from all the debug printouts.
Oh, yes, what took most of the time was making it encrypt every chat message using a session specific public/private key. I use nacl library
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf e Curve25519 elliptic-curve-Diffie Hellman function, the Salsa20 stream cipher, and the Poly1305 message-authentication code. A 24 byte high entropy nonce is used for every message.
Now that encryption is part of the dataflow, we are one step closer to NXTmixer!
When you are doing a chat,you can always agree to go to a private group as you need to specify the destination or it goes to everyone in the group.
It would really be nice if we can verify that multiple people can all do encrypted chat. The server is used as a directory, but all the chats are point to point UDP using the hole puncher.
James
P.S. The ubuntu version does not spawn a new window, but it should work fine.
Edit: I am seeing several attempts to login without a name set. You need to do a setAccountInfo command from
http://127.0.0.1:6876/test and set the name field (first one). Without that it wont authenticate