continuing with the thread from #4, #5, here the 3rd gap:
3. Ct1Acknowledged.Receive accepts Ek chunks not described by the spec
Spec (page 21–22, Ct1Acknowledged.Receive): the only handled message type is EkCt1Ack. Any other message is a silent no-op.
Code (src/v1/chunked/states.rs, Ct1Acknowledged receive branch): also accepts Ek payload chunks and feeds them to the ek_decoder, with an explicit in-code comment: "If we got all messages in order, we would never receive a msg.ek at this point … However, we can get messages out of order, so let's use the msg.ek chunks if we get them."
We suppose that this is a conservative extension: accepting out-of-order Ek chunks in Ct1Acknowledged can only help recovery and cannot cause incorrect decapsulation (the SHA3-256 integrity check on the reassembled ek_vector is still performed before Encaps2). However, the spec does not describe this behavior.
continuing with the thread from #4, #5, here the 3rd gap:
3.
Ct1Acknowledged.ReceiveacceptsEkchunks not described by the specSpec (page 21–22,
Ct1Acknowledged.Receive): the only handled message type isEkCt1Ack. Any other message is a silent no-op.Code (
src/v1/chunked/states.rs,Ct1Acknowledgedreceive branch): also acceptsEkpayload chunks and feeds them to theek_decoder, with an explicit in-code comment: "If we got all messages in order, we would never receive a msg.ek at this point … However, we can get messages out of order, so let's use the msg.ek chunks if we get them."We suppose that this is a conservative extension: accepting out-of-order
Ekchunks inCt1Acknowledgedcan only help recovery and cannot cause incorrect decapsulation (the SHA3-256 integrity check on the reassembledek_vectoris still performed beforeEncaps2). However, the spec does not describe this behavior.