Optimization: Signature for Body+ObjectId

[streetycat]

I find that, I need to sign Body and Desc separately if I want to prove the authenticity of the object. It consumes a lot of space and efficiency.

If we add the ObjectId into the signature data, we can achieve the same with the signature:

Sign(Hash(Body+ObjectId))

[weiqiushi]

In principle, most of our Object, there is no Body part. At this point, only a Desc signature is needed, and only once at the time of creation, to ensure that the source of the Object is true and reliable. Only when the object needs to be changed frequently, it is necessary to sign the Body. We believe that this kind of Object only accounts for a small part of the overall Object

[streetycat]

But we can't prove whether a body belongs to an Object, I can combine the desc of ObjectA with the body of ObjectB to cheat.

[weiqiushi]

ObjectA's body must have ObjectA's owner signature, so if you are not ObjectA's owner, you can`t combine ObjectB's body, if you are ObjectA's owner, you ARE NOT cheating.

[streetycat]

ObjectA's body must have ObjectA's owner signature, so if you are not ObjectA's owner, you can`t combine ObjectB's body, if you are ObjectA's owner, you ARE NOT cheating.

But, there a 2 objects(ObjectA and ObjectB), they have the same owner. I can exchange their Desc and Body, The new contents will be forged, and we cannot verify it.

[lurenpluto]

When this involves the initial design, the object consists of four parts: desc/body/signs/nonce, these four parts are actually independent, that is, they can be split and combined, that is

• Both desc and body of an object can be propagated and stored independently
• The desc and body parts of the object can be signed independently. The desc signature is generally the owner signature, which proves that the object belongs to the owner; since the body is mutable, the signature is generally used to prove that the modification was initiated by the owner, which is the theory Each modification requires the signature of the owner to prove that the body is valid
• Due to the immutability of desc (ObjectId will change after changing), the signature of desc is based on the signature of desc hash, and ObjectId also contains the hash of desc, so the signature of ObjectId can actually prove that the owner owns this object ( desc)

Therefore, for an object with a body, if you want to prove that it belongs to a certain owner, you need to sign the Desc and body separately, so in this case, you can sign the object_id+body once to save space; this signature mode is equivalent to bind the body with the desc, someone can judge whether the current body belongs to the current desc (for a complete object including desc and body), but I don't know if it will bring other problems?

object_id+body bound and signed, consider the following two ways maybe:

• The custom implementation of the content of the body, adding the object_id field, so that a not very general implementation will be obtained. Each custom object needs to add this field when designing the body content, and for the existing StandardObject and CoreObject type, there is no way to achieve
• The body adds an additional object_id as a unified Option field. If this field is filled, it means that the body is bound to desc. The difficulty of this solution lies in the compatibility issue. It needs to be carefully designed to ensure that the old and new versions of object are compiled decoding is compatible with

[streetycat]

It doesn't have to be old body, it could be something else of the same structure.

It maybe other content defined by a developer, but the structure is same as the People.body, if I find it, I can combine it with the People.desc, and put to MetaChain, maybe others can not connect to the attacked people.

[lurenpluto]

It doesn't have to be old body, it could be something else of the same structure.

It maybe other content defined by a developer, but the structure is same as the People.body, if I find it, I can combine it with the People.desc, and put to MetaChain, maybe others can not connect to the attacked people.

The fake body, which from "It maybe other content defined by a developer, but the structure is same as the People.body", does not have the signature of the original People's private key. Therefore, even if it is integrated with the original People.desc, it will fail the signature verification when using the People object in other places.

[streetycat]

The object is defined by other developer in a DECApp

It doesn't have to be old body, it could be something else of the same structure.
It maybe other content defined by a developer, but the structure is same as the People.body, if I find it, I can combine it with the People.desc, and put to MetaChain, maybe others can not connect to the attacked people.

The fake body, which from "It maybe other content defined by a developer, but the structure is same as the People.body", does not have the signature of the original People's private key. Therefore, even if it is integrated with the original People.desc, it will fail the signature verification when using the People object in other places.

The object(CustomObject) is defined by other developer with the same body as People.body in a DECApp.
And a user installed the DECApp, so he will signature it, now there will be a signatured CustomObject.body(it's same as People.body) and a signatured People.desc.

[lurenpluto]

Although the probability of this "attack" is small from the perspective of using the object with body, there is a potential risk that can be considered for improvement in subsequent versions.

For more information on the use of object with body, see at #154 (comment)

For the progress and suggestions of this improvement, please refer to #154

[streetycat]

I agree with you, but as a basic system, once there are enough users, small probability events will inevitably happen.

I will continue to pay attention, thank you!!