Day 29 2SSL, PiB data transport and quantum key exchange protocol

What I did: Simplify protocol, review quantum protocol and review 2SSL transmission protocol to ensure data up to 1PiB can be transported.

Time spent: 69.333

Comments:

1 - Deal with Green Geeks answer regarding 2SSL so we're stuck with 128 bit encryption for main site on Firefox....

2 - Dealing with version, security, replay attack and randomValue (avoiding issue with Unicode encoding issues) along with versioning

3 - Quantum Key distribution understanding

4 - Header redesign since each 2SSL connection uses a two password encryption which means that an individual message cracked doesn't leak data for any other data sent within the same channel. In the event that the 2SSL connection level derived key is cracked only that connect and no other connect is cracked.
This means to crack the connections would mean having to crack each connection stream (since each connection stream has it's own primary encryption and each packet is encrypted with a separate key that is unique to that packet.)

This means that TLS + 2SSL ensures 3 layers of encryption preventing leaking data. These first 16 bytes of the session are the session UUID and

5 - Planning replay resistance by tying UUID to the session so the same UUID can't be used. During a retransmission attempt we can request UUID's to be cleared.

6 - Using bloom filters as a probablistic data structures. Since these can be precomputed we at most need two bloom filters - available and used. This is easier than searching thru 65536 UUID's manually. In the event that we need to renew the pool of UUID's we can swap out the UUID's with a precomputed bloom filter. Meaning that there can be 100's of precomputed bloom filters and the associated 1MB of data to sent to the client. So this is work that can occur during idle times and during bootup of the application.

7 - Realized that I need to ensure that the header isn't modified so that an incorrect command isn't sent en route by using a throwaway public/private key pair.

8 - Researching Curve25519 if it's broken or not in terms of Quantum protection. It's secure enough since it's encased within XChachapoly1305 symmetric encryption. In the event

9 - Realizing that XChachapoly1305 is 256 bits of encryption and provides authenticated data of 12 bytes. So public/private key encryption isn't needed....

10 - Reading thru Standard Notes encryption lib to understand the tag size and modifying header to ensure data is KB aligned.
What is associated data that I keep seeing?
Taking a quick dip into https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-xchacha-01
Still don't understand what associated data is but I was able to verify that the tag is 16 bytes.

11 - Happy accident stumbled upon stable lib implementation of the encryption code which means it's possible to move off of Standard Notes crypto library meaning I'm not then tied to the AGPL requirements. If I want to.

12 - Realized that 1 KB header is extremely big for the protocol and I'm left with more than 800 bytes of empty space. Inspecting packet sizes and overhead of TLS. So it can hold approx 1K to 1.5K bytes. I'll keep the header to 256 bytes header which gives us a massive 136 bytes of empty space for us as payload.

13 - Alright had a massive 13 bytes after adding in the necessary control bytes that be configured or interpreted close to 254 ways!!!

I realized data acknowledgment is still a requirement which I'll address in a future update.

14 - Turns out with the current file network transmission concept 2SSL can support transferring files of up to 4.5 Petabytes!!!! WOWOWOWOWOWOW

15 - Discovered issue with nouce reuse within the implementation spec. Figuring out how to fix that. Since I've shrunk from 1KiB and it's now 256 bytes adding a bit extra for nounce is fine. I just need to figure out the layer to add that. Alright just fixed that. The header is now an odd. Alright figured out that I really fucked up the numbering on the header... O_o That's an issue for later today or tomorrow.