control channel???

[Werner Koch]

On Sat, 13 Jan 2007 20:40, taviso at sdf.lonestar.org said:

> I havnt read any rationale, but I assume that a packet with the same id
> could be generated by another implementation, and this is a safeguard
> against interpreting that.

This is one reason.  Another reason is defensive programming.

Although that the control packets used with cleartext signatures are
not exploitable at all (they emulate a one-pass signature packet), it
is safer to not allow the user to add data which gpg considers as
internally generated.  It also helps to analyze bug reports

Another use of the control packet is with the --pipemode feature.  I
have not looked into this right now, as this feature has always been
experimental and will be removed in future versions.

The last use of control packets is to run a syntax check on packet
compositions.  Here the control packet is used to replace a plaintext
packet by a short marker packet.  This is required because a plaintext
packet can be of any size but we need to know the sequence of packets
processed later.  Using the control packet is the most straightforward
method of implementing this syntax check.  I concur that gpg's method
of checking the structure of OpenPGP messages is too flexible and thus
not easy to get right.  However, this is the core of gpg and it seems
pretty matured by now and thus I see no immediate need to rewrite it
and introduce new bus and incompatibilities.

A rationale for not using a true RNG derived nonce is stated in
g10/misc.c:

        /* also this marker is guessable it is not easy to use this 
         * for a faked control packet because an attacker does not
         * have enough control about the time the verification does 
         * take place.  Of course, we can add just more random but 
         * than we need the random generator even for verification
         * tasks - which does not make sense. */

[s/also/Although/].  

gpg has always used a faked one-time signature packet to verify
cleartext signatures.  Back in July 2000, a vulnerability was found
when composing messages out of different signature types.  In the
course of fixing this problem, the ad-hoc method of faking a one-time
signature packet has been generalized to the control packet scheme and
used for the syntax check.


Shalom-Salam,

   Werner