Class variables kept private through a library

Question

Oddly enough until now, there really hasn't been a need to be sure that a private variable remained private. But, there is sensitive data that is to be passed into the library, and passed back as well. Perhaps restructuring is the appropriate route so that we are not passing back the same data type that is being passed in, it just makes sense to.

public class PrivateData
{
   public publicInput_;
   private privateInput_;

   public PrivateData(long publicInput, long privateInput)
   {
      publicInput_ = publicInput;
      privateInput_ = privateInput
   }
}

But, this class inside the library when debugging can see the private variable that is part of the PrivateData class when providing this class as part of a jar. I couldn't find what the appropriate way to handle this issue would be. Perhaps some sort of Opaque class that obscures the actual value of the private data to be seen at the debug window when the user is using it? This data goes out and back into the library, so I had thought there would be a way to keep a portion of it hidden for ourselves without doing some sort of internal hash mapping on a key value passed out and then re-mapping when it comes back in.

Answer 1

I'll start with some potential obscurity approaches discovered if the information is requested to be shared yet obscured. One approach would be to do some management within the native layer and hold onto an opaque pointer within the class that is being passed around.

public class PrivateData
{
   public Object publicInput_;
   private long privateInputPointer_;

   private native static long jniStoreObject(Object privateInput); 

   public PrivateData(Object publicInput, Object privateInput)
   {
      publicInput_ = publicInput;
      privateInput_ = jniStoreObject(privateInput);
   }
}

With this approach you should not be accessing the native object frequently or performance hits would be encountered. Additional mangling of the underlying data can be performed as desired.

Another approach would be to store encrypted byes of a private object and de-encrypt those when the object re-enters the library for the purposes that we would need internally when it comes back through.

public class PrivateData
{
    public Object publicInput_;
    private ByteBuffer privateInputBuffer_;

    public PrivateData(Object publicInput, Object privateInput)
    {
       publicInput_ = publicInput;
       privateInputBuffer_ = encrypt(privateInput_);
    }

    Object getPrivateInfo()
    {
       return decrypt(privateInputBuffer_);
    }
}

With the second approach there is a delay in the encryption / decryption, but any available data to the user seen through the debug window would then be mangled bytes that would be useless except to the library itself when it needs it. These were some of the potential approaches that I have seen for handling a situation such as this when a library is requested to have this type of capability.