EncryptedNumber obfuscated only after accessing the ciphertext or using the serializer

[Guillaume Smith]

The encrypted value of a number a is g^a r^n mod n^2 which consists of two terms: g^a and the obfuscation term r^n where r is random.
The term g^a does not provide any security, only the obfuscation is. Thus knowing the random value r and having the encrypted value g^a r^n mod n^2, it is easy to compute a.

With the current API, an EncryptedNumber has a boolean isSafe representing if this encrypted number has been obfuscated by the node creating or receiving this encrypted number.
When using the encrypt method from the context, the computed encrypted number is not obfuscated, and thus not safe to share. The user can work locally with this encrypted number without obfuscating it, but the computed values are still not safe to be sent or shared.
To share an EncryptedNumber, it needs to be obfuscated locally*. In the current API, the ciphertext cannot be accessed directly (no get method) and can only be accessed using the method calculateCipherText() which obfuscate the number only if the number is unsafe. However, it is to notice that after using the method encrypt, the number is not secure. It will be secured after being serialized or when accessing the ciphertext, but in a public API, it may be hard to defend that the method encrypt do not provide a secure number. Furthermore, if a developper uses Javallier and decides to send the encrypted numbers using its own serializer (e.g. transforming an object to a byte stream), he may be able to send the ciphertext without obfuscation.

Not obfuscating an encrypted number each time it is generated is an optimisation when doing a large number of operations locally, but may not be intuitive.
We were thus thinking to remove the boolean isSafe but to have two classes: EncryptedNumber which is always safe (obfuscated locally) and a NotSafeEncryptedNumber which is not obfuscated locally, to make the difference more explicit.
Then from the paillier context, there will be two encrypt methods (encrypt which generate an EncryptedNumber and encryptNotSafe generating a NotSafeEncryptedNumber).
The sum of two unsafe encrypted numbers is unsafe, all other sums are safe (as at least one of the number has been obfuscated). The multiplication keeps the safety state of the used encrypted number.

By default, any handled encrypted values should be safe to ensure that a user cannot used unsafe encrypted numbers without using a method explicitely mentioning that it is unsafe. An aware user should have the possibility to use unsafe encrypted numbers to optimize his computation at his own risks.

The main complication of this refactoring will be in the paillier context where we will have to implement all the different operations of the different possible combinations of encrypted numbers.

• an ecnrypted number should not be considered safe to share even if it was obfuscated by another node. In fact, the user who had obfuscated it may store the random value it used and thus would be able to decode any encrypted numbers generated or computed (ex: a multiplication) with the same obfuscation.