I "wasted" a bit of time recently while I waited for more servers to come online for expanded DHT testing and bruteforced some interesting curve25519 properties.
https://bitcointalk.org/index.php?topic=820614.msg9170663#msg9170663Also got a good education from andytoshi who really knows all this crypto math.
Anyway, as it often happens I get lucky and as I was battling the issue of how to do the key exchange and deaddrop address exchanges, the recent curve25519 lessons solved it nicely with the basic shared secret that automatically comes from curve25519.
On one node:
./b SuperNET '{"requestType":"addcontact","handle":"jl777","acct":"NXT-P3K3-M9XB-5MDG-DVNT8"}'
shared.(
ad021e641e6c65e357921fe8348f4d0718f7f81e89a058071d0e73fb3873)
ADD.(jl777 -> NXT-P3K3-M9XB-5MDG-DVNT8)
{"result":"(jl777) acct.(NXT-P3K3-M9XB-5MDG-DVNT8) (12927190866050319905) has pubkey.(45ec94823354d56c549b475c5e3ffd49c9c2cf4a366deed809bfba38dd756318)"}
On another node:
./b SuperNET '{"requestType":"addcontact","handle":"s0","acct":"NXT-Z6JT-5TB6-EXSL-48JPG"}'
shared.(
ad021e641e6c65e357921fe8348f4d0718f7f81e89a058071d0e73fb3873)
ADD.(s0 -> NXT-Z6JT-5TB6-EXSL-48JPG)
input.({"requestType":"addcontact","handle":"s0","acct":"NXT-Z6JT-5TB6-EXSL-48JPG"}') -> ({"result":"(s0) acct.(NXT-Z6JT-5TB6-EXSL-48JPG) (2834459742776037913) has pubkey.(7b689a7b0035bcaa944ac5d38415ebbe81a9fa2f3f3cb3898872a5075bed1a15)"})
I decided to just use the same pubkeys that is in the NXT blockchain. Since I can directly generate the pubkey and privkey and already auto-generate accounts via linked addresses, just by using a single coin address, you can get a universal pubkey that SuperNET can use to encrypt things to your node.
The blue shared secret is something that only the two nodes are able to generate and so now not only can I encrypt the comms directly between the two nodes, I can find a key to store these comms in the cloud without worry about it being spoofed, plus even if the address is figured out somehow, it has to be encrypted and only from the specific other party.
Another key advantage to using the permanent pubkeys is that now transactions can happen in non-realtime. This was one of the few weaknesses of Teleport, but now things would just progress as far as they can as each party is online. Basically, the cloud becomes a virtual fully encrypted bi-directional peer to peer communications channel for arbitrary data.
All built on top of onion routed Telepathy DHT comms to non-existent deaddrop addresses with an encrypted attachment. Also at the DHT level, all these Telepathy requests will look like they are coming from the same account. There is no need to authenticate the outer part of the packet as it will be fully authenticated inside the attachment. I think the fact that it decrypts using the shared secret is enough authentication, hopefully someone will correct me if I am wrong on this assumption.
I already have all packets the same size (1400 bytes) and they are randomly delayed/shuffled to prevent timing analysis and with nobody knowing the actual destination I believe we have unlinkable IP addresses while using IP packets.
The cloud location where the deaddrop addresses are exchanged will be calculated based on:
sha256(sha256(acct || sharedsecret))
The inside hash value will be the encryption key for the contents using AES. Maybe I will reverse that, yes that seems a bit better to make the encryption key one step beyond the location.
So a lot of progress!
James
