Cryptographic Protocol on a PICO

Cryptographic Parameters Used in cryptomsg4.js
The objects that use cryptographic parameters:

1. Random
   1.1. AES1 flag 0 or 1
   1.2. AES2 flag 0 or 1
   1.3. Pdir1 0 or 1
   1.4. Pdir2 0 or 1
   1.5. Owtype 0, 1, or 2
   1.6. Perm1 128 bytes
   1.7. Perm2 128 bytes
   1.8. Key1 16 bytes
   1.9. Key2 16 bytes
   293 bytes

2. Myhash
   2.1. AES1 flag 0 or 1
   2.2. AES2 flag 0 or 1
   2.3. Pdir1 0 or 1
   2.4. Pdir2 0 or 1
   2.5. Owtype 0, 1, or 2
   2.6. Perm1 128 bytes
   2.7. Perm2 128 bytes
   2.8. Key1 16 bytes
   2.9. Key2 16 bytes
   293 bytes

3. Client only:
   One Random object 293 bytes

4. Server only:

5. One Random object 293 bytes
   Shared copies on Client and Server:

6. .permIDPW 128 bytes
   4 sets of hash parameters

7. MsgHash 293 bytes

8. AuthHash 293 bytes

9. IDPWHash 293 bytes

10. IDPWkeyHash 293 byes
    1210 bytes
    Total cryptographic bytes in server or client = 1210+292 = 1503 bytes.

Since the client and server have independent Random objects in the cryptomsg5.js, it would be possible to periodically generate new cryptographic parameters. Perhaps this rekey could be implemented with a setInterval() function using a random interval.

Additional cryptographic entropy could be added to the message by the following means:
Currently the text[1] part of the message only carries the encrypted ID+password hash and is cleared to zero for all other messages. If in the zero cases, text[1] contained a random number, and a 32 element permutation of bytes over the text[1] and Rnd blocks the entropy would be increased. A 256 element permutation of bits could also be used, or do the 32 byte permutation followed by 128 bit permutation on each resulting block.
A key exchange password could allow the text[1] to be used to move keys in a covert manner that would appear to be normal operation.
The protocol could require the ID password hash be validated on every logged in command instead of just once.
In the first call to a hash, two parameters are initialized. Cryptographic salt could be used for the initial values.
Note on the direction flags:
The direction flags make use of the bidirectional properties of AES and the permutations.
AES1 flag 0 or 1
AES2 flag 0 or 1
Pdir1 0 or 1
Pdir2 0 or 1
Plaintext can be encrypted to cipher text A and the decrypted back to plaintext, or
Plaintext can be decrypted to cipher text B and then encrypted back to plaintext.
A not equal to B.
A similar process occurs with the permutation function.
It would be possible to use bits in the RND field to modulate the flags dynamically.

The low cryptographic entropy problem:
A commercial device allows remote operation of a lock.
The device is controlled by two messages Lock and Unlock.
The messages differ by one bit in the message and by several bits in the CRC or hashed check code.
A modem using a stream cipher is used to send the Lock and Unlock messages.
The stream cipher makes uses of synchronized random number generators to exclusive or a different random byte with each byte of the message. A=R1 ^ M1, M1=A^R1.
If an attacker can intercept and modify the message, show that he could use:
B= M1^M2, C=B^A to change a Lock to an Unlock or an Unlock to a Lock command.
The stream cipher produces cryptographic confusion but no diffusion. A permutation function can be used to introduce diffusion ( swapping the bits/bytes around in the message) Note that AES in block mode produces both confusion and diffusion but produces the same output for the same input making the message subject to replay without additional steps.

Link from the cryptographic anxiety closet: (Once a can of worms is opened the only process that works is to contain them is a larger can,)
https://securityevaluators.com/knowledge/case_studies/rfid/