Hi -

What's the suggested method for adding encryption to the entity classes?

Will encryption be available in the designer at some point in time? What I want to be able to do is encrypted and decrypt customer information as it passes through the entity objects.

At the moment I'm thinking of extending the entity class with the encryption application block from MS.

Kind regards,

Phil.

How would you like to have it added?

Data stored encrypted in the db and decrypted somewhere? Or stored normally but encrypted somewhere? And how would you like to specify the keys for en/decryption?

Ideal for me would be;

1/ Set an encryption key in the LLBLGen designer for the entire project. This key needs to be supplied to the entities to do a load, ideally this would be stored in the app.config.

2/ Set the fields which need to be encrypted in the designer when you edit the entities. (after all don't want to encrypted all the data).

There's always a question in my mind as to how and where to store a key, as well as if this needs to be supplied for each call or as part of the overall constructor.

Aside from encryption, where did the name LLBLGen come from?

Kind regards,

Phil.

We use Encryption in our internal framework, if you are going to include the ability to handle this within LLBLGen, I would prefer to see it done through an interface and/or a delegate so that the actual encryption process can be swapped out.

Several 'boundries' would need to be defined, such as does the encryption happen at read/write of the data from the database, leaving the data vulnerable while in memory, or should it happen on read/write of the actual properties leaving it encrypted except for when in use.

Obviously there are tradeoffs with each one, performance vs security etc. but regardless the encryption routine itself should be a pluggable architecture so each developer can choose the level of protection they need.

If you go to the effort of doing this don't forget about one way hashing needs as well. =)

John Gooding

There would also be different storage requirements. some data can be saved in nvarchar or nchar, but some can also be binary, and probably has different implications for different datastores I am sure.

Phil wrote:

Ideal for me would be;

1/ Set an encryption key in the LLBLGen designer for the entire project. This key needs to be supplied to the entities to do a load, ideally this would be stored in the app.config.

2/ Set the fields which need to be encrypted in the designer when you edit the entities. (after all don't want to encrypted all the data).

There's always a question in my mind as to how and where to store a key, as well as if this needs to be supplied for each call or as part of the overall constructor.

My question is always: encrypted data can't be used, so it has to be decrypted to be used. This thus means that the ONLY useful way is that code can plug in a key in the entity and AFTER doing that, the entity is usable as the property data gets decrypted.

Any other way is IMHO useless: either it has decrypted data in memory which thus can be retrieved through reflection, or it has encrypted data which then has to be read in encrypted form which also is pretty meaningless, as you can already do that: store the encrypted data in a blob field.

So IMHO the only useful way to encrypt/decrypt data in an entity is that the data is stored encrypted and when loaded from the db stays encrypted till the property is read and the decrypter kicks in, preferably indeed via a delegate. The other way around, a field gets set to a value, which is then encrypted through a delegate as well.

In the may/june update type converters are planned which allows you to specify your own assemblies which convert from one type to the other and which are used in the properties. I can imagine you can build type converters which in fact decrypt (i.e. convert 256byte varbinaries to string for example and vice versa)

Aside from encryption, where did the name LLBLGen come from?

Lower Level Business logic Layers Generator

My concern is... if your db is compromised then the data should be encrypted.

In terms of it's stored in memory as it's accessed this is a secondary concern.

UK law says "every reasonable effort should be made to secure personal data". Encrypting in the database is IMHO a base line requirement.

Maybe I should just encrypted in the db layer?

Phil wrote:

My concern is... if your db is compromised then the data should be encrypted.

In terms of it's stored in memory as it's accessed this is a secondary concern.

UK law says "every reasonable effort should be made to secure personal data". Encrypting in the database is IMHO a base line requirement. Maybe I should just encrypted in the db layer?

Every reasonable effort... that's pretty subjective. I mean, even with using SHA hashes, it might not be safe anymore, is it then reasonable to store the data with that?

And, what to encrypt? Every field? that's pretty intense. I mean: as soon as you store data encrypted, it can't be searched using usual values, as these have to be encrypted as well before the search takes place....