IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: applying AES-GCM to secure shell: proposed "tweak"
Jeffrey Hutzelman <jhutz%cmu.edu@localhost> writes:
> What I'd suggest instead is defining a unique MAC alogrithm for each
> AEAD encryption algorithm, which has the same effects as null but is
> usable _only_ when the corresponding encryption algorithm is selected.
I'm not sure I follow precisely what you mean, but I think the
important structural change is that we say that should apply algorithm
selection to the encryption algorithm first, before selecting the mac
algorithm.
Then the result of the selection of the encryption algorithm may
trigger special behaviour when it comes to the MAC algorithm. The
naive rule "If an AEAD-algorithm is selected for encryption, no other
MAC is used, and it doesn't matter whatsoever what's on the MAC
algorithm lists" is simple and I think it should work, although I'm
open to other variations.
Implementations not supporting AEAD need of course not know or care
about this rule. A party that advertises only AEAD-algorithms for
encryption can safely list "none" as the only MAC algorithm (IIRC,
it's not allowed to send an empty list, and any value, not just
"none", will work just as well), negotiation with a party not
supporting AEAD will then fail in an orderly manner. A party that
lists AEAD and some non-AEAD encryption algorithm, will list the MACs
that it's willing to use together with non-AEAD encryption.
Regards,
/Niels
Home |
Main Index |
Thread Index |
Old Index