## 3 Approach
### Transmission of Target Value and FrequencyTable, Synchronization of Transaction Pool  
If the Devicesensor transmits FrequencyTablesensor, the Devicegateway can know which frequency (of ModResult) is missing by comparing with FrequencyTablegateway. However, only the number of cases can be found for the position of TransactionPool only with ModResult. To generate the same TransactionPool by using only the frequency difference, the answer sheet of entire transaction pool is required. However, if the answer sheet is transmitted, a malicious attacker can steal it and know the transaction pool, i.e., the key generation information. To prevent this, a hash function is used. Due to its preimage resistance, it is almost impossible to find out an input value by looking at the hash result. Figure 9 shows how to synchronization of transactionpool. The Devicesensor calculated the hash value of TransactionPool and sets it as TargetValue. When BlockCondition64 is met, the Devicesensor sends a message including TargetValue and FrequencyTablesensor to notify the generation of a new dynamic key. Even if a malicious attacker steals TargetValue and FrequencyTablesensor, it is impossible to find out the original transaction pool within 64 s which is the generation cycle of the subsequent encryption key. The Devicegateway that received TargetValuesensor and FrequencyTablesensor calculates TargetValue when there is no lost message, compares it with the received TargetValue, and generates a new dynamic encryption key in Section 3.6. If there is data loss, it calculates ModResult by using the difference between FrequencyTablesensor and the lost FrequencyTablegateway, and generates the same TransactionPool from the TargetValue. It calculates permutations by using the lost ModResult, substitutes the permutation results into the lost part of TransactionPoolGateway, and attempts to obtain the same TargetValue through hashing based on trial and error. For example, suppose that 5 messages are lost, the lost modular results are {1:1 2:2 A:2}, and the index order of each lost message is 20, 21, 30, 44, 57. For the places of 20, 21, 30, 44, 57, there are 30 possible cases, i.e., 5!/(2! \(\times\) 2!) which are all permutations. For these 30 cases, attempts are made to find the case having the same value as the received TargetValue by filling in the empty index position and hashing the possible transaction pool. The case of having same value as the TargetValue indicates that the result is the same as \(\text{TransactionPool}_{\text{sensor}}\). Through this process, the \(\text{Device}_{\text{gateway}}\) will have the same \(\text{TransactionPool}\) as the \(\text{Device}_{\text{sensor}}\) despite the data loss. Meanwhile, suppose that a malicious attacker steals \(\text{TargetValue}\) and \(\text{FrequencyTable}_{\text{sensor}}\). If the frequency of ModResult is the same, the attacker should find out the \(\text{TargetValue}\) through repetitive hashing for \(16!\times(64)/(4!\times 16)\) number of cases. It is impossible to find out the \(\text{TargetValue}\) within the \(\text{BlockCondition}_{64}\), i.e., \(64\) s which is the generation cycle of the subsequent encryption key. The pseudo code is as Algorithm 3.