the message can be in F_p^12 or not?

[dandelionzbx]

the encrypted message must be in GT, if I set the message in F_p^12, encryption, re-enryption, and decryption still works. So
(1) why we can not set the message in F_p^12?
(2) In your scheme, how to solve the problem? If we randomly choose the message in F_p^12, and use some method to convert the message into GT(M), then set the symmetric key to SHA256(M). I want to know whether there is an efficient way for client to generate symmetric key instead of generating by us.

[BobWall23]

The math appears to work for values in F_p^12, but for the encryption to be secure, the values that you encrypt must be elements of G_T. The pairing operation at the heart of the proxy reencryption algorithm requires the input to be in GT.

The client should use the SDK to generate the plaintext (by calling gen_plaintext), derive the symmetric key from it (by calling derive_symmetric_key), encrypt the plaintext (by calling encrypt), then encrypt the actual data using the symmetric key and an algorithm like AES256-GCM. The encryption of the plaintext requires that it is an element of GT, and it is less efficient for the client to generate an arbitrary symmetric key and work backward from that to produce an element of GT.

The gen_plaintext actually does choose a random element in F_p^12, then performs a "final exponentiation" step that yields an element in GT. We initially tried choosing a random value in Fp and just multiplying a seed value in GT by that value to obtain a random element of GT, but that actually takes more time to compute than the final exponentiation.

[BobWall23]

@dandelionzbx Hopefully this answers your question - we will close this. Re-open or open another issue if you have additional questions.