Day 55 Layer 1 Encryption State

What I did: Finished up Crypto.decrypt, rxUUID and txUUID along with reengineering state management for UUID reissuing.

Time spent: 115.60

Comments:

Working on UUID_t and reading thru code to see how it's used.
.getUUID():UUID, .valid(UUID):boolean and throws RefreshStateError if out of UUID's to use.

txUUID has .getUUID():UUID and rxUUID has .valid(UUID):boolean

Both are constructed using Uint8Array[]

Alright finished txUUID() which is the easier of the two.

Now working on rxUUID() which is the harder one.

This we have to take in several ideas and optimize them pre compilation. This is because if this changes it will require changing a few other areas. This is where rigidity makes sense.

Now looking for a bloom filter that is Uint8 based and not using Strings.

https://github.com/raghav-grover/node-bloom-filter/blob/d02d40309c112cade51c3bc2127c566bd350a247/bloomfilter.js#L337 looked good but then it turned out to use strings underneath the hood which is a problem...

Except this is preoptimization issue. What I'll do is write a method that converts a 128 bit into hex and then compare the resulting strings!!!

Also will need to use Browserfy for web development.

Finished both now!

Working on Decryption Engine now.

Stopped. Need to understand how the flow happens. The full flow.

Need to address five scenarios and how the protocol will address it:

Refresh
Transmit files
2a) Refresh command
2b) Disconnection
Transmit JSON
3a) Refresh command
3b) Disconnection
Disconnection mid connection
Disconnection

What causes refresh to occur?

When we've reached 80% usage of rxUUID or txUUID this is only triggered once as an error.
Throws an error. rxUUID and txUUID can only throws these errors once per instantiation. When this occurs we need to flush the outbound queue, process any inbound messages.

We need to send a command packet to remote indicating that we need to finish up any messages and hold all future messages until (except acknowledgement packets) we've renegotiated a new anti replay UUID's.

Since the layers are designed and the antiReplayUUID's are injected at the last moment. A failed command will hang in layer0.

However we're going to need to modify the EventQueue... unless we but a block on layer3. If we put a block on layer3 with exception of 'systemCommands' then we automatically stem the outbound SPackets so that they dry up. Once they're dried up all the layers0 to layer3 can report dry and then we do a gracefulSwitch. In the future we'll setup the protocol to handle abruptSwitch.

In the event that somehow this fails and we've hit 100% usage of rxUUID or txUUID then the system will do a forcefulSwitch. This will create new Encryption/Decryption engines. We'll also clear the outbound queue but not the inboundQueue (because a new message could have arrived between the time we refreshed and before we had a chance to clean the queue).

Okay I'm going to need to look at how layer0 and layer1 interact. We have 3 retries before giving up (this is to prevent clogging of packets at layer1 because of a glitch that occurs at another layer. If it fails for some reason, we just resend data from a higher level again. However this is meant to deal with network and accidental corruption.Also with active hostile interception as well.

Design State flow for layer1.
How do we know when to resubmit messages? How does this interact with the layer0? We don't want to sent messages before layer0 is ready to receive them.

We need to clear layer0 once a new session has been setup (flushing outboundQueue) and at the same time deal with throttle messages state (for when UUID's for anti replay are running out) [since either side can trigger them].

Focusing on designing state flow for layer1.

What events and flow does Layer1 process?

From above the following:

OperatorSwitch
ProcessSessionSPacket
From within:
Tick
Resend
From below:
Sent
ProcessSessionRefresh

Alright setup the flow and finished defining scope of each.

Working on processSessionRefresh.