patern and database question.......

[raja srinivas]

Hi guys,
I posted this question on the EJB J2EE forum but got no response ,so am posting it here now
I am trying to build an application for the Financial sector. As security is of primary importance there, i want to store ALL the data in the Database in the encrypted format(and not just the username and passwords).
My first question is, can i do this ?? If i can, what is the datatype of the fields that i need to specify ? can i carry on with integer, var(n), String type of datatypes or will they all have to specified as Strings if they have to be stored in the Encrypted format?
My second question is related to Ejb's and patterns
I have a Stateless session Bean that i want to decrypt/encrypt all data passing to and from the database, that is it sits between the other session beans and the entity beans. In this scenario this particular encryption session bean ends up as a bottleneck for the entire application, which might drag down the performance of the entire system. Does anyone have a more efficient solution/pattern for solving this problem ?
Thanks
Raja

[SAFROLE M3]

To answer your first question about storing encrypted data in the database, I would think that encrypted data would be comprised of alphanumeric characters, therefore, your data types in the database that require encryption would need to be VARCHAR, or variable character data types. INTEGER would not work because 1) this type can only hold digits, and 2) encrypted data usually requires more character elements than the actual decrypted data it represents, and INTEGER has a fixed size.
To answer your second question, you are correct about the bottlenecking statement. The fact that your are storing encryted data in your database is beyond me, but perhaps you need to think twice about the fields in your database that actually require encrytion. First, try to reduce the number of fields that require encryption. Then, think about this to increase performance...
Instead of decrypting/encrypting on every single query and update to your database, why not use an Entity bean that stores local copies of the sensitive data decrypted? In other words, lets say you have a Customer entity bean. Upon first access to the bean, the bean gets the customer data from the database, decrypts it, stores local copies of the decrypted info in the bean, and then sends the data back to the client. If the client updates, say, their password, the bean can simply encrypt the new password, store it in the database, and store a local unencrypted copy in the bean itself. The database and bean are in sync at this point. Any subsequent access for the customers information will not require the new password to be obtained from the database since the bean contains a local decrypted copy of the password. This would certainly speed things up since 1) you are not hitting the database for the requested data, and 2) the data does not need to be decrypted. Essentially, the first hit to the bean would be the slowest, but any subsequent queries for data would be much faster.
Hope that helps you,
SAF