Or maybe we should just do the sync anyway.
I would normally be in favor maintaining the traditional resync,
since it's code any implementation has to have anyway, but here
it would open up a huge hole. An attacker could easily convert a
new SEIP data packet into an old SE data packet by replacing the
header+version and tearing off the known-sized MDC packet at the end.
Depending on the difference in resync mode alone doesn't feel good
to me, though.
Perhaps Hal could elaborate on the internal discussions that
motivate including the block+2 pad in the hash.
If you don't need the block+2 pad in the hash, then you could just
use another level of nested packet, something like:
Symmetrically-Encrypted-Packet {
block+2 pad
MDC-packet {
arbitrary-packet // compressed or literal
hash
}
}
I would find another nesting level much easier to implement in
a pipelined receiver. To implement the latest (non-nested) proposal,
an inner packet-parsing loop would need access to context from the
outer reading logic, which is not nearly as natural.
Looking through the archive, I see Tom Zerucha proposed bracketing
with two new packets, but I haven't seen this nested approach mentioned.
It's quite possible I've just missed it -- there's been a lot for
me to catch up on -- so if it's been discussed, can someone point
me at the messages?