▲ | amluto 16 hours ago | |||||||||||||||||||||||||
If you are planning to sign your data structures, IMO your first choice should be to sign byte strings: be explicit that the thing that is signed is a specific string of bytes (which cryptographic protocol people love to call octets). Anything interpreting the signed data needs to start with those bytes and interpret them — do NOT assume that, just because you have some data structure that you think serializes to those bytes, then that data structure is authentic. Many, many cryptographic disasters would have been avoided by following the advice above. | ||||||||||||||||||||||||||
▲ | zzo38computer 3 hours ago | parent | next [-] | |||||||||||||||||||||||||
> If you are planning to sign your data structures, IMO your first choice should be to sign byte strings Yes, that is right; but, the byte sequence can be the canonical form of the data structure, and DER is canonical form. | ||||||||||||||||||||||||||
▲ | RainyDayTmrw 14 hours ago | parent | prev [-] | |||||||||||||||||||||||||
That matches the advice from Latacora[1]. That advice makes a lot of sense from a security correctness and surface area perspective. There's a potential developer experience and efficiency concern, though. This likely forces two deserialization operations, and therefore two big memory copies, once for deserializing the envelope and once for deserializing the inner message. If we assume that most of the outer message is the inner message, and relatively little of it is the signature or MAC, then our extra memory copy is for almost the full length of the full message. | ||||||||||||||||||||||||||
|