## 4 Analysis
### Security  
The level of security for attribute-based re-encryption is analyzed based on things presented by the cloud [32; 33]. These include unidirectionality, data confidentiality, noninteraction, intransitivity, multiple uses, re-encryption control, and master key security. Unidirectionality means that reverse re-encryption or decryption cannot be performed. Data confidentiality means that data cannot be obtained from an entity without privileges for the ciphertext. Noninteraction means no entity other than the data owner is needed \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Attribute-Based** &
\begin{tabular}{c} **Reversible** \\ **Attribute-Based** \\ **Encryption** \\ \end{tabular} & **Proposed System** \\ \hline Attribute withdrawal & \(\times\) & \(\bigcirc\) & \(\bigcirc\) \\ Delegation of authority & \(\times\) & \(\times\) & \(\bigcirc\) \\ Conspiracy attack & \(\bigcirc\) & \(\bigcirc\) & \(\bigcirc\) \\ Modulation attack & \(\times\) & \(\times\) & \(\bigtriangle\) \\ \hline \hline \end{tabular} Note: (\(\bigcirc\): Excellent, \(\bigtriangle\): Normal, \(\times\): Insufficient).  
\end{table} 
Table 2: Comparisons with the Proposed System. to generate the encryption key; interaction cannot be used to generate the encryption key or the basic data needed for encryption. With intransitivity, two different re-encryptions cannot be combined to obtain a new ciphertext. In other words, different ciphertexts cannot be combined to generate a new ciphertext to be reused, nor can the information needed for decryption be obtained. With multiple uses, re-encrypted data can be re-encrypted again and distributed. This is different from intransitivity, and it is not about generating a new ciphertext by combining re-encrypted ciphertexts. It means that re-encrypted data can be re-encrypted using a proper encryption key for distribution. Re-encryption control, whether or not to perform re-encryption, can be controlled by the data owner. It means that re-encryption for distribution for multiple uses is possible. However, the data owner must be able to decide whether to perform the re-encryption or not. In terms of master key security, a user cannot obtain a master key of an owner by colluding with another entity. In other words, the data user must not be able to obtain the master key of the data owner by any other means. The proposed model meets the following criteria, which are satisfied in typical proxy re-encryption: unidirectionality, data confidentiality, noninteraction, intransitivity, and master key security. In addition, the model satisfies re-encryption control but does not satisfy multiple uses. In the model that includes re-encryption control, when data generated by a vehicle are sent encrypted by the vehicle, the proxy will re-encrypt them. This is because access attributes for a re-encrypted ciphertext can be delegated or revoked. With respect to multiple uses, the model does not assume there is a case in which re-encrypted ciphertext is re-encrypted and used. Other attacks on the ciphertext include the collusion attack, user/attribute revocation, and man-in-the-middle attack. To prevent a collusion attack, the user must not be able to use encrypted data by colluding with the cloud. That is, a revoked user must not be able to access any encrypted data. User/attribute revocation is an important consideration when using attribute-based encryption. A man-in-the-middle attack is when an attacker comes between two parties that are in communication, eavesdrops on them, and obtains useful data. The proposed model satisfies user/attribute revocation. However, it may not fully defend against collusion attacks and man-in-the-middle attacks. The user revocation problem is resolved because user attributes can be delegated or revoked. However, for attribute delegation and revocation, because an attribute delegate/revocation list is not kept at the fog server, a revoked user cannot generate attributes by colluding with multiple entities.