Return to Sender

This is just a little update to report, as I have now completed the error correction and message segmentation scheme.

Firstly, I have devised a pretty solid method of hiding the identity of the recipient in the packets. A single byte added to the hash of the identity essentially makes 256 different looking recipient "addresses" but a lot of messages will have less pieces than this. I have not implemented this yet, because I had to figure out the other side, which this post's title refers to. This scheme ensures that an attacker will have very little chance of associating messages together that are in fact related, while it will be cheap for the recipient to identify the segments of long messages.

I have devised a scheme whereby it becomes cheap (in processing) for using a different signing key, and half of the encryption, for each message piece in a long message.

In the elliptic curve cryptography, a secret key is a special number that not every random 256 bits of number can be qualified, there is a limit, but it is not a big limit, just makes sure that attackers cannot exploit the Elliptic Curve Diffie Hellman (ECDH) by using secrets that are outside of the secp256k1 group to force the recipient to leak secret information, as non-group values can reveal information when used for the encryption.

Generating a new secret key is a little expensive. It essentially means getting random numbers from the system's cryptographic random number source, aka "entropy", and this stream of strongly random bytes has a limited supply.

So what this scheme will do, is you have a base secret key, used for signing/encrypting messages to a given peer, and there will be a second, random key that is also generated, which the number can be "added" to the base secret, and this can produce a very large number of secure secret keys that are not so expensive to generate as generating a new key out of system entropy.

This leads to the possibility that in a single message, every single signing key can be different, strengthening the security of the ECDH encryption scheme, without the extra cost of generating as many keys as the number of pieces required to send a message. Many messages will be short, though.

So what I have come up with, is that each message will contain a return address encoded into it compactly.

For short messages, the overhead is greater, but if a message is more than about 12kb in size, it will be possible to spread the return address into the message at a cost of 5 bytes per message. These 5 byte segments will be expanded with reed solomon error correction such that any given 8 messages out of any length of message will give the return key even if the message fails to be reassembled due to lost packets.

After thinking about it further, I decided that the blinding factor should be 2 bytes long, enabling 64k different keys for a message, of which each can be up to around 1kb segments in size, or 64Mb before repeating the same "to" address.

I will be working on this new scheme starting tomorrow.

Using cryptography to prevent surveillance is such a pleasure for me, I love this stuff, which is why I am so happy that I have finally been able to go full time working on this.

Indra will utterly destroy all of the power of NSA and other spook agencies, chinese, russian, all the rest, from identifying the flow of bitcoin and lightning traffic, it will improve the balance of liquidity of lightning channels as well, and will scale up to the point where it becomes completely impossible for even a global government to have the resources to spy on your internet.

That's my end game.