The reasoning behind placeholder string in the dict

[blelump]

Hi Sam,

in the spec section 2.3 ( https://weboftrust.github.io/ietf-said/draft-ssmith-said.html#section-2.3 ) provides an example of calculating digest of an object (dict).

Why do you use the placeholder string in the payload that goes to hashing function? In essence what is the difference of having:

digest({
    'said': '############################################',
    'first': 'Sue',
    'last': 'Smith',
    'role': 'Founder',
})

vs.

digest({
    'first': 'Sue',
    'last': 'Smith',
    'role': 'Founder',
})

I mean, yes, both digests will be different, but what's the advantage of including the 'said': '############################################', in the object-to-be-hashed? Is this somehow related to performance or some other case?

[SmithSamuelM]

For some applications of the SAID the length of the serialization must be stable or fixed or it is not parsable. This is true when multiple serialization types are supported via some field in the data structure that provides the length of the serializaiton. For example the v version field in KERI and ACDC provides the length of the serialized data structure (SAD) so that parser knows how many characters to extract from a stream for parsing. The v field value MUST be fixed before the digest is computed in order that the length of the serialization before and after the digest is computed ans SAID field value assigned, be exactly the same. So using dummy characters ensures this. Using dummy characters provides more generic support for all types of SADs. Changing the length breaks any application that includes length information in the digested SAD.

[blelump]

Thanks. Clear.

You've probably thought about that before, but let me ask: due to the v attribute existence in the upper layer (the messages), the SAID spec is tailored to always contain a dummy string, even when you don't have any attribute that is length dependent (ie. above example from section 2.3 of the spec). Shall it be constrained like this?

[SmithSamuelM]

Its just simpler to have one spec and not options. The dummy string doesn’t have any downside that I can see even for applications where the size doesn’t matter. Too much flexibility is a bad thing. Numerous malleability attacks arise from allowing size variation. So its just good practice to fix the serialization size for the digest.

[blelump]

Got it.

Closing.