protecting objects from being changed

[Andy B]

Is there a way that is already built into .net 3.5 that will let me protect
an object from being modified when the object is public?

[Jon Skeet [C# MVP]]

On Apr 15, 2:37 pm, "Andy B" <a_bo...@sbcglo bal.netwrote:

Is there a way that is already built into .net 3.5 that will let me protect
an object from being modified when the object is public?

Simply put: don't expose any way of making any changes. Make all your
properties readonly and make sure your methods don't change anything.
Making all member variables readonly goes some way to doing this,
although it's less clearcut if one of your member variables is of a
mutable type itself (e.g. StringBuilder).

It's unfortunate that C# doesn't have more support for creating and
checking immutable types - I know it's something that the design team
are considering for a future version.

Jon

[Morten Haug]

Is there a way that is already built into .net 3.5 that will let me

protect an object from being modified when the object is public?

I'm not quite sure what you mean by modifying an object, except for modifying
it's state (ie. fields). You should encapsulate your fields with properties.
Properties can be read-only (not set), or a mix of a public get and more
hidden set (private,protec ted,internal).

public class OpenClass
{
private string _name;

public string Name
{
get
{
return _name;
}
internal set
{
_name = value;
}
}
}

[Andy B]

I have an object that when it's IsSigned property is set to bit 1, can't be
changed. Otherwise if it is set to 0, it can be changed in whatever way is
needed. This check would need to be done before putting the object inside a
database and after it is pulled out of the database as well. The object will
be serialized into an xml format and it's IsSigned state will be put into a
database table column seperate from the object itself. I.e. in the table
called objects, I would have the columns Id, IsSigned, IsFulfilled, IsPaid,
Object. I guess I'm just looking for some easier way of doing something like
this since the object already has over 60 public properties built into it.
These 60+ properties are split between 18 sub classes and data types.
"Morten Haug" <mo****@haugern .netwrote in message
news:e9******** *************** **@news.lyse.ne t...

>Is there a way that is already built into .net 3.5 that will let me
protect an object from being modified when the object is public?

I'm not quite sure what you mean by modifying an object, except for
modifying it's state (ie. fields). You should encapsulate your fields with
properties. Properties can be read-only (not set), or a mix of a public
get and more hidden set (private,protec ted,internal).

public class OpenClass
{
private string _name;

public string Name
{
get
{
return _name;
}
internal set
{
_name = value;
}
}
}

[Peter Duniho]

On Wed, 16 Apr 2008 04:55:43 -0700, Andy B <a_*****@sbcglo bal.netwrote:

Do you have a link to the pgp encryption stuff? And I forgot to mention,
there are 2 different people signing the document (the company and the
customer).

http://www.google.com/search?q=pgp+signing

I'm not sure I understand the "2 different people signing the document".
You're not specific about what effect this should have, or how you expect
the two to interact. Are both people supposed to be able to access the
document after it's been signed? Can you simply store two encrypted
versions of the document? Alternatively, is it okay for the company to
retain a copy of the customer's encryption key?

That requirement will certainly make your problem more complicated,
whatever the answers to those questions might be.

Pete

[Andy B]

>I'm not sure I understand the "2 different people signing the document".

>You're not specific about what effect this should have, or how you expect
the two to >interact.

The company and the customer are supposed to sign the document. When the
form is filled out by the company online, a username and an encryption key
(a password as the customer would know it) is sent to the customer. They are
directed to login, view and sign the document (which has already been signed
by the company). After the company signs and presents the document for the
customer to sign,, for some reason the customer needs some changes made to
the document (the "form attached to the document"), the company should be
able to make the changes to satisfy the customers changes to the "form" and
then present it back to the user for signing. I think this possibly might be
a legal issue though since the standars for e-signing act of US law states
that after signing the document, it should be checked to make sure it can't
be changed. Is this before both people sign, or after both people sign?

>Are both people supposed to be able to access the document after it's been
signed?

Yes, both customer and company have to be able to view the document. There
might be a slight issue though. When the company fills out the document,
they have to sign it before it is presented to the customer before the
customer signs it. So, basically, even though the company has already signed
the document and commited to provide the services outlined in the document,
the customer still must be able to view and sign it for themselves. We
already found that 2 encryption keys for each document would be required -
one for customer and one for company.

>Can you simply store two encrypted versions of the document?

No, this method is not possible. Disk space is expensive and the database
needs to be as small as possible. Each transaction (document signing) will
roughly take about 2-3k in size. So, there can only be 1 copy of the
document for each transaction.

>Alternativel y, is it okay for the company to retain a copy of the
customer's encryption key?

Yes, that is entirely possible. The only restriction to this is that if the
customer forgets or loses their security key (password), it can't be
retrieved or reset. The conciquences to losing or forgetting the security
key is that the customer will not be able to view their signed documents
again (since most security signing services or programming addins do the
same sort of thing).

[Peter Duniho]

On Wed, 16 Apr 2008 16:44:37 -0700, Andy B <a_*****@sbcglo bal.netwrote:

[...]

>Alternativel y, is it okay for the company to retain a copy of the
customer's encryption key?

Yes, that is entirely possible. The only restriction to this is that if
the
customer forgets or loses their security key (password), it can't be
retrieved or reset.

Well, then I'd say that means it's not possible. After all, if the
company retains a copy of the customer's key, they can always retrieve
that copy. Or if they can't, there's no point in retaining it. :)

I also don't know what world you live in where "disk space is expensive",
but I suppose that's one of those relative things.

Other than that, the requirement that the document be signed by both
parties, while still retrievable by either party individually, is way
beyond anything I'm able to offer. I'm pretty much out of answers; you
need an expert in the field, and that I definitely am not.

I know that the experts in cryptography seems to be able to solve all
sorts of intuitively intractable problems. Maybe there is in fact a
reliable encryption scheme in which two different keys (and only two
different keys) can be used to decrypt an encrypted document. But if
there is, I don't know what it is.

Which isn't to say you won't get an answer in this newsgroup. It's
possible you would...I've seen some esoteric crypto stuff discussed here.
But for sure, I'm not the guy to give the answer. Sorry...

Pete