Re: Authenticated cipher modes

[Simon Tatham <anakin%pobox.com@localhost>]

Bill Sommerfeld  <sommerfeld%sun.com@localhost> wrote:
> how about listing the combined mode cipher in both the "cipher" and the
> "mac" lists?  that avoids the unambiguity problem -- if you know what it
> is, you'll know to accept it on an all-or-none basis; if you don't know
> what it is, you'll reject both instances of it.

I think the problem is that this is inconsistent with the algorithm
mandated by the transport protocol for choosing ciphers and MACs:
the chosen cipher must be the first one on the client's list which
is also in the server's list, and likewise with MACs. Suppose, for
example, that a client's cipher list has (say) AES followed by
Helix, but its MAC list has Helix followed by (say) HMAC-SHA-1, and
suppose the server supports all of these things. The transport
protocol then _requires_ that both sides agree to use AES as cipher
and Helix as MAC, which makes no sense.

You could solve this by having the (hypothetical?) Helix-for-SSH
draft specify an override to the normal cipher/MAC selection
process: `if the normal cipher and MAC selection selects Helix as
only one of or MAC for a particular direction, then Helix must be
used as both cipher and MAC for that direction, superseding whatever
the normal selection algorithm chose for the other slot'. It isn't
100% clear that this gives you the right priorities, but it would at
least be unambiguous.
-- 
Simon Tatham         "_shin_, n. An ingenious device for
<anakin%pobox.com@localhost>    finding tables and chairs in the dark."